Three key qualities of great developers

Illustration by Jessica Lascar

I’ve been coding since I was very young, I actually learnt to write my first lines of code before riding my first bicycle, and as far as I can remember I always wondered what makes great developers who they are.

Many years have passed since those days, and while I’ve been working with amazing people of all kinds and cultural backgrounds I kept reflecting on what I really value in people who practice our beautiful profession.

I’m not talking about values I seek for while I’m recruiting, but personal ones that inspire me at work and that I try as hard as I can to live by:

Illustration by Jessica Lascar
Nothing great in the world has ever been accomplished without passion. — Georg Wilhelm Friedrich Hegel

Passion is a fundamental aspect of becoming great at what you do. Amazing developers, when they have spare time, will be found coding, running side projects, studying, and experimenting with new technology. Sitting at a desk for hours can look like an unexciting hobby for an outsider, but there definitely is an addictive aspect in our nerdy profession.

Passion drives the perseverance that is necessary to find the infamous needle in the haystack. Software became so complicated, that a problem could lie anywhere and will occasionally look like an “impossible event” to our eyes, until we spent enough time searching for it, maybe days or weeks will have passed when the clicking EUREKA moment will finally be triggered, and then ironically the fix will be produced in a few minutes.

Clearly not everyone shares the same amount of passion, some think software is a “good job” and learn one or two things, maybe fairly well, and stick to those for their whole career. Undoubtedly these developers are somewhat productive to our society and I understand not all code is necessarily creative and pleasant to work with, but there’s a big chunk of IT workers out there that don’t read blogs, don’t keep up with technology and best practices… they just keep plumbing stuff together to earn their wage and go home.

Learning software requires a lot of trial and error, you will need a huge amount of passion to drive you constantly onto new learning challenges, otherwise you’ll end up finding your niche, some simple web page development, or legacy system maintenance job. Respectable, but definitely not great.

Illustration by Jessica Lascar
Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.
— Edsger W. Dijkstra

How is it possible that we’re able to dig up some rare materials from the ground, put them together, add some electrical power, and end up having a screen with 3D graphics, AI, sound, networking and more?

This happens because in computers concepts are layered: there are people who know everything about electricity and produce small components, people who engineer clever ways to put these components together and create great “calculators”, people who take calculators and instruct them to do useful things… this last part is called software development and itself is layered and modularised.

Certain people specialise in low level hardware interfacing and extract simpler ways to use your electronic components, say the sound chip. This is all very technical and arguably doesn’t require much abstraction, but the more the layer gets closer to the final user, to the real world application, the more things can’t be easily represented by ones and zeros, and need the power of abstraction.

How do we “abstract” the concept of an online shop, with a cart where items can be added and removed, how do we create the feeling of an AI. There’s no straightforward solution, it’s all left up to the human behind the machine. The best developers are able to create great abstractions, comprehensible by peers, yet understandable by a computer. When these abstractions are closer to the real world problem, they tend to lead to better and more elegant solutions.

In other words, because developers are humans, and humans understand real world metaphors better than than long sequences of ones and zeros, great abstractors’ solutions to real-world problems will be easily understood by other developers, and their work will be considered great.

For example a piece of software that produces a notification at an exact time of the day will be called “alarm”, not “notifier for exact time of the day” (though this will be part of its description), and from now on everyone will refer to it as alarm.

Illustration by Jessica Lascar
Simplicity is the ultimate sophistication
— Leonardo da Vinci

Often the best solution to a problem is the simplest we can think of, and although laziness is mother of all invention, the simplest solution is often very hard to find and short-sighted laziness could lead us to messy solutions.

Even abstraction (building metaphors), which is a big part of a developer’s work, has to be kept as simple as possible, and a good developer will invest time and energy into producing clever metaphors that are easy to understand for other humans.

When we want to have our “alarm” application, is it enough to check the internal computer timer and run a “notification” piece of code when we get to the right time… Or should we try to reproduce the abstractions of a real alarm, with the hands for hour and minutes, a bell, a mechanical way to set the alarm time etc..?

I mentioned before that software is layered, these layers allow us to focus on a specific area, but also hide what happens elsewhere. The simpler the layer, the easier it will be to understand what happens when things go wrong.

Looking for simple solutions means that great developers will look for the minimum amount of future maintenance on a piece of code, if it’s simpler it’s easier to maintain. Far-sighted laziness will motivate a developer to invest more time now, in order to not have to understand what they did years before when the needle in the haystack bug emerges.

Final words

So here they are, my three favourite characteristics that make great developers who they are. Please bear in mind that these do not necessarily determine my or carwow’s hiring strategy, which is more structured, and based on a larger, more practical scale of values.

I understand this is a controversial topic, so feel free to engage me in the comments section! But first I ask you to think of your favourite developers, the gurus, and reflect on whether they have the aforementioned qualities.

Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn :-)