I Should Have Done More of That..

Five things I should have done earlier in my career as a software engineer.

Every now and then, I like to think back across my journey as a software engineer so far, and reflect on the things that went well and the things that I would have done differently knowing what I know now.

My first few years were spent as a frontend engineer at a local web agency, before doing a couple of years at a larger consultancy, eventually becoming more full stack focused out of necessity and picking up tech leading responsibilities. From here I joined the management track and have been fortunate enough to work with a variety of different teams and disciplines.

Not all journeys look the same, and that is ok! But here are five things that reflecting back on my career so far, I think I would have benefited from doing earlier on.

I hope this helps some of you who might be early in your careers in particular, but I think this advice might be useful for all :)

Take time to explore other disciplines

As mentioned, the first few years of my career, I was convinced I was a frontend developer and that was my speciality and discipline. In hindsight, the first five years as an engineer are one of the best times to experiment with different technologies, both to understand what you are most interested in but also to build up a strong picture of the landscape of product engineering.

As a manager, I have lead teams that have been working on technologies and part of the engineering process that I have never touched as an individual contributor (hands on). Having experienced the problems they are solving first hand would allow me to build more empathy and understanding quicker for what they are working on. This isn’t uncommon in management at all but from this perspective it would have been nice to have taken the opportunity to experience some of these technical problems.

Some of the best engineers I have worked with have a decent working knowledge of the majority of the stack, ranging from frontend to infrastructure. Of course, it is unreasonable to think that you could be an expert in all of these things, and as you progress into a more senior role it does pay dividends to focus down on a specific problem area - albeit I think this often happens fairly naturally.

Speaking to a friend, Yusuf, and hearing his experience of joining MoonPig as an associate engineer - I understand they have a rotation for the more junior engineers where you spend a certain amount of time in different teams working on different problems ie a backend team, then a web team and then a mobile team. When your rotation is finished, you can pick a discipline or team to align with on a more permanent basis. I thought this was a particularly interesting way of approaching this problem, and a great idea.

I often think how different my career path would have looked if I had spent more time learning on other areas. Where would I be now? Would I be doing different things?

Take the opportunity early on to understand what you love, and build a picture of the whole product development landscape!

Write more

I didn’t start properly writing about technical topics until I was a manager. Not because I didn’t enjoy writing, and not because I didn’t have a lot to say. In hindsight it was definitely a confidence issue on my behalf.

In 2019, I wrote an article called “Next.js vs Gatsby” and it was a deep dive into both React frameworks and what the pros and cons of each were. There was a lot of strong opinions flying around concerning both of these technologies, and my idea was to write something that really cut through that. I spent a fair amount of time researching to write as clearly as possible.

In writing that article, a couple of great things happened. Firstly, my understanding of both Gatsby and Next grew tenfold. To explain something clearly, you have to know it well and writing forces you to know things well.

Secondly, the article did well and there was a knock on effect from it. Across 2019 and 2020, if you Googled “Next.js vs Gatsby”, I ranked right at the top. People started reaching out asking me to speak on podcasts, my network grew on social media and my website traffic exploded.

I often speak to engineers who are starting out in their career, and they tend to be worried that writing articles is something that is reserved for the more experienced. I get the concern, because I shared the same thoughts - but this couldn’t be further from the truth.

When you learn a new thing, write about it! At the very least it will really drive home that knowledge and force you to understand the topic that little bit extra. I spend a fair amount of time writing about things I am learning even with the intention of not sharing it outside of my digital notes. But I believe in the power of writing to build greater knowledge, and this is sometime I wish I had picked up on sooner.

Network more

As an introvert, networking doesn’t come easy to me. I had (and still do) have a lot of social anxiety when it comes to meeting and being around people. I have gotten better over time due to necessity, but when I was in my early twenties I found it hard to even make a phone call.

My first real experience with networking happened when I started an Instagram account, and a LinkedIn account not long after that. In my mind, I thought networking was going to conferences or meet-ups, shaking hands with new people and socialising - it seemed an impossible task. Speaking on the internet for me was much easier than doing so in person.

I didn’t even realise I was ‘networking’ when I was building these online connections. I was speaking to engineers at similar points in their journey to me, as well as reaching out and speaking to people on LinkedIn - just happy to be speaking to likeminded people to me from the comfort of my own home.

Before I knew it, I had a decent group of internet friends and connections. The majority of my jobs have come through a mutual connection (other than my first role and Monzo, these are the only two places I have worked where I have officially ‘applied’). Of course, that doesn’t mean you skip an interview, but it does mean that you will often have someone fighting your corner in an ever growing competitive market.

Networking doesn’t have to be complex, it doesn’t have to be intimidating. Just reaching out online to similarly minded individuals and making new friends on the internet. Building those connections early on and helping people, will pay dividends when you find yourself needing a hand one day!

Less courses, more building

I have spoken many times before about the pitfalls of getting trapped in a cycle of tutorials. I spent a lot of time and money when I was starting on different courses. I would go through the material, feel super productive and knowledgeable when building along to the course and then when it came time to implement what I had learned I would become unstuck. It was easy at this point to blame the course, and then look for a new one that was going to solve the gaps in my knowledge.

Realistically, there is not a magical course that will make you an expert on a particular subject. There are courses that are better than others sure, but it’s the practice and the building and the getting stuck and figuring your way out of it that builds strong engineering chops.

Watching courses and never spending any time building is akin to watching people play an instrument on Youtube, and then thinking you can play it yourself. It takes practice to build the muscle memory, to know where to put your fingers, and to pull everything together whilst keeping time and rhythm. Programming is the same.

The sooner I realised this, the quicker I progressed.

Rather than courses, I would think about something I wanted to build and then build it. Either that, or I would look for real world problems to solve on open source projects that I knew would test my knowledge. This is a much more realistic and effective way to approach and solve a problem. The speed it which this helped me progress over courses was incomparable.

I wince at the amount of time and money I spent on video lessons thinking it was the route to all of my problems.

Read wider, earlier

I never got along with programming books. There was something about seeing lines of code written on a page, that just didn’t sit well with me - and I never found technical books to be particularly useful in me learning a subject. When I realised this, I stopped reading.

It wasn’t until I started as a manager, I turned to books to build my knowledge of leadership and management. As a less technical subject, I found books to be much more useful, my copies of “Making of a Manager” and “The Managers Path” well worn and full of scribbles sitting pride of place on my shelf.

Those books got me back into and enjoying reading. I started buying more books on more subjects, and it is surprising the amount of lessons that are applicable to a career in software that come from books that are not technology focused at all. I hold philosophy & psychology books as some of my favourites, and these are particularly useful when learning about the dynamics of teams and working with others.

As an example, currently I am reading “Black Box Thinking”, which is a look at the difference in various industries and their approach to learning from mistakes. On the surface, the lessons don’t seem particularly transferable, but as the book progresses the more “aha” moments I have and I see myself making connections with software. What could be doing better as engineering teams to learn from mistakes? What do we do well?

Some of the best books I have read have had valuable life lessons that are very applicable to a career in software, even though that is not what the topic is focused on. It also builds discipline, to sit down and read every day for half an hour to an hour, and that is something I needed earlier on in my journey.

—

If you enjoyed this or found value in it, please click the little heart below. It helps more people find my writing and I will be eternally grateful! <3