Influences on me as a programmer

In this article I will talk about two things that have influenced how I approach my craft, which is programming.  They appear to be contradictory, but I think I can live with both at once.  This is an area where everyone has to work things out for themselves.  I’m not trying to preach; just talk about things I’ve found helpful in case you find them helpful too.

A ship-building grandfather

My grandfather was a shipbuilder on Merseyside.  Because Merseyside had a port as well as shipyard, you might see a ship you’d worked on come back later to the port.  Any of the tens or even hundreds of people who had worked on a ship would point to it and say, “That’s my ship.” They were proud of what they had made.

I like to take pride in my work.  There’s already enough bad and annoying code in the world – I don’t want to add to it.  I try to approach people with dignity, which means they have innate value.  That in turn means the users of my software deserve a reasonably good user experience, just because they’re humans with value.

I want to be able to look myself in the mirror and think I did an OK job.  Or, on the other side of this, what I want to avoid is looking at some code and then thinking:

1. What idiot wrote this?
2. Oh, me.

I’m exaggerating for effect here – I try to not be too hard on other people, and being negative with yourself isn’t always a good way to help you develop.  (Search for “self-talk” in this podcast / article from Art of Manliness.)

I realise that there isn’t always time to do things as well as you’d like, and everyone can have an off day, or something else can get in the way of perfect code.  (Also, what is “perfect” code?  Programming can be referred to as software engineering, and engineering is often an exercise in balancing competing forces or constraints.  What is the perfect car?  An Aston Martin?  A Tesla?  A Classic Mini?  A Volvo estate?  It depends on what’s important to you, which will control how strongly the different constraints bear down on the design.  With programming there are similar competing requirements: functional correctness, time taken to write it, performance, maintainability, ease of support / debugging, memory footprint etc.)

So, the question I ask myself when I look in the mirror is along the lines of: Am I happy with the choices I made, given the constraints I was under?

Egoless programming

When I was a geeky teenager, I had the good fortune to stumble across the book Egoless Programming by Gerald Weinberg.  Unfortunately I don’t remember much of its details, but its central message has stuck with me ever since.

You are not your code, and your code is not you.  It’s much better to talk about “this approach vs. that approach” than “my approach vs. your approach”.  It helps things to be compared at arm’s length, on their own merits, rather than tangled up with personalities and egos.

The users of the code I work on are interested in:

1. Achieving their goals
2. The code, as a means to that end

Missing from that list is: me.

In all my career, programming has been a team sport.  At times I’ve been a junior member of the team, at others more senior, and also somewhere in the middle.  When I started at my second job, still quite young and junior, I was struck by the fact that while I had incredibly talented and experienced colleagues, there was still an open and supportive atmosphere.  I could ask questions of, and make suggestions to, people much senior to me, and this was OK.  There was a strong culture of reviewing designs, code, requirements etc. – anything of value.  It wasn’t assumed that just because senior person X made something that it didn’t need reviewing.  The product, and all of us, got better as a result.

We are all fallible and limited people.  We don’t know all the answers all the time (even with Google).  We’re not always the smartest person in the room.  If you have decent (in both senses of the word) management, your contributions should be recognised without having to shout about them or put anyone else down.  If you’re good at your job, this will show up as your being the person people go to for help, or the person the tricky problems go to, and so on.

Joel Spolsky famously once said that his criteria for hiring for people were:

1. Smart
2. Gets things done

It’s interesting that he and others have added a third to this list:

3. Not a jerk

There’s another can I look myself in the mirror? type of question here. Did any of my colleagues feel frustrated or unheard or diminished today because of me?

Strong opinions, loosely held?

It might seem that these two influences act in opposite directions, like individualism and conformity.  I don’t think so – with the individualism / conformity pair it’s a zero sum game.  You can only have more of one by having less of the other.

Programming need not be a zero sum game: You can both take pride in your work, and not be an arse.  In fact, respecting and otherwise helping your colleagues will make the thing you work on better.  This means you’ll be able to take pride in the whole thing, rather than having to pick and choose just the bits you’ve worked on.

I’ve heard people like Scott Hanselman describe a way of balancing these forces as: strong opinions, loosely held.  If you’re as kind and respectful as Scott then this is a sound approach, but you need to watch that it doesn’t devolve into something like HiPPO (Highest Paid Person’s Opinion).

HiPPO in a team of programmers can play out like this.  A senior person on the team gets in early in a discussion and states their opinion strongly, and other people who have lower status don’t feel able to challenge that opinion.  Strong opinions, loosely held works if there really is a fair marketplace of ideas, where all relevant ideas are brought into the open, and ideas compete on their merits.  If only the right people have the right to suggest ideas, or only the right people’s ideas are allowed to win, then the “loosely held” part is a fig leaf over a lack of health in the team.  As far as the team’s concerned, it would be more accurately be described as “the senior person’s ideas”.  Note, there’s no “loosely held” part.

Conclusion

I have had the good fortune to work with many people who were talented, cared about their work and were respectful.  I try to live up to their example, and I invite you to do so too.