It’s probably natural to get a bit contemplative as one year rolls into another. In this post I’m going to spend a little time writing about some of the things I’ve learnt after a year moving into a “Senior Engineer” position, and then onto some of the things I hope to change going forwards, based on what I’ve learnt.

As a result, this post is going to be a bit introspective and not very technical - hopefully it won’t come across as too self-indulgent! I personally think it’s sometimes interesting to read about things from this perspective, but feel free to turn back now if that doesn’t sound like your cup of tea! 🍵

The Background

To begin with, I’m going to need to do a brief bit of scene-setting. I work for a large UK-based retailer and mostly tackle things in E-Commerce. At the start of 2020 I had recently switched from a job with “Architect” in its title into a position with “Engineer” instead. This was a deliberate choice as I missed the hands-on detailed involvement you get when actually building something. My career choices to date have always been focused on what tend now to be called “Platforms” - as well as building stuff, I also like working on systems that are large & foundational, and love being able to see what else is going on across lots of different areas … and then influencing the bigger picture. Cake, meet Eat It 🍰

The year just past is 2020, but I didn’t mention Covid-19, which is clearly still a horrific pandemic which has very much affected how we work. Oh, and I became a father for the first time, which was both awesome and life-changing! On top of that, our house nearly burnt down, leading to the loss of most of our belongings …

Yeah, this latest season certainly had some interesting plot twists

Those things do matter for this tale, as they affected how I work, and had a significant impact personally on the amount of time I could devote to my profession.

What Have I Learnt

So with that in mind, what are the new things I’ve learnt or have been reinforced for me over the course of 2020?

I went into the year thinking I’d write more code. I was now an engineer after all - that’s what we do! And I did, but only a little and to be brutally honest not nearly as much as I wanted to. Even though I’d moved from Architecture into Engineering, I couldn’t escape the fact that I had still been around in the company for a comparatively long time, built up a reputation, been involved in some big ticket stuff, and so on. These are things that - despite having a reasonably flat structure in the company - lead to words like “senior” or “lead” being thrown around. And with that responsibility comes a few inescapable truisms that I had underestimated:

1. Your opinion matters. People tended to be more interested in my thoughts on things than I had previously realised. This was probably the most significant thing of all that I learnt and tends to go hand in hand with: you will go to lots of meetings. This is the nature of the beast (although don’t be afraid to challenge when you don’t think those meetings are valuable of course). You need to have a good handle on what is going on in your company and your field so that your opinion is actually an informed and trusted one. Being able to do this instead of just trying to blag it takes up a lot of time.

2. Someone needs to make a decision. If people think of you as the lead or a senior person, then think about whether that someone should be you. I would increasingly hear from people that they appreciated it when I would facilitate and, when needed, actually make decisions on things. It is super-awesome-sauce when you can get consensus as a group, but sometimes someone has to make a call on the direction to go, or when to compromise on quality to get something out the door or fixed (oh, hi there technical debt), and own that decision (whether it turns out to be a good or a bad one). This outcome also contributes to lots of meetings too, of course.

3. You can’t know everything. You need to understand how the pieces fit together; you need to know the general trends in your area of specialism; you need to know the common pitfalls to avoid - but if you think you can know all the details about all the things then you are more than likely making a rod for your own back. A much better option is to trust your team.

If they’re as awesome as my team then they will know a lot more about the details than you do, and be willing to share that expertise

Listen to their advice, facilitate good healthy discussions about the topic at hand, and if consensus can’t be reached then make a call on what to do and be clear on why you’ve gone in a certain direction. This comes with so many benefits - your job becomes significantly easier and you build up a relationship of trust with your team, who hopefully feel valued and that they can contribute to the product as a result.

4. It doesn’t have to be you. I believe that the value I tend to provide is more often front-loaded - the early inception of ideas and helping make them reality, in shaping of features and helping set realistic outcomes for delivering them. This probably at times feels a little like Product Management but the ability to do this in a way that ensures engineering quality can be maintained is I think very valuable and something I initially underestimated.

My day is less about pulling cards across the board and more about creating the cards in the first place, or making sure that they are in a pullable state. My to-do list is mostly littered with “try out X to see if it does Y” or “investigate whether Z is worth actually building around”. This is exciting and fulfilling work.

There is a trap to avoid here also - the risk of losing sight of work in progress. It is helpful if you’re still there and available to help if the work gets caught up in knots or to spot if it’s going in a direction you didn’t expect. I can think of examples through the year of both where I managed this successfully and where I didn’t do this so well.

Whilst I went into the year thinking I’d write more code - which didn’t happen as often as I thought it would - I did read an awful lot more code (and learnt a lot by doing so!).

5. You won’t get everything right and that’s ok. Try to put in place practices that help you avoid making bad mistakes. This is going to vary a fair bit, but in general I mean things like being directly involved in early exploratory activity to experiment with a new idea to really kick the tyres on it, and think about how its success (or not) can be measured as you go. If you work in an agile world then this ought to be bread ‘n’ butter to how your team works anyway.

Some Changes For This Year

So, after reflecting on the year that’s been, am I going to change my approach in any way? For sure - I have a few experiments in mind to see if they help me be more effective in my role in 2021. Some of my I-am-not-going-to-call-them-resolutions for the year are …

1. Set aside some dedicated time to do technical work. Block out time to experiment with new things, or just fix some defects, do some refactoring … whatever really. I’m planning to do this every Friday, and will fight to keep those days as free from meetings and chat as possible, so that I can properly get into things.

Without this, you will run the risk of losing track of what the problems in the codebase actually are that need fixing, and not staying on top of the new things in your field (techniques, tools, etc).

This ties back to both being informed in your opinions and also to aid decision-making - without it you’re fully reliant on others to help make sure you know what you need to know. Possible, but hard to cover all the bases and speak with the same authority.

2. Make time every day to take in articles, videos or tutorials. This of course ties back to having informed opinions on things and continuously learning. I’m going to start with what I think will be a fairly modest two articles/tutorials/videos per day, and see how that goes.

3. Blog more. This article is the first of these! I’m going to try to write about something interesting - ideally technical - once a month. Why am I prioritising this? Well, writing about things is a really good reinforcement of learning and chance to reflect on choices made - even if nobody ever reads them! It really makes you think about what you’ve done more carefully. Plus, I find it pretty fun to do 😎

4. Devote some time every day for code reviews. My team is extremely good at having a slick pull request procedure that very rarely leaves code unmerged for long - this has been a real boon during Covid times. I feel the biggest benefit this actually gives is visibility of changes - knowing what’s going on (for those informed decisions again …) and learning from others. I’m going to try blocking out the “dead time” of the first hour of the day to go through the previous' days reviews. Previously, I’ve been dipping in/out - this will be more of a concerted effort.

5. Be stronger in pushing back on meetings. Instead of almost always instantly accepting the invite, I’m going to stop and think about whether it really has to be me. Is a meeting needed at all - can it be covered in group/direct message conversations instead for example? Am I invited “just in case” or do I have something genuine to contribute? Is it a good learning opportunity for someone else to take the lead on, and I can be the sounding board if needed?

Summing Up

So, those are my thoughts as 2021 rolls into view. I acknowledge that this is a rather self-indulgent blog post to be brutally honest - if you’ve made it this far and took something of value out of my ramblings then I am very glad! I’ve personally found it useful to put pen to paper on some of these thoughts, and it’ll be interesting to see whether I’m back blogging about this in a year’s time reflecting on how phenomenally well / incredibly badly this plan went 😏. At least those objectives I’ve set for myself are measurable, right?