MongoDB code guru: what even is a ‘good’ developer?
This is a guest post for the Computer Weekly Open Source Insider team blog written by Joe Drumgoole in his capacity as director for developer advocacy across EMEA region at MongoDB.
Drumgoole voices his own opinions via social media here and writes his own blog.
He has pointed to the stream of articles that agonise over how to extract the most from that scarce resource, ‘the good developer’.
Some push it and write about how to turn ‘good developers’ (by which they mean anyone with a modicum of skill) into spectacular coding robots that churn out thousands of lines of perfect user-centric code.
But, he argues, it can’t be done.
So what does ‘good’ even look like…? … and when developers are good, what keeps them motivated?
On the subject of code, you’d be surprised to learn that good and bad code can often look amazingly similar. So it [i.e. code] alone cannot always be easily analysed. This static analysis rarely uncovers the kinds of live problems that really destroy a system’s utility.
So if we don’t know what’s good, how do we define better?
Instead of defining good systems, we should try and define good programmers in some abstract way. What mould do they fit into? Do they work well with people? What’s their past experience? This somewhat intangible (dubious even) list goes on.
Aye, there’s the runtime rub
Well here’s the rub of it. Even the best developers (especially the best developers) don’t know what makes them better than the average developer. What’s worse, bad developers don’t know why they are substandard. So when we talk about what motivates developers we cannot afford to talk at a level of abstraction that could be the same for doctors, firemen, lawyers or any post-graduate profession.
Programming, software engineering and development – whatever you choose to call it – is just different.
Let me tell you from my experience what the best programmers look like and what continues to motivate them:
- Constant Learning: Smart people can usually weed out low performers much faster than management can ever detect them. I worked at a large investment bank in London and the team I was on was responsible for core infrastructure. They simply wouldn’t tolerate people that could not operate at their level but they created some of the finest software of their generation (and it’s still being used to this day). They also continually learned from each other. Once you find yourself in a team where everyone is challenged and in pulling in the same direction – that’s powerful.
- Fear of defeat: The willingness to apply themselves to a mountain of minutiae to get to the bottom of a problem. The original hacker team in the Trinity College maths department trying to boot a 4.1 BSD tape from which they had not viable tape drives (they managed it after a few weeks) is a good one. The programmer wrote out hex dumps by hand from an in-memory dump to debug a memory link in that same bank. Now that’s something.
- Being the resilient ones: Great developers believe in themselves, bet on themselves and have faith in themselves to get the job done. Programming is often relentless so that inner belief is a key driving force. Feel like you don’t have it? Embrace it. Don’t wallow or dwell on failures; acknowledge the situation, learn from your mistakes, and move forward. Now that’s resilience.
- Seeing the job through: The need to get a system delivered, documented, used as a first priority. In the developer’s mind, half done is simply not done. We’ve all started a book and given up, remember how bad that felt? On the flip slide, completion never felt so sweet. Now go off and tell all your friends about it.
- Taking full responsibility: The capability to apply themselves to not just the ‘cool’ part of the system but the boring dingy parts: the localisation, the documentation, the logging, the build system and installer requires dedication.
What’s clear is that cultures must be built around a set of values that ensure that these kinds of behaviours can predominate and flourish.
Go-faster bean bags
If you build a culture like this… then suddenly the foosball table and the bean bags will seem like the management equivalent of go-faster stripes.
People like nice offices and decent salaries (that’s table stakes) but they will neither join nor stay for those aspects of the job alone. They stay for great work, great colleagues and the opportunity to change the world – one application at a time.