Exploring common themes in a software engineers career
Often, when a manager leaves a team or company they can take the history of their teams and what was achieved together with them. This is particularly acute when it comes to the infamous annual review. It’s not unheard of for an engineer to receive a yearly appraisal based wholly on the previous three weeks of work under a new manager.
During my final few weeks at Funding Circle, in a bid to do something about this, I sat down and wrote a short page for each of the engineers that I had been managing, summarising their contributions and also adding some more far-sighted feedback that I hoped might be of use.
I wanted to make this as useful an exercise as possible so, in each case, I tried to set aside time to think deeply about the person to target my advice to their needs, circumstances and what I knew about their desired direction of travel. In short, I was going for a bespoke, personal touch.
As with many such exercises though, the outcome was not what I had expected. Rather than a set of bespoke advice, there were clear themes that emerged in relation to the level and experience of the engineers in question. So this post is a distillation of that advice, advancing from that most pertinent to a junior engineer to those at a more senior level. To you the reader, I hope that somewhere within this bundle of subjectivity there is something that strikes a cord and proves useful.
👂 Listen to Your Anxiety 👂
I’ll put this bluntly first, anxiety and fear are most often symptoms telling you to talk to someone.
Imposter syndrome, feelings of inadequacy, worrying that you might break the build, not wanting to bother the “senior” engineer. There is no doubt: anxiety can be debilitating but as with so many problems of the mind, with a change of perspective, it can be a driver rather than a blocker.
Specifically, when you experience any of the above as a junior engineer (or as a new employee in an unfamiliar environment) you need to have a conversation with someone who can remove the reason for your anxiety. Which, most often, is because you lack knowledge that they have. Fear is offering you a path to grow by developing a relationship with one of your colleagues in a genuine way and through the acquisition of knowledge that will instantly make you a more experienced engineer.
Now to the argument that you may be bothering and/or annoying this "senior" engineer. It’s nonsense! Mentoring is one of the best forms of learning and perhaps the most solid way of embedding information in your long term memory. It is also worth remembering the fact that most behavioural psychologists will tell you that the fastest way to get someone to like you is to start by asking them for their help. So the next time you feel like an imposter listen to your feelings and go have that conversation. You’ll be doing yourself and the other person a favour.
📖 Focus on Knowledge That Lasts 📖
There’s some bad news here: much of what you are learning on the job is a complete waste of time and will be irrelevant in a few years. Learning a new language for a job is fine, learning a new framework to be productive at work is encouraged. But those caveats aside, as a relatively new engineer I would strongly recommend not spending your time learning new languages and frameworks/libraries. They are the software equivalent of fast-food. If you can learn from anyone, follow the example of Warren Buffet and look for information that has a long half-life, that is, information that will be almost as relevant in ten years as it is today.
What does that mean practically? Instead of learning a new language, learn how to build a new language. Instead of learning a new library, could you try building your own library?
This problem is often compounded by the fact that you will spend most of your work life solving problems at a particular level of abstraction. Take your time to delve into the levels beneath. Understand them and you will find that your ability to solve problems will grow exponentially. This advice continues to be relevant for the rest of your career and is one of the few ways I know to maintain that excitement that I hope we’ve all felt at times programming.
🤓 Get the Basics Right 🤓
Ok, so you’re a senior engineer. You are a superstar coding ninja. You solve problems elegantly using the right tools for the job. There’s just one thing, well actually a few small things. You tend to be late to meetings often citing that you didn’t realise they existed in the first place. You tend to forget to put leave in team calendars and/or switch your on-call time at the last minute. You often have to be chased multiple times to complete small administrative tasks or company mandated training. We get it, you’re really focused on solving problems and delivering value and really none of these are deal-breakers plus you respond well to feedback but...these issues persist.
The problem for you personally is that these are the things that everyone sees. They are more visible to those you work with than your code and rightly or wrongly they create a perception that you are not reliable or professional. As a senior engineer you are also a role model to others in your team and are influencing their behaviour.
There is good news: this is so easy to fix! A little bit of technology and some tried and tested productivity techniques will ensure that from now on whatever the job is you are getting the basics right.
Have a todo list (Todoist is great) potentially enable calendar and on-call notifications in your browser or on your phone. 95% of all issues have now been solved. Even better, why not take the same approach you apply to technical learning and spend some time focusing on your personal productivity? Search out articles and new techniques and apply them to your work. If you’re an analogue kinda person perhaps Bullet Journaling is where it’s at. Try it, you might find that those annoying administrative tasks that you had sitting around in the back of your mind just fade away allowing you to really focus on what you enjoy and to have more headspace generally.
📢 Marketing Yourself 📢
While it’s always good to question stereotypes they often contain certain truths that are worth paying attention to. For today’s stereotype: the introverted software engineer. It’s usually balloni but the grain of truth that I want to examine is the engineer that does fantastic work that no one else knows about or sees.
You’ve probably heard the saying, "If a tree falls in a forest and no one is around to hear it, does it make a sound?". Well, this becomes particularly relevant as you become a more senior engineer. You are more self sufficient and able to solve problems on your own which is awesome but now there can be a tendency to just burrow away fixing, tinkering and improving without making your contributions visible.
Think about when you were a more junior engineer, you would often need to talk about your work with other engineers to reach a solution. The fantastic side effect of this was that your work was visible to others on your team. How do you achieve the same thing as a senior engineer?
For a second, think beyond your current day job: you’re at the level where with a good idea and some serious evenings and weekends you could pull together a pretty sweet SAAS business. But where do the majority of SAAS businesses fail? Sales and marketing. The idea may be great, the work you’ve put in may be second to none but if no one knows about it of course you’re not going to get any customers. So this is a skill that you need to learn!
Now let’s come back down to earth and move back to the realms of our day job. How can you make your work visible? It’s a case of finding efficient methods of communication. When I first say that, most engineers look horrified at the idea of having to schedule hundreds of meetings. No, that’s not what I’m suggesting. Our friend the written word is what we need to turn to.
Good documentation scales really well, can be shared in multiple places and can also be digested asynchronously. Keeping JIRA/Trello/whatever boards up to date and filled out with concise, useful information that you can point people to and share fulfills the same purpose. Recorded screen captures - do you see the pattern? Do the work once, share again and again, no more meetings. In fact you might even be able to start getting rid of meetings. Wouldn’t that be great?!
🤷♂ Ultimately, all Problems are People Problems 🤷♂
We’re now reaching the peaks of our profession, senior even principle engineers who are able to have an impact across entire organisations. The horrible anti-nirvana at this point is the realisation that 99% of your problems are actually caused and solved by people.
That’s right, at this level to be effective you have to up the game of other engineers and engineers are, contrary to some beliefs, people. But it doesn’t stop there. Managers want the solutions you’re proposing built in half the time - no change in scope please. The actual stakeholders didn’t know what the scope really was in the first place and just had to make it up in a meeting scheduled at the last minute, so that will change. You have some junior engineers that have started committing code written using crayons and a bunch of newly minted senior engineers who have just read Clean Code at their weekly book-club and want to refactor the entire system. You thought you were on a technical track and yet these are the problems you have to grapple with. That all sounds a lot like leadership.
Getting more senior as an individual contributor is a funny kettle of fish. Isn’t leadership something for management? Well sadly for you the answer is: no. You are a leader and that means to be great at your job you need to expand your toolbox and pickup some new skills.
Good leaders know that they need to have the skills to handle different situations. That means you could look to classics such as Dale Carnegie "How to Win Friends and Influence People" or try to take acting classes to practice being disagreeable in the situations that require it (anecdotally - while everyone talks about the horrible shouty boss, something I am not advocating for, the majority of engineers temperamentally find being disagreeable one of the most difficult aspects of leadership). There are courses on motivation, coaching - there are courses on pretty much everything. Reflect on the type of leader you want to be and where your weak spots are (if you don’t know I’m sure there will be people you work with who will be happy to tell you) and then try to address those. Your colleagues will thank you for it.
They say (whoever they are?) that all advice is a form of narcissistic nostalgia and I would take all of the above with that caveat in mind. However, I hope that wherever you are in your career something here resonated with you. If it did, my job is done but I’d be a hypocrite If I didn’t finish by saying: If you have any feedback for me I’d love to hear it. 🙏