A lot of people are familiar with Maslow’s Hierarchy of Needs. The theory goes that humans have basic needs – food, shelter, and so on, and that once these are satisfied, we look to satisfy other requirements, like reproduction, and eventually “self-actualisation”.
Here’s a diagram:
Each level of the hierarchy only finds expression once the lower needs are satisfied. For instance, someone who has nothing to eat will be willing to sacrifice their safety in order to obtain food, and is very unlikely to be engaging in creative activities.
In my line of work, I spend a lot of my time figuring out how to get the most out of programmers. Ideally, this would involve work in that top tier, but it stretches all the way from the first and second tiers (“is my job safe?”) through the third (good, well-integrated teams), the fourth (recognising and rewarding achievements) up to the top tier, where we’re encouraging people to spend time developing themselves and working on ideas which might be able to help either them alone, or the whole organisation, do something new and brilliant.
But the hierarchy of needs I’d like to talk about in this article isn’t quite like this. I want to take this hierarchy of needs and put it in a mirror. From the perspective of a team leader or employer, how are my needs met by the programmers working with me?
I feel pretty strongly about this, as satisfying the needs of employers is actually the single most effective way for people to ensure that their first and second tier needs are met. And so the title “A programmer’s hierarchy of needs” isn’t misleading at all. What should you really focus on in your career?
To misquote former British Prime Minister Tony Blair: “Delivery, Delivery, Delivery”.
An organisation thrives on its ability to swiftly put services into live. Without that, it dies. This is the equivalent of food, water and warmth to a person. That’s why cycle time is considered such an important metric for development teams. As a programmer, your entire raison d’etre is to deliver code. If you can’t do that, then you’re useless. In our world of meetups, value-add events and new technologies, it is quite easy to forget this, and it is not unusual to come across individuals in organisations who are spending an inordinate amount of time attending conferences and other events, giving talks on god-knows-what, and floating about achieving precisely nothing.
As a newly minted developer, prior to getting a job, perhaps as a hobbyist or a student, the single thing that you can do to become useful and employable is to learn how to deliver. This means learning a language to the point where you can sit down and start coding without spending significant time looking things up; it means understanding a development environment; and it means being able to prove your skill, by having already delivered something substantial, start to finish.
The coders who I have learned the most from and for whom I have the greatest respect share a key trait: Tenacity. They were willing to bang and bang again at the door until they fully understood their domain. That hard-won understanding breeds success.
To deliver good code at speed, you need to build that proficiency with blood, sweat, and tears. Meetups can take a backseat, conferences also. Spend your time on learning to deliver, and you’ll find success.
Once we can rely on your ability to code, we need to be able to rely on your ability to fix it. What if something goes wrong? How can we prevent something from going wrong in the first place? Not only that, but how can we make the code secure against hacking attacks?
Firstly, writing clear, simple code is the best thing you can do to keep it secure. Rats’ nests of functions with cyclomatic complexity numbers in the low hundreds are not only impossible to test, they’re impossible to fully understand, and code which no-one understands can harbour exploitable bugs ripe for attack.
Secondly, writing idiomatic code which follows design patterns that your colleagues will understand is not only a sensible and sociable thing to do, but also means that should it go wrong, any of your peers will be able to pick it up and fix it. Implementing arcane things like domain-specific-languages because it seems the most functionally and philosophically pure way to approach the project will lead to crazy code that no-one else can understand. See point one.
Thirdly, understanding the various common attack patterns and ways in which your applications can be compromised (both by you and other people) is a foundational skill now. Security can’t be added to code at a later stage – it has to be built in from the beginning.
So once you can deliver, learn to do it with clear, idiomatic, secure code.
As much as the early years of computer history were defined by mavericks and crazy characters, a software engineer is of little use if they are unable to get on with others and fit into an organisation. This covers two things: Working as part of a team, and working as part of an organisation.
Within your team, hopefully your ability to deliver clear, understandable, secure code at speed will gain you respect, but you need to make sure that you return that respect to all of your team-mates, no matter who they are. This means no weird passive-aggressive comments in code-reviews; no false confidence when you don’t fully understand a new concept; no dismissive or rude attitudes toward other people’s coding styles: Don’t be a jerk.
Being part of a well-functioning team is also great for your mental health. Coming to work and knowing that you’ll be part of a friendly group of peers can do wonders for your mood.
Within your organisation, you need to have passion for your project and the greater mission of your company. This sounds impossibly optimistic, but great code is written by people with passion, and if you are harbouring a not-so-secret loathing for the management team, then you won’t have that passion, and you won’t be able to deliver. This isn’t about letting yourself be brainwashed by corporate bullshit, it’s about having the humility to recognise that whatever company you’re employed by, you’ve signed up for the job, and there are people who need you to give your effort to the mission.
In the same way that a person will reach out and form rewarding social relationships once their basic needs are met, an organisation thrives on partnerships with its customers, suppliers and peers. Once you and your team can deliver, and have delivered something excellent, it really is time to share that achievement with others.
Sharing your code doesn’t just give you a sense of self-esteem, it also gives you great feedback on things which you could have done better, in the same way that a social contact might give you better ideas about life in general. In reality, you’ll have already been getting plenty of feedback from people from the moment you started working with others. This step is really about taking it further, and sharing the work that your team has done for the organisation.
This will likely start with presentations at brown-bag sessions, lunch-and-learn, town-hall meetings, whatever particular venue or term your company uses. This might escalate to appearances at internal company conferences, and finally to appearing at industry conferences. This sort of thing is obviously incredibly great for both your career and for your company.
Notice how as you step up through the hierarchy of needs, the goals of the organisation become more and more aligned with your own personal goals.
As a newly minted influencer both within and outside your organisation, you’re now in a position to change things. You have the knowledge and experience to understand what your company needs, and you have the ability to have the organisation itself be creative and to generate new ideas. Really great companies innovate, and you’re now the innovator who is able to help it do so. Go for it!
What do you all think? One person’s map certainly isn’t the territory. Leave your thoughts in the comments below.