Happiness Optimization

playwork.jpg

The hiring process for a new employee costs about $4,588 in the US [1] or £5,311 in the UK[2]. For Software Developer roles the cost might be even higher. Moreover, when we add additional costs like salary, taxes, benefits, training and equipment we will end with quite a big sum spent on a single employee.

Big companies and corporations try to lure the best candidates with a wide range of benefits and competitive salaries. In addition, each candidate is sifted through a complex and involving interview process  for only the best employees to be chosen [4].

The only thing which companies require back is a productive employee generating profit…

Unfortunately they tend to forget the most important and obvious fact:

A happy developer is a productive developer

Or perhaps, of more relevance, is the negative of this sentence:

An unhappy developer is an unproductive developer

This article will discuss some practices which may lead to the increase of happiness and (effectively) productivity of software developers in a company. It is impossible to cover all of them in only one blog post, but I believe that these are the most important ones.

Trust

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

Agile Manifesto

The most important part is to trust each and every new software developer in a company. We should think about them as artists or craftsmen doing their creative work and we should always give them room for problem solving.

Trust in your employees is sometimes more than that. When the level of trust is high, programmers start to feel unique and energized. With many challenges to work on, we are creating space for growth and self development. In addition, by giving time to simply play, hack and work out potential solutions, we are more likely to get them in the most (and probably the best ) productive state of mind – Flow [6].

The most interesting example of trust-building that I’ve seen was what Nordstrom tend to give their employees on the first day:

Welcome to Nordstrom

We’re glad to have you with our Company. Our number one goal is to provide outstanding customer service. Set both your personal and professional goals high. We have great confidence in your ability to achieve them. So our employee handbook is very simple.

 We have only one rule: Use good judgement in all situations.

Please feel free to ask your department manager, store manager, or division general manager any question at any time.

Tools and a Process

 In addition to state of flow and hacking, we should always provide programmers with the best possible tools and adjust the whole software development process to their needs.

According to  this  discussion, we can split programmers into two groups.

The first group loves playing with their toys. They view creating a software like a sandbox in a playground, so providing them with new tools, equipment and giving them possibility to create “cool” things means a lot to them. (If you don’t support my claim then why would programmers spend hundreds of hours discussing which text editor is the best [7]?).

Moreover, when a team is provided with inadequate tools or forced to use specific tools or when there is only limited number of licences available, programmers will start to feel like replaceable components. For example, in many financial organisations and bigger corporations you cannot install your own software without permission from management.

The second group loves delivering working solutions and is driven by a feel of accomplishment. They are focused much more on a bigger picture and they seek reward in form of appreciation or self-fulfilment from their achievements.

 This part is very well discussed in video on RailsConf 201by Chad Dickerson, CEO of Etsy [9]. He discussed performance of factory workers in early 90s and used some ideas related to software development:

 “The traditional assembly line deprives the worker of satisfaction… by the confinement of the worker to one manipulation repeatedly and endlessly which denies the satisfaction of finishing a job.”  [9]

He discussed an interesting story taken from a book [10], where workers assembling parts of the aeroplanes (modules like engine, wings etc) were unsatisfied and productivity started to decrease. They resolved this problem by organising a meeting with pilots in planes and having discussion about which parts the workers were working on. After this productivity raised, because they were given a purpose and a sense of meaning.

“If companies really want their workers to produce, they should try to impart a sense of meaning – not just through vision statements but by allowing employees to feel sense of completion and ensuring that a job well done is acknowledged.” [9]

 Lastly, I would like to point, that no matter what, every programmer loves to work with certain type of equipment. It is viewed by them more like a lucky pen or certain routine which is necessary. We can find plenty of examples discussing what equipment and tools a programmer is using in new company on their blogs [11]

Working Hours

One of the most obvious, yet another one which is often forgotten by employers, is allowing programmers to work for no more than 40 hours a week. There are three important reasons behind this.

 First of all, programmers are often working on creative things. In order to solve problems they need the full firepower of their brain and a different way of seeing things. It is impossible to come up with the perfect design in one day no matter how much time you spend on it.

Secondly, when you work for a long time you start to make more mistakes. It may be the case, that instead of producing good code you are injecting bugs into the code, which might be difficult to find and not easy to repair.

Lastly, it is all about knowing what a team can produce with sustainable pace without depleting their energy resources. Instead of working 80 hours a week for a month before the release of the project and crashing afterwards it is better to work 40 hours a week for two months. This approach will definitely lead to much better results and higher team morale [12].

Other sources also support the 40h/week regime:

From The Art of Agile Development [15]:

“When you make more mistakes than progress, it’s time to take a break. If you’re like me, that’s the hardest time to stop.I feel like the solution is just around the corner—even if it’s been just around the corner for the last 45 minutes—and I don’t want to stop until I find it. That’s why it’s helpful for someone else to remind me to stop. After a break or a good night’s sleep, I usually see my mistake right away.”

 From [13]:

“1. Improve focus.  How many people can claim they have 100% focus every day, 40 hours a week?  Focus is absolutely critical in building quality software and it’s something we should absolutely optimize for.

2. By giving your employees a little more time for themselves they’re able to take care of personal errands during off hours.  And that’s exactly how it should be anyway.”

Eat Together

Something about sharing meals breaks down barriers and fosters team cohesiveness. Try providing a free meal once per week. If you have the meal brought into the office, set a table and serve the food family-style to prevent people from taking the food back to their desks. If you go to a restaurant, ask for a single long table rather than separate tables.

The Art of Agile Development, Supporting Energized Work p. 79-80 [15]

 There are plenty articles on the web about benefits of eating a dinner with your family [14]. Some of them are applicable to team members too. I would personally say that there is nothing in the world which boost team morale, cohesion and spirit rather than lunches together.

Let’s look on this from another angle – providing good communication and integration within a team is extremely important – after all the team is developing a software together. If most of “socialization” takes place during mandatory meetings over a conference table, it is much better to build some relationship over the lunch table.

However we should have a look on much more than eating together. Giving your employees nice and comfortable place to eat and rest is extremely important. Every human being needs a break from time to time, so having a place designed especially to that will be beneficial and probably this is a reason why we can find examples of colourful offices from Google, Facebook or Amazon.

I would say that we should go much further than that. Providing your employees with free lunches and onsite cantinas may tighten bonds much more. After all, there would be a place where your employees can eat, chat and have fun together. In addition, providing them with free lunches will save the time for going to grab takeaways [11].

Conclusion

There are a lot of examples of a good techniques and practices which can lead to productivity boost. Some of them are obvious (but still a great majority of employers are not following them) another are vague and it is difficult to see explicit connection to productivity.

Aforementioned practices may have a much bigger impact on programmers’ performance than increasing salary, which doesn’t always work in boosting productivity. Even when it does, it is usually in short term. Creating energized atmosphere and controlling developers need will help to boost their productivity, design and code quality.

This might be a reason why most programmer would rather work for Google, rather than Banks, even if salary in the first place would be a lower.

References

[1] Hiring an Employee: How Much Does It Cost?  – http://homepages.uwp.edu/crooker/441-so/articles/ats-workforce-121500-c.htm

[2]http://www.hrmagazine.co.uk/hro/news/1020605/talent-aquistion-costs-rise-uk-gbp5-311-hire-compared-gbp2-226-us

[3] How Much Does An Employee Cost? – http://web.mit.edu/e-club/hadzima/how-much-does-an-employee-cost.html

[4] Cracking the Coding Interview: 150 Programming Questions and Solutions

[5] On Developer Happiness and Productivity – http://ilikeorangutans.github.io/2013/04/03/on-developer-happiness-and-productivity/

[6] The Flow – Programming in ectasy http://psygrammer.com/2011/02/10/the-flow-programming-in-ecstasy/

[7] Editor War – http://en.wikipedia.org/wiki/Editor_war

[8] Respect People: Trust Them to Use good Judgement –  http://management.curiouscatblog.net/2010/10/28/respect-people-trust-them-to-use-good-judgment/

[9] Optimize for Developer Happiness at Etsy – http://www.youtube.com/watch?feature=player_embedded&v=22EECFEk9Xs

[10] Concept of the Corporation, Peter F. Drucker

[11] Price of Developer Hapinness – http://officesnapshots.com/2012/03/30/the-price-of-developer-happiness/

[12] What Silicon Valley Developers Can Teach Us About Happiness At Work – http://www.huffingtonpost.com/2013/07/25/what-silicon-valley-devel_n_3644538.html

[13] Optimizing for Happiness in Software Development –http://www.bucketsoft.com/blog/post/optimizing-for-happiness-in-software

[14] The Benefits of Eating Together – http://www.sparkpeople.com/resource/nutrition_articles.asp?id=439

[15] Shore, James. The art of agile development. ” O’Reilly Media, Inc.”, 2007.