What Makes A Good Developer?
There’s (hopefully) a good title to get attention. I’ve been spending some time thinking about this lately. Part of being involved in the hiring process at HMB is thinking about who people are, how well they will do in the role we’re considering them for, and how happy they’ll be doing it.
What makes a good programmer? Excitement. That’s pretty much it no matter if you’re talking about a junior dev or a senior architect/tech lead. The difference is: excitement about what.
Good Junior Developers
A good junior dev stands out from his or her peers because of an excitement for creating stuff. Whether websites, desktop apps, something on a phone, or whatever, a good junior developer says things like:
Most really good junior devs are just discovering how awesome it is to make something they can interact with. They get excited about tactical problem solving, and designing more strategic solutions, but it’s definitely secondary:
When you’re a new developer, it’s all about learning new ideas by building stuff. You don’t know what you don’t know, and you don’t know a lot! Every new concept should be exciting and feel like it’s life changing.
I’m sure there are exceptions, but I’m a bit leery of someone fresh out of school who says they are excited about middleware. There is a subset of really good junior devs who are hardcore code geeks and want to build languages and databases. These devs may turn out to be awesome one day, but in most environments their first few years are going to be difficult. Be excited about building stuff!
Junior developers are great for a team that needs energy, but they need more experienced people to act as anchors.
Good Mid-Level Developers
Mid-level developers should have a wider spread of things that excite them. Part of this is just a developer getting exposed to more stuff, and getting good at new types of tasks. Another part is simple boredom; if you’ve built a widget 9 times now it’s not as exciting to build it the tenth time. A good mid-level developer sounds like:
Mid-level developers start thinking about business problems and no longer see everything as a code problem. They realize solving problems is what we do, not writing code. However, code is still what they’re focusing on:
A mid-level dev shouldn’t have lost his or her passion for building things by any means, but that developer should start seeing the big picture. They’ll still underestimate how long things will take, and they’ll dive down the first rabbit hole they see.
These developers are incredibly valuable to a team with a senior person who can keep them focused and engaged. Without this focus, they tend to overdo everything. A junior developer doesn’t know what TDD is. A mid-level developer wants to TDD everything, all the time!
Good Senior Developers
The old gray beards (or non-beards as the case may be) of software are an extremely important group; many organizations underestimate how valuable they are or even actively discriminate against them if they’re old enough. That’s another blog post though.
The beard is full of knowledge
A good senior developer can build things and still likes to do so, but is incredibly important to a team because he or she provides direction, stability, and the occasional gut feeling that something’s not right. Sometimes the only way to see a problem bus coming is to have been hit by it in the past.
A really good senior developer can keep up with the youngs when it comes to coding, but really provides value when it comes to finding solutions. They live to understand systems and figure out how to align the key pieces:
A good senior developer or two on a team helps teach the juniors how to do new things, and keep the mid-level folk from going overboard smacking everything with their technology hammers. They know when to use tools, and when not to. They realize when code isn’t the solution and find other ways to solve problems.
The big difference between a great senior and junior developer is big picture, strategic stuff. In either case, a good developer is excited about building things and solving problems. With more experience, the breadth of things they get excited about should increase.
Do you agree or disagree? Let me know how I’m wrong in the comments :)
1. You should always have 100% test coverage of target identification code. You really don’t want to learn this the hard way.