Thursday, 30 April 2015

Book review - Peopleware

I’ve been meaning to read Peopleware ever since I heard read about it on Joel Spolsky’s blog a few years ago. It was written by two software development project managers who came to the realisation that “the social complexities on most of the projects we’d known simply dwarfed any real technological challenges that the projects had to deal with.” The book is comprised of many short examples of the types of social problems they faced and suggestions on how to deal with them. One of the key words in the last sentence was short. I imagine many other books on management are dry and long winded. Peopleware on the other hand is an easy, enjoyable read that crams a huge amount of content into each short chapter. Much like rework you can pick it up for fifteen minutes and get something out of it.

Why read Peopleware?

I’m not a manager and I have no intension of becoming a manager any time soon, so why read this book? Firstly, it’s incredibly interesting. Secondly, it’s relevant to all software developers, not just managers. For example there is advice on overtime, office environment, innovation, hiring staff, meetings, leadership, making change possible and email. And this is just scratching the surface.

What did I learn?

There’s a huge amount to learn by reading this book but a few parts stood out to me.

  • The flight from excellence. The authors talk about the friction between the client’s desire for quality and the builder’s desire for quality. The client often isn’t concerned about code quality, they just want a finished product for their consumers. Builders (developers) on the other hand get a deep sense of pride from achieving high quality code. We’ve all been there
  • Making change possible. The insight in this chapter about why people resist change really hits the nail on the head. It’s argued that the resistance comes from emotion, not logic and I can’t help but agree. There’s also some good suggestions on how to make change easier
  • Productivity. This is a theme covered by a number of chapters. Flow is highlighted as being essential for productivity, as is quiet and the avoidance of distractions like email, telephone and multi-tasking

Some quotes

I know quotes like this don’t really mean much out of context, but I still like them, so here’s are some of my favourites.

“The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted”

“The fundamental response to change is not logical, but emotional”

“Change won’t even get started if people feel safe”

“The managers function is not to make people work, but to make it possible for people to work”

“People under time pressure don’t work better, they just work faster”

“Innovation is all about leadership, and leadership is all about innovation”

Monday, 16 March 2015

What makes a good software developer?

What makes a good software developer? I've been thinking about this question quite a lot in the past few years, even more so recently since I've been involved in interviewing candidates. 

Many people with much larger brains than myself have written about this, but here's my take. Knowledge and experience are very important. I could make a list of technical skills I think are essential for a job on the team I am currently part of. If someone else were to write a similar list I've no doubt it would be different. This is why I think knowledge and experience definitely play a big part in what makes a good developer but it's a good attitude that is key. 

What constitutes a good attitude? Here are a few things that I believe are important:

  • Enjoyment - You must enjoy creating software. This is absolutely fundamental. It's impossible to be good at something you don't enjoy 
  • Learning/self improvement - I'm not saying you need to spend hours reading books or creating software in your own time, although that will get you far, I mean at the very least take time to improve at work. Identify weak skills, learn from more experienced colleagues, read blogs when you have ten minutes spare
  • Caring - Please give a crap! Care about writing good code, care about coming up with the best solution possible, don’t settle for the first idea that pops into your head. Care about your team, care about your culture, care about everything!
  • Be open to new ideas - Don't reject something simply because it's new, you don't know much about it or it's not the way you’ve always done things
  • Take responsibility - Don't just complain about problems or leave them for others to fix, take action 
  • Simply doing what you've been asked to do is not enough - Typically companies want developers to build features and fix bugs as fast as possible. Unfortunately a codebase is like a car, it needs servicing, regularly, otherwise small problems become big problems. A good developer will identify and fix these problems