Some Senior Software Engineers feel they must win every argument, which I think is a bad idea. Not only is this bad for the team, it’s bad for the Senior Software Engineer as an individual. In this article I’ll explore this a bit, with the analogy of Top Trumps. It’s also related to the strong opinions, loosely held idea I go into in an article on my influences.
Top Trumps
Because I will use this as an analogy, I ought to explain Top Trumps to those for whom its new. (Please skip this section if you already know what they are.) Top Trumps is a card game for two or more players, that I used to play as a child. You need a special Top Trumps pack, rather than a pack of normal playing cards. Each pack will be on a particular theme, e.g. cars, animals, athletes etc. Each card gives the same set of attributes for a different car, animal, athlete etc. So a car pack might show acceleration, top speed, weight etc.
The idea is to end up with all the cards. Each player starts with an equal share of the pack, and for a given round in the game the person whose turn it is picks an attribute, e.g. speed, and all players say the value for that attribute for the top card in their hand. The best (usually highest) number wins all the cards, and the winner picks the attribute for the next turn.
In my experience there are usually three groups of cards in every Top Trumps pack. There are one or two cards that seem to always lose because they’re the weakest. Most cards are in a group where it’s less predictable who will win and lose, and there are one or two cards that seem to always win because they’re so strong. I’ve visualised this relationship for a pack of Olympic athletes, based on some simple analysis.
It has nothing to do with ex-Presidents of the USA, it’s “trump” in the common card game sense of one card or group of cards beating or trumping others.
What has Top Trumps got to do with Senior Software Engineers?
Some Senior Software Engineers treat their job as one long game of Top Trumps. They consider everyone to be a Top Trumps card, with a score against a set of attributes. The attributes might be something like:
- C# / JavaScript / SQL / etc.
- Database design
- Web design
- Etc.
Because they’re Senior, they see themselves in the group of cards that always wins. Everyone else is a loser. This is because they view interactions as a zero sum game (like in Top Trumps) – for me to win, you have to lose.
I will spend the rest of this article looking at this idea. (TL;DR – I think it’s wrong.) First I’ll dismantle things, and then I’ll propose what I think is a healthier approach.
Maybe your attributes and scores aren’t as great as you think
First let’s have a proper look at what’s on the cards. That framework that you last used 10 years ago because it’s been replaced by a better one? I don’t think that basing your self-worth on that attribute is a good idea. Those 5 years’ experience you have in language X? Have you really spent 5 years developing new skills in that language, or did you stop after the first year and have spent the last 4 years regurgitating that knowledge? I.e. do you have 5 years’ experience, or 1 year’s experience 5 times over?
Extrapolating from past experience
This is hand waving, but I hope it’s useful. Imagine that there’s a tool or approach that you’re considering. This could be applied over a range of situations, and there’s some way of ordering those situations (e.g. by complexity) and also measuring the outcome of picking that option. You’ve got experience applying that approach in a few situations (A – C) in the past, and have seen what the outcome has been like. You’re now in situation X and, based on past experience, you think that the outcome will be even better (so you think the approach is the one to pick).
This is an extrapolation – you could be wrong. It could actually be like this:
It might be that the new situation appears to be in the region of situations that you’ve encountered before, so you’re confident that you can apply the approach, i.e. there’s no extrapolation. However, maybe there’s a variable in the set that defines which situation you’re in whose value is different from before, and you’ve not noticed it. So it’s not the same situation as before (it just looks a bit like that from one point of view), and it’s back to extrapolation.
Building things back up again
Now I’ve said what I think is wrong, I’ll look at what I think is better. To help with that, let’s look at your responsibilities as might be defined in a job description.
Your responsibilities as a senior developer are usually something like:
- Help the team to meet its objectives – in terms of features, time, quality etc.
- Help the team to perform as well as it can
- Help the people in the team to grow as individuals
- Help the organisation outside the team to meet its objectives
Your responsibilities as a senior developer shouldn’t include:
- Always be right
- Always win arguments
More junior developers can help with all the responsibilities in the first list, but they usually focus in on only their part of the first one. They need to do their bit to improve the code.
So, if you want to cling to the model of the Top Trumps card (but not the I-must-win-every-time part), think of your card as growing extra attributes as you become senior. You’re expected to keep all the technical ones, but you also gain people-related ones. The trouble is there are no unit tests for these, and you can’t run them through the debugger. They’re intangible, complex, messy, hard but important.
Before you dismiss them as unimportant and too hard, think back to your own experience as a more junior developer. What was the working environment like? Did you feel part of a team, or in a constant battle? Were you supported as you climbed the ladder, or were you undermined or ignored? You’re more of a provider than a consumer now – it’s your responsibility to contribute to the health of the team, and not just to the code base.
Also, your horizons will broaden, to other teams and other kinds of people. As I progressed in my career, I learned about what my sales, marketing, support, documentation, operations, and management colleagues did. This wasn’t because I wanted to do their jobs, or was expected to, but it helped me to do my job. It helped me better understand the interfaces between me and my team on one hand, and the rest of the organisation on the other.
Benefits of experience
Hopefully, over your career you’ve picked up general principles, that help in novel situations where everyone’s a novice. In many ways, what we’re doing is engineering, which involves the balancing of competing constraints. Each bit of code is a trade-off. Experience helps with that trade-off, because you’ve seen the results of previous trade-offs (but see the previous section with the graphs in).
You’ve possibly seen previous Latest Shiny Thing come and go. You have a fuller perspective of the pattern of things in software development, so you’re able to put shiny things in their proper place. You aren’t blinded by the benefits, and so can see the costs and limitations too.
How more junior developers can help you
If you try to win and be right every time, if you see yourself as the only valid source of technical ideas, then you will miss on ways in which people more junior than you can help you. This is beyond just doing their share of the day job:
- You can’t keep your finger on every pulse, so they might learn about a useful new thing before you do.
- The ground might have shifted since the last time you considered and discarded an option, e.g. storage costs might have got cheaper or the relevant tool might be easier to use or have more features. The fact that you were right to say X == bad in the past doesn’t exclude the possibility that X == good is true now, and junior developers can remind you of X so it’s re-evaluated.
- You can’t be expert in everything. More junior people might be better at something than you are. That doesn’t mean you’re worthless, that you’re soon going to be unable to do your job or even be out of a job.
- You aren’t infallible. Yes, even you make mistakes sometimes. If you create an environment where more junior colleagues are fearful of contradicting you, they won’t point out your mistakes.
Pulling rank
You might think that I’m advocating that you’re just a completely chilled out doormat, which isn’t true. I think it’s right for things to matter to you, which can lead to differences of opinion – some of which can be intense and not always resolved quickly and easily.
I think that pulling rank – using “because I said so” as a persuasive tool – should be a last resort and not a first resort. It’s important to note that it’s still an option – you’re paid to be a senior programmer, not people’s friend. (That shouldn’t forbid you from being their friend, and I hope you can get along with your colleagues, it’s just not your top priority.) You are a (small) part of the company’s leadership, and part of that leadership responsibility is being prepared to be unpopular if you think that’s in the best interests of the company. It’s not anarchy, but nor is it a dictatorship.
Summary
In this area, as in many other areas, simple answers are wrong and better answers are complex and messy. This is probably because life (and the people in it, including me) are complex and messy. I encourage you to use UX skills to put yourself in the shoes of your colleagues the next time you’re tempted to whip out your mental pack of Top Trumps. How would those around you want you to act?
Random Tech Thoughts 