Category Archives: Business

Developer productivity is a  perpetual area of improvement. Finding better tools, new abstractions, learning shortcut keys and using modern project planning is a way to continually get better at your job.  The goal of doing all that is to produce better software faster.

Choosing the right tool for the job plays a big part.

Lets say you wanted to get a web app up and running that provides a login, admin area, user accounts and authenticated REST API around some simple business form data that’s submitted by a Mobile App.  Writing that in C++ might take weeks, writing it in Go would take days and writing in Python/Django might take hours.

When deciding how to roll this service out onto some servers.  purchasing, receiving and building physical hardware could take weeks, manually building the machines on AWS could take a couple days, and deploying to a PaaS like Heroku or ElasticBeanstalk might take minutes.

There are orders of magnitude in reduction of effort required to build things when you choose the appropriate solutions.

As a developer who writes software there are several things that are easy wins for writing more code in less time:

  • Typing speed. Learning to type faster is a basic skill, expanding on that with shortcuts is awesome
  • Knowing the language and APIs.  Every time you have to Google for API references it slows you down by 10x and gives you a chance to get distracted.
  • Knowing how to do things. At a higher level than code syntax, knowing how to structure solutions, and having a good sense of what the software is supposed to do and how you are going to do it.
  • Isolation. Distractions will derail you – people, noise, tv, all get in the way of being able to focus on the problems at hand.
  • Preventing blocks. Running out of battery, losing internet, no credit card, don’t have the credentials? Getting blocked can stop you from working entirely.

The best developers really can be operating at 10x the performance of the average developer.

Getting things built quickly is not only impressive, but it is a major competitive advantage.  Getting your products to market faster and iterating on them faster is a big win for everyone.

Technology is getting more and more personal. As it does such it becomes easier to make things social in a real way.

Bringing a social experience to your application is more than just slapping a like button somewhere. Social is about making people aware that when they use your application they are entering a social situation.

A party is a real social situation. We know it’s a social event before we get to it. The host of a party tries to ensure that people engage in social behaviour such as chatting with each other, singing, dancing, and meeting new people by arranging for food, drinks and games to stir conversation.

Facebook is social in only a narrow sliver of what it means to be social in meatspace.

Now is the time to take a leap in what it means to create social software.

Creating software the provides a sense of presence, promotes social engagement, and enables social discovery and self expression is a real challenge from both a software and design perspective.  There will be new innovation required from both disciplines to get it right.

We are digging into this by experimenting within the scope of mobile games.  Mobile provides an interesting place because it is much more personal than sitting down at a computer in your office.  It allows us to go deeper than Facebook was able to go with their app when it was developed in 2004.

There is much work to be done yet in this area.  MMOs provide a glimpse at what should be possible to duplicate in mobile.  World of Warcraft and Second-Lift allowed people to meet and form relationships that became more intimate than would have happened outside of the games.  Technology has the potential to make social much more than it is in a physical setting.

Maintenance.  UGH!

We live in a world where software is part of an every evolving ecosystem of other software.  Everything is constantly changing and everything you do needs to keep up or risk falling into disrepair and creating technical debt.

The maintenance window is a chance to breath fresh life into an otherwise languishing project.

A little over a year ago I released FreeSlots, a slot machine game for iPhone. It’s a pretty good game, and I’m still happy with the design although I was cut short on developing it fully. The time has come to refresh it for the upcoming iOS 8 release and that has given me the chance to revisit the code and find some other opportunities to make it  better.

My original plan was to use FreeSlots as a platform to test some bleeding edge features, and then fork the project into a new game that is better branded, and takes the best lessons I learn from doing FreeSlots, while also spinning off some of the services I create for it so others can take advantage of it.

It seems that strategy is still a good one.

So this maintenance tune up, has fired me up to develop some newer, bigger, better things.  YAH for maintenance!

You know what you need to do to launch your business, you have the skills, you have the idea, and yet progress is slow. Maybe you have White Shoe Syndrome.

The problem with white shoes is that they are always dirty and need to be cleaned. When it is time to sit down at your desk to do some work that pair of white tennis shoes is in the corner of your office just screaming at you to clean them. Even in the dead of winter when you are months away from lacing up those white shoes for some reason now is the right time to clean your shoes.

Of course it doesn’t have to be white shoes. If you are sitting down to do some work and minutes later you find yourself tidying your office, or mowing the lawn, or re-organizing your stamp collection then you are a victim of white shoes syndrome.

The tricks to overcome this is:

  • Isolation – close the office door, put on some headphones or anything else you can do to physically isolate yourself from visual noise and disruption
  • Minimize clutter – clear your desk, minimize your office, move files off your desktop, run your software full screen
  • Turn off notifications – turn off auto-email checking, disconnect from chat, turn off calendar alerts
  • Turn off the lights – working in the dark can help you focus on what’s on your computer screen
  • Before or after hours – try working early in the morning, or late in the evening when other people are not around.
  • Go somewhere to work – you won’t be inclined to clean the counters at the coffeeshop

White Shoes can be a real roadblock to your success.  Try to do what you can to avoid it.

Getting into the flow or zone as a coder is when you are your most productive and code spews from your fingers into your favourite text editor as fast as you can type. When in the zone you can seemingly pour out 100’s of lines of code in no time.

But how do you get into the zone other than by pure happenstance?

Authors have a technique called free writing which was popularized in Julia Cameron’s The Artist’s Way for which the rules are simple:

  • Select an amount of time: 5, 10, 20 minutes for example
  • Write continuosly and quickly for that amount of time ignoring spelling, grammar, formatting
  • If you can’t think of things to write, write about that or simply scribble. just keep things going from your brain to the page.
  • When your time is up, review what was written and mark anything interesting to explore further in a future free writing session

The goal of free writing is to build up enough momentum to blast through mental blocks and quickly transition to a state of flow for the real writing process. It is meant to be done daily as part of a morning routine before real work starts.

I’m curious if a similar technique could be used to get into the zone for coding. A quick Google search revealed no information about anyone exploring this idea so I thought I would.

Here are the rules I’m using for freecoding:

  1. Pick an amount of time before hand 5, 10, or 20 minutes for example
  2. Use a text editor where I can turn off syntax highlighting (to avoid the impulse to go back and fix typos)
  3. Code in a language that I know well enough to code without referring to documentation
  4. start coding and don’t stop typing. If you can’t think of something to code just code about that. it doesn’t have to run, it doesn’t have to make sense or be correct syntax. Try not to go back to code out of order.
  5. Don’t try to accomplish anything that will require you to stop to think. ie. don’t try to implement your favourite sorting algorithm.
  6. If you code yourself into a spot where you don’t know the API well enough, just fake it out with a call to a magical function that does what you want.

When time is up, turn on syntax highlighting and read what you wrote. Make notes about anything interesting that you’d like to explore again in the future. Note things that you were hung up on with syntax or APIs that you should brush up on.

The purpose of freecoding is to limber up your mind before starting real code. The secondary benefit is to identify gaps in your knowledge of a language or library where you might have to stop to look up the documentation.

Use the momentum built up in the freecoding session to launch into a real project. Try to keep the transition freecoding and real code somewhat smooth

As an example here’s part of what I did in my first 5 minute freecoding session:

a = 'hi there'
b = a.replace('hi', 'bye')
a. reverse()
c = fun(a)
def requestA(a):
    return GoogleThis(a)
if requstA(a) == 'no results':
    println("there's nothing in the google machine")
    return tryBingInstead(a)
requestA('matt warren')
b = b.capitalize()
b = b.reverse()
b = b.capitalize()
not_sure_what_to_type = b
def star_trek_is_better_than_star_wars():
    return true
if star_trek_is_better_than_star_wars:
    print "hell yeah"

There’s nothing interesting going on here, it’s not complete thoughts and doesn’t accomplish anything nor does it run. the point is to simply start getting a flow of code coming by reducing any blocks that might prevent it (in this case by removing the need to create something that runs or even makes sense).

Upon reviewing this particular session I might decide that the concept of using bing as a backup for google is interesting, and that I need to increase my vocabulary of string functions to call upon.

In my limited trials so far it’s clear that there is a bit of a skill to freecoding successfully. For all other coding you do there is a goal to reach, something specific you want to implement. I suspect that after a couple weeks of regularly freecoding the code will start to get more complex, better structured, and longer thought streams of cohesive code segments.

I am still early on in my experimenting with this concept. However, if it is as effective as free writing is for authors, then perhaps free coding can be a daily ritual more of us can use to boost our productivity. I’d like to encourage every software developer to give it a try and report back (if they like) with how it worked or didn’t work for you.

One of the things Bill Gates did was to take a semi-annual ‘Think Week’ retreat. During this week he would extract himself from all obligations and hole up in a hotel somewhere with a stack of books to read. To Bill Gates these retreats were critical to his ability to stay ahead of big picture trends in industry that might have otherwise surprised Microsoft. Sometimes these retreats resulted in major strategy shifts for the company.

The rules for these retreats were simple, he was not to be contacted except for emergencies. And presumably he had amassed a reading list recommended to him by his peers over the previous 6 months.

Bill Gates is not alone in the practice of going into seclusion to fully focus on important things.

Religious people have been practising seclusion for centuries as a way to deeply explore their beliefs. Many writers are known to use retreats, or hotel rooms as ways remove distraction and get a burst of productivity.

I know many software developers that find they get a lot done on long flights, and have heard of more than one developer that swears by trans-atlantic cruises as a way to avoid the numerous distractions and become productive.

Taking time to really think about a problem deeply can often benefit from some isolation. When you are alone in your thoughts and have the time to fully develop your ideas it puts you in a unique position. There are so few people who think deeply on topics. Most decisions are made by impulse and intuition – which often is good enough – but for difficult problems which require new concepts or unique approaches we need to invest a bit more time to read, learn and think.

As an employee your ability to take these sorts of retreats is severely restricted. Bosses want to have something to show for the money they pay you to sit and think quietly can be a difficult sell.

This is just one of the things that makes being a contractor/consultant so appealing. When you can make your own decisions about how to spend your time, then it’s possible to invest in taking a week to isolate yourself and regroup, or produce something.

A think week is also something that is difficult to justify when you’re living paycheck to paycheck. Using up a week of precious vacation days, or taking unpaid leave presents a risk, especially given that when you come back to work you may not have the time to follow through on what you did during your retreat.

Based on the effectiveness of a think week, as reported by several high profile people, it’s unfortunate that they can be so difficult to execute on yourself. Time is a tight commodity and obligations can be hard to wiggle out of. However if you can manage to schedule one there can be good payback.

Personal branding is deceptively effective in many cases.

The difference is skills between a manager who codes and a developer team lead is negligible.  In many cases you could say they are job titles that describe the same role in a company and yet from a HR and status point of view they are very different.

If you’re getting hired into a position having presented yourself as management material with the bonus of having technical skills then you get lobbed easy questions in a relaxed setting (usually).  The hiring decision is based more on fuzzy “I liked her” type of gut reactions than any type of objective assessment of skills.  With this initial staging you are more likely to be treated as an equal with other “higher status” management employees.  And any technical skills you have will be treated as a bonus.

Brand yourself as a developer with team lead experience and you will get a barrage of technical questions.  A high stress examination of how well you know obscure algorithms, or specific programming language APIs. In this case any holes in your knowledge will be assessed as negatives.

The difference in hiring practices between these two roles is night and day.

With this admittedly specific and anecdotal comparison it would be interesting to see just how real and widespread this effect can be.

In my experience there seems to be a causal relation between what you internally believe your self worth to be, and the employment positions you get.  A strong personal brand comes out naturally when you have the confidence to tackle a “higher status” role.

If there’s a lesson here it’s this:

Position yourself for the future you want to have and there’s a better chance you’ll get it.

The term Service Oriented Architecture has been twisted by so many people now that it has lost some of it’s meaning. Microservices is a software architecture for web apps that aims to define a more specific way of doing SOA that isn’t so fuzzy and hand wavy.

Web applications have long been developed in a SOA way.  Especially with the advent of PaaSes like Heroku which make it easy to bolt on services.  But even when building an app to run on Heroku it’s easy to create a monolithic application which may better be segmented into separate services.

By dividing your application into micro services you can focus on clear contracts and well defined APIs. If you have an application that can be divided between people to work on then micro services allow you to reduce the cognitive burden of understanding the entire application.  It makes regression errors less likely, and gives you the focus to produce a high quality service.

You can go pretty far with micro services.

Exactly how micro you go can depend on your goals and the size/requirements of your project.

A project I’m working on now will be creating a separate analytics service.  By pulling this API into a distinct application we were able to choose a different technology stack that  was better suited to the requirements.  For uptime and performance it made sense to write the analytics API in Go, this provides nearly 10x the performance of our usual Rails stack.  Given that we expect the reporting app (in Rails) to be updated far more often than the analytics gathering API it’s valuable to isolate it.

This separation is just the start. In a micro service architected system you can go so far as to pull out user accounts, generating reports, sending reports, processing various things etc. all into their own stand alone service.  Then tie everything together with asynchronous message bus so that if a service goes down messages are queued and nothing gets lost.

There are some performance issues to be aware of.  A request going through a message bus adds significantly more overhead compared to a function call.  As a result some thought should be made on how to design the API with some performance considerations. Perhaps adding a bulk update operation as an example.

The benefits to pulling off a successful micro service architecture can be huge for managing the scalability of a big system.  If you have a project that is going to be big enough to require 4-5+ full time developers then consider micro services so that you can divide the work into multiple stand alone micro services.

When you measure things you can manage them – Words of wisdom from Peter Drucker.

Every time I have made the effort to measure something whether it be calories, carbs, miles run, heart rate, cash flow, net worth or weight there is always a surprise in what the numbers reveal. Recently I did a one week time audit; writing everything I did to the nearest 30 minute interval.

Prior to actually measuring things I would be swayed by my perceptive bias.  Things that I don’t like doing would seem to take more time than they actually did, and those things that I enjoy would take more time, and seem like less.  This emotional influence on time perception can deceive you into making poor time management choices.

Sleep was the biggest single bucket for spending my time.  it consumed 33% of the week.  That is a lot of time I wish I could take better advantage of.  There are other animals in the world that sleep far less often than us humans so perhaps there are some (yet undiscovered) ways to sustainably reduce our sleep requirements.  Until then sleeping will continue to be a big part of life.

Employment was the second biggest time  consumer. 23% of the week was spent in full-time employment.  An additional 3% was spent commuting to and from work so a total of 26% of my time went towards earning a pay check.

11.5% was family time.  Taking care of a 8 month old can take as much time as I have to give.  It certainly didn’t feel like I was getting this much family time.

10% of my time was spent on preparing or eating food.  For me that was a shocking number since I usually have a handful of something quick for breakfast and skip lunch.  Cooking and eating supper was taking a lot more time than I had realized.

Time dedicated to personal projects on the computer was just 5.5% of my time.  Not enough to make progress and much less than I wanted to  spend on it.

Rounding out the last few things that took time,  Reading, shopping and housework consumed 3% of my time each and TV was at 2%.

There are a fixed number of hours in the week (168).  Getting more time to work on my side projects requires taking hours away from something else.  Deciding what to cut is difficult, actually figuring out the logistics to cut out that time is also difficult.  Hours are not easy to re-allocate without major life changes and stressing other things and so it will be a struggle to adjust to a new schedule.

Change is hard.  Changing how your spend your time, can actually change who you are which can be fundamentally difficult to drive from yourself without an external influence (like having a child).

This time audit raised some interesting issues. Time is our most valuable resource and yet so few of us understand how to best utilize  the time we have given to us.  A disconnect between your goals and your time  can be a critical underlying issue that prevents your success.  I would encourage everyone to do a time audit.  You may find it as surprising as I did.

Grabbing the best ideas from other industries and applying it to your own is a fantastic way to learn and discover new ways to do things.

I was listening to the Tim Ferriss podcast yesterday in an interview with Neil Strauss.  Two best selling authors discussing their creative process for writing a book.  It got me thinking if some of the approaches they discuss could apply to to software development -which is also a highly creative process.

Let’s break down Neil’s process a bit.

The first part is to do a lot of research.  For example, when Neil is doing an interview with a celebrity, he will read everything they’ve written, listen to ever song, devour every bit of information he can about the person.  He writes out a list of 100 questions for the person and studies it like you would for exam prep.  Finally when it’s time for the interview he puts the questions in his back pocket and forgets about them.  As a result of this level of preparation and study the interviews can flow naturally.  He has a backup of questions to draw on if the conversation stalls but usually he can riff off the bulk of knowlege he has collected to build rapport and get to the really interesting details.

With a cache of notes from research it’s time to start writing.  There will be several drafts and the goal of the first one is to “Write to the end”.  Convert the pile of notes into a story as quickly and rough as possible without self editing along the way until you get to the end of the book.  This first draft will be read by no body else.

After the first draft you are just 1/4 the way finished.  The second draft is done for the readers.  You cut out all the uninteresting pieces, ensure the story arc is solid, characters are developed enough, flow is good, and jokes are funny.  You do this by putting on the hat of a reader and ruthlessly editing your first draft.

The next step is to put on the hat of a hater.  To deflect criticism before it happens you go through it again with the perspective of someone who wants to debunk your stuff and criticize your ideas.  At this step you fact check everything, and make sure there’s nothing offensive, or at least that the counter points are acknowledged and dealt with.

Finally it goes to the editor and is test read by anyone who wants to read the manuscript. Listen to their criticism, and adjust your book to improve things and cut parts that people don’t find interesting.

After enough feedback you’ll know when to lock down the book to a final version and send it to be published.

For an average size book this whole process can take upwards of a year to complete.

There are some lessons that we can take from the best approaches to writing books and apply it to writing software.

Notice that this approach to writing a book is not Agile, and it’s not waterfall, it doesn’t involve sprints, scrums or user stories. It’s completely unique to the way most software is created.

The first part of Neil’s process is research.  You might roughly correlate this step to requirements gathering but that vastly understates the effort Neil goes through.  I have never met a developer that thoroughly masters the domain knowledge before typing anything the way Neil does.  Taking months and often years to interview people, take courses, and generally immerse yourself in the space you will eventually write about gives you skills and knowledge to be able to write “to the end” without pause.

Side note: Interruption is one of the most detrimental things to the creative process. Stopping to look something up, or ask a question of the client can waste half a day of productivity.  Agile methods promote this open communication during development… maybe there’s a better way.

Writing to the end for the first draft is something not possible without having enough domain knowledge to do it in the first place..  There really isn’t a comparable product in any software project I have personally worked on which compares to this first draft.  The scope of Neil’s first draft expands far beyond what is in the final book as he will likely cut 50% of the pages during editing.  It has me wondering if it would be a good software development approach to rip through a 20,000 line first cut of an application knowing that I’d delete 1/2 of the code before being finished, slashing out features along the way.

If we did write this quick rough first draft application with the intention of whittling away anything superfluous to arrive ultimately at a publishable product then the next step would be to put on the hat of someone who wants or needs to use this software. Can you make the interface more intuitive? Can you give it some life? Are there any features that are more complex than they’re worth? What can be cut without destroying the utility of the application?

It would be only after these changes have been made that anyone other than yourself would see a demo.

In Neil’s process the final step is essentially debugging. Going through the application yet again with an eye for correcting errors, fact checking things, getting a lawyer’s review for liability etc.  At this point you would also ask for the input from as many test subjects as you can, gathering and filtering feedback to fine tune rough edges.  Essentially you want to make sure that if someone is trying your software they don’t have a reason to ask for a refund and they can’t claim that you or your company are incompetent.  The final product has to be great.

Only after enough friends, family and colleagues have used the software that you feel confident in it do you call it done.

It’s interesting to wonder if this would produce a better product than the typical agile developed software.

There are a couple of significant differences in software vs book writing however that need to be addressed.  Software is rarely a single developer’s sole project.  There is usually a team to divvy the work between. This team adds some communication load to the project as people need to be in sync.  This team approach doesn’t work well if all the domain knowledge is stuck in scribbled notes and in the head of  one guy that did the research.  Would Neil’s approach scale to writing a 10,000 page book with 4 other writers?  The counter point would be that if you’re looking at writing a 10,000 page book maybe it would be better to write 20 500 page books and only have a single author per book.

Software is also not written linearly.  When you start to write a book chapter you may be able to start writing and continue without stopping the flow of words.  You probably wouldn’t be halfway through chapter 18 and realize that it would be good to foreshadow what’s happening earlier, then stop and go back through to find a good spot to add that foreshadow element to an earlier chapter. A disruption like that would completely disrupt the flow of your writing.  It’s difficult to write software without jumping around like that.

Programming languages are much more rigorous than English.  it’s not always possible to skip pieces where you need to know an answer to get a working program. There can be hard dependencies that prevent you from moving on until they get solved.  Again this is an opportunity for interruption.

It would be interesting to try this method on a software project to see how it translates.

If you are interested in getting more details from Neil Strauss and Tim Ferriss about the creative process check out this video: