What does it take to be a good programmer?

First, let’s talk about the teaching profession. 

What does it take to be a good teacher? 

In Norway – where I live – I think most would agree that the best teachers see the potential in their students, and find ways to bring out the best in each one.  It’s not so much about the teacher’s own knowledge of the subject they teach, as their ability to spike their students’ interest and make them understand the subject matter. 

Schools have changed dramatically over the last century.  Back in the day, children lived in fear of the teachers.  Teachers were meant to be strict authoritarians who’d happily administer painful, both physical and emotional, punishment for, say, getting your latin grammar wrong. To be a good teacher back then, it was deemed necessary to be authoritative and have superior knowledge that was not to be questioned.

How things have changed.

Some say we’ve gone too far in the other direction now a days: 

“Respect for teachers is gone! Nobody wants to be a teacher anymore. It used to be a respected profession. Now it is low pay, low status and you’re bullied by difficult kids and their parents all day.”

Maybe we have gone too far, maybe we haven’t gone far enough.  Interesting discussion, but beside the point I want to make, which is this: Things can change. 

We still have the same profession: teaching. That takes place in the same environment: schools and classrooms. Yet, how the work is done has been transformed. I don’t think teachers back in the day saw this coming – They most likely would not approve.  People are good at justifying the status quo.

Ok, now let’s talk about programming.  

What does it take to be a good programmer? 

You need to be really smart and have a scientific mindset. Most importantly you need to love learning new things.  Programming isn’t a typical 9-5 job. At least not if you want to be any good at it. You need to stay up to date with the latest changes in the field. When (if?) you get back from the office, you should spend your evenings on open source projects and/or learning new languages and frameworks.  


I wonder how long it’ll be before we look back on this era and shake our heads and marvel at how anyone got through this with their sanity intact (did they?).

Lots has been said about how the current state of software development leads to lack of diversity.  But forget about that for a second: what does the current state of software development do to the actual software we create?

What impact does it have on the products we create, when nobody has more than a few years experience with the tools used? I got my first programming job more than 20 years ago (part time while I was studying, but still!) Yet the amount of time I spend every day searching the internet for tutorials and examples of how to use whatever “flavour of the month” framework or library or service we’re using is considerable.  I know I’m not the only one.  The time and effort spent learning these new libraries and frameworks, is time and effort not spent focusing on the actual product we’re meant to be making.

This might not be so bad, if the new services and frameworks we learn provide massive improvements in our ability to deliver value to the users.  But it rarely does.  Whether it’s the software architect who’s discovered “microservices” or “streams”, or a new programming language, or a manager who wants to impose some configurable off the shelf monstrosity, it seldom really makes an impact where it matters: to what the users of the software actually see and use. 

That’s what should matter.  That’s the whole point of programming.  The point of programming is to create software that delivers value to the users.  

I don’t care how good you are at chopping vegetables, how efficiently you handle the ingredients while cooking or how modern your kitchen appliances are – if the food tastes like crap, I’m not coming back to your restaurant! 

I don’t care how good your vocabulary is or how many languages you speak.  if your writing isn’t interesting or relevant to the audience in some way, it’s worthless.  

As a woman, I keep hearing the following justification for the lack of gender diversity in programming: 

“Women don’t choose programming, because they want to work with people, not technology”. 

Sure, absolutely.  In todays field of software development, people don’t come into it, do they? We care about the tech.  Is it “green field”? Does it use “cutting edge” technology? That’s what the programmers care about.  If you care more about people and how the product you’re making actually affects them, then you would not fit in.

Is that a good thing though?

To be a good programmer you obviously need to care about the code.  Caring about user experience doesn’t make you a good programmer.  Just like caring about people’s health is not going to make you a good doctor.  As it turns out though, caring about people, does not in fact exclude the possibility of caring about other things as well. Like medicine, or chemistry, or indeed coding. 

Which brings me to the very act of programming:  What is code, when it comes right down to it?  What kind of mental processing is actually required to write elegant and efficient code? 

Code is written instructions. Nothing more, nothing less.

Programming is writing down unambiguous instructions, and then grouping those instructions in meaningful ways.  We’re coordinating work.  It’s not rocket science. 

Is it even science?  

If you can coordinate a large social event, you have all the mental capacity required to be a good programmer. Let me illustrate:

To organise an event, you need to book a venue and send out invitations. Then you can start looking for music acts and caterers.  When the RSVPs start coming in you can narrow down how much food you’ll be needing and land a menu with the caterers.

For each of the various stages in this process, there will be more layers of increasingly detailed instructions.  The top level catering instructions are “3 course meal for 50 people: first a greek salad, then roasted lamb, followed by a crème brûlée.  For each course, there will be more layers of instructions. The most detailed of which being how one beats an egg, or how one operates the oven.  But you rarely have to dive into that level of detail.

To be able to coordinate things well, it’s important that one has a clear idea of the roles and responsibilities involved.  You typically don’t mix in table setting instructions in the crème brûlée recipe. 

This does not require Mensa-level intelligence.  

“Architectural” considerations like: Should we have one person in the kitchen be responsible for all egg-related work, and another in charge of the flour, a third person is in charge of chopping things? (“microservices”?), or should we let people be in charge of a whole dish – like “A does the salad, B does the main course” etc? Choosing between these types of strategies does not require a masters degree in a scientific subject.  And making these decisions are precisely what programming is all about.  Typing out the code is not the point or the challenge of programming.  It’s about being able to understand the flow of instructions and information.  Which roles are required to perform a task, who needs what information, and how do they get it?  

Do we need a “Chef” with the abilities “greekSalad()”, “roastedLamb()”, and “cremeBrulee()”? Or do we deal with the dishes separately, so they don’t necessarily have to be implemented by the same chef?  Do the resulting dishes get put on a queue, and then get picked up by a “waiting staff” process? How do we prevent dishes piling up with nobody there to deliver them to the diners?  

There are no “correct answers” here.  There are always any number of ways of solving these problems.  The important thing is that the instructions make sense, and that they lead to the desired outcome. 

These are the problems we work on as programmers. 

Is this “technology”?  Because I know plenty of people capable of reasoning these things out, who are not very technologically minded. The only “techy” part of the programming job, is that we have to learn new tech every couple of years to express these same ideas. But is this really necessary?

In addition to the questionable requirement to learn new tech all the time, I suspect that the reason we think programmers have to be insanely smart, is because so much of our code is organised in a horribly complex manner.  We group things together in non-productive ways to suit our technological fancies.  Like organising the kitchen staff by the tools in the kitchen.  Team A are those who work with metal utensils,  team B work with wooden utensils, C use electrical appliances and D are in charge of all food heating.  Trying to make sense of how one creates a crème brûlée with a worker grouping like that requires a lot of intelligence.  But it shouldn’t have to be that way. We need to stop admiring those smart enough to understand how the software works, and start making the software easier to understand in the first place.  But we’re not optimising for those kinds of skills at the moment. 

If we just stuck with a tech stack that works, we could focus more on user needs.  Just like in any other field, there might be new and shiny innovations that could provide some benefit or other.  But just like in all other fields, you shouldn’t have to drop everything every time someone comes out with a new product: 

“OMG! Have you seen the new kitchen appliance series from Kenwood?!?! We need to completely replace everything in the kitchen!  If we don’t, we’ll be unable to attract new staff,  morale will drop and everyone will resign!”

I feel pretty sure this is not a thing in the field of catering. Developers are such primadonnas, and it’s a self reinforcing thing.  We get away with this behaviour, because there are too few of us, we’re needed.  Why are there so few of us? Because we’re gate keeping and pretty much ensuring that anyone who isn’t this obsessive about tech won’t feel welcome or that they’re able to contribute. 

Through my years in the field, I have seen my fair share of companies and the struggles they face.  Very many are working on the same thing: “We need to move our software to the new platform”.   In other words, they have software, that works (for some definition of “works”), but they feel they need a new platform of some kind. 

“We need to move to the cloud”.  

“We need to make this ‘COTS’ system do the same thing that our old software does” 

“We need to modernise our tech stack”

A very large part of what software developers do now, is not write new functionality that users will notice and enjoy, but rather re-write something the users dislike to varying degrees, so it runs on a “modern platform”.  This “modern platform” will of course be obsolete a few years down the road, so we start again. 

Software development provides well paid work for many, so in a way I guess I can’t complain personally.  I happen to like working as a software developer, even under the current environment.  But I can’t help but asking myself: 

How are we getting away with this? Isn’t someone going to catch on soon?  How many “new platforms” do we have to make, before people start realising that rewriting everything, using “the latest tech” is not going to solve the problems that matter? 

What would the field of software development look like, if “the best programmers” were not the most mathematically inclined neophile workaholics, but rather people who are good at organising work? Good at communicating clearly.  People who care, not so much about which tools are used, but  about using whatever tools are available to maximise the value of the product being made?    

I think we’d see a different brand of developers, and much better software.  Better in a way that actually matters to the users.  

Would developers risk losing status, just like we’ve seen happen to the teaching profession? Maybe?  But is that a good enough reason to hold onto a counter productive culture that both prevents focus where it matters, and simultaneously excludes people in a time where software development is needed more than ever? I don’t think so. 

I don’t know how we’ll do it, but I think we both can, and should change.  There will be strong resistance of course, from those with the most to gain from the status quo. 

I hope we’ll manage to find a better balance between the eagerness to learn new tech, and the focus on actually delivering value. 

I hope “If you’re interested in people, you won’t be a good programmer” will bring about a good laugh all around, as we shake our heads and think about how backwards the field of software development used to be. 

I encourage you all to help make this happen. 

This entry was posted in iT. Bookmark the permalink.

8 Responses to What does it take to be a good programmer?

  1. mark4asp says:

    Teachers don’t make good programmers. Good programmers make themselves by seeking out the best experts and mentors to learn from.

  2. Max says:

    Wow, mentors! They sound a lot like teachers.

    Did you even read the article?

  3. qristin says:

    And… Where did I even say that teachers would make good programmers? I’m confused.

  4. Tim says:

    “If you can coordinate a large social event, you have all the mental capacity required to be a good programmer.”

    As someone who has both worked large events and programmed computers, I can report that this is false. Or if you believe that it’s true, then by your definition I have never in my life seen one person ever “coordinate a large social event” successfully. Their directions are always wrong. Large events ultimately work because people down the chain are human beings who know not to interpret bogus instructions literally. Computers are exactly the opposite. When your caterer runs out of eggs, they don’t burn down the entire hotel.

    “Team A are those who work with metal utensils, team B work with wooden utensils, C use electrical appliances and D are in charge of all food heating.”

    That’s crazy! You might as well split up construction crews into people who work with electric wires, and people who work with water pipes, and people who work with wood framing. They’d certainly never get anything built that way.

    “If we don’t, we’ll be unable to attract new staff, morale will drop and everyone will resign!” “I feel pretty sure this is not a thing in the field of catering.”

    Indeed: because catering and programming have opposite supply/demand curves. Caterers aren’t getting US$100,000+ starting salaries, either. In a hypothetical world where caterers were in such high demand, you can bet they’d be quitting all the time to go work for the kitchen with the coolest gadgets, too.

    “I think we’d see a different brand of developers, and much better software. Better in a way that actually matters to the users.”

    Unfortunately, software suffers from the Agency Dilemma. Users today overwhelmingly don’t pay for the software they use, so they don’t have a voice in how it’s made. Users will put up with pretty bad software, as long as it costs them no money. And that means companies have no incentive to make anything even a little bit better.

    As with teaching, until you have a method to fix the fundamental economic issue, the best we can do is write blog posts asking people to change their behavior, even though it’s not in their personal interest to do so.

    • qristin says:

      As you might have guessed, I too have organized events and written code. They are not _the same_. As you say, computer instructions need to be way more precise.
      All professions have their own characteristics. The point of my comparison here was to provide a new way of thinking about coding, as a way or organizing work, rather than “creating mathematically optimized technological algorithms” or whatever people assume our work resembles.

      We also have a tendency of splitting our teams in “frontend” “backend”, “messaging”, “database” etc. So to deliver anything the user might actually be interested in, you need to coordinate with tons of different teams. In my opinion, it’s much better to group software by what noticable benefit it delivers to the user. The risk of code duplication is worth it.

  5. Mike Iapalucci says:

    Rather than take issue with any of your analogies, I just want to say how much I enjoyed your post. I am relatively new to programming but not to life. I am also a teacher. I think you make a lot of good points. Thanks!

  6. tobias says:

    As per usual you bring an entertaining and highly interesting take on a topic that is hard to write and talk about. It made me think and laugh and want to change. And that’s besides resonating with soooo much I see everyday at my current assignment from others, and (sometimes) from myself.
    Thanks 🙏

  7. Joe says:

    I have been a software developer for 40 years and I think my experience has been very different. I have mostly written software for myself or a small group of colleagues to use, in the field of scientific or financial modelling. For the first 20+ years I used one language, Fortran, and didn’t bother with things like frameworks. We did move to different physical platforms and updated code to newer versions of Fortran, which always had significant improvements.

    At my current organisation I have used substantially three programming languages. I have ported code from the 1st to the 2nd as the server was end-of-life and they didn’t want to pay £60k / year to support a very small amount of code; this was entirely successful. A large amount of code in the 2nd language is now being ported from a dedicated on-site server to the cloud as this will be significantly cheaper than replacing the end-of-life server.

    I accept that my experience may not be typical of most people who work as programmers these days!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s