OVO Tech Blog

Tribes & tribulations: lessons learnt from 6 and a bit years a software engineer

Introduction

Laurence Bird

Laurence Bird


Tribes & tribulations: lessons learnt from 6 and a bit years a software engineer

Posted by Laurence Bird on .
Featured

Tribes & tribulations: lessons learnt from 6 and a bit years a software engineer

Posted by Laurence Bird on .

When I put together the title for this article, in my head it was going to be a five year retrospective- a nice clean career milestone. Strangely when I cross referenced my LinkedIn profile, it’s in fact been six and a half years (time does fly). Though this is not quite as nice a milestone number, I'd like to use this blog to take a look back on my career so far and hopefully provide some insights and highlight some common challenges I have faced (and still do face) working as a software engineer.

After graduating from University with a degree in Electronic Engineering, I found myself on a graduate scheme catering for any graduates with a degree in any STEM discipline. Having written some basic control systems in C, written a  simple game in python and dabbled with IOS a little at University, I felt very capable of taking any challenges my first day threw at me- how hard could it be?

The reality was much tougher than I had naively assumed, my first pull request had 100+ comments, none of which made sense to me (~30 of which I remember were single word comments: “whitespace”), and even forming the vocabulary to be able to approach colleagues and ask meaningful questions took a really long time. We all suffer from imposter syndrome but those new to the industry are obviously disproportionately affected by it. Navigating a new and unfamiliar industry can be mentally and emotionally taxing. In my experience we as engineers don’t talk enough about how hard building digital products really is. The continual and delicate balancing act of an infinite list of possible trade offs, alongside meeting goals and hitting deadlines can and does take its toll! Colleagues won’t always tell you how they are feeling and it can be so easy to misinterpret pull request comments, take feedback personally, or give feedback which could have perhaps been worded a bit more delicately. This leads me to my first and arguably most important point:

Look after each other

Check in with a colleague if you think they are struggling, make sure you take the time to explain things in person which could be subject to misinterpretation or hard to explain in an instant message, or pull request comment. Remain patient when explaining new concepts to those less experienced than yourself and don’t be frustrated if you have to repeat yourself, or if you’re struggling to understand something a colleague is explaining to you. A happy team is a productive team- time spent making sure everyone is happy, has a voice and feels safe in their working environment irrespective of their experience levels, background or ethnicity, is undeniably time well spent.

The scope of my role as a software engineer has massively changed since the first team I joined as a graduate. Deployments were managed manually and we had a Devops team who managed all our infrastructure for us. Our release cycle was 2 weeks and we had dedicated testers to support us in these releases (with a 3 day test cycle before every release). We had an Infosec team who were responsible for the security of our applications and generally speaking code was the main concern of a software engineer. Due to coordination between the various aforementioned teams, I can remember in instances setting up a simple hello world api in production taking 2 weeks.

Now in the age of the T shaped software engineer, a lot of the above responsibilities have been merged into a single role. With the progression in cloud technology and infrastructure as code, setting up a production application can be done in minutes. Full stack ownership is becoming more commonplace, and with the infinite array of modern application frameworks the speed of software delivery has become astonishing. Due to this it can be tempting to set up a new API with a narrow set of responsibilities, and in doing so miss commonalities in the concerns of your software, avoiding abstracting and simplifying in favour of speed of delivery. To summarise- things move and expand fast! This leads me to my second point:

Less is more

Code is a liability not an asset- the less code you have the better. The same applies to infrastructure, for both fiscal reasons and practical reasons (the more things you have the more things there are to break innit). Keep your code DRY, be realistic about what your team can support with the resources you have available to you, opt for hosted services when you can- aint nobody got time for debugging issues with self hosted CI servers.

The above principle is definitely governed by what is manageable for a team, and what is manageable can be hard to define. As an individual, warning bells should be ringing if you find yourself struggling to remember the responsibility of certain parts of your system, or if debugging is particularly time consuming and you find it difficult to get to the cause of a bug in your system. This leads nicely to my next principle:

Build a mental model of your stack and always look to expand it

I hate to think the amount of hours I have spent googling stack traces trying to get to the bottom of an issue. It’s important to make sure you take time to understand the technologies you are working with, whether that's the internals of a framework you are using, digging in to the runtime behaviour your language of choice, or taking a deep dive into the semantics of that message queue which is the backbone of all your production services. Having a mental model of your systems is so important, seek out opportunities to expand it and fill in the gaps when you can. It won't just make debugging easier, it will help you make more informed decisions about the future architecture of your systems, and give you a more well rounded view of the tradeoffs involved when making important engineering decisions. This also applies to your own code real estate, if you struggle to hold the systems you are responsible for in your head then there is a chance you need to rethink your systems architecture, or your approach to code design.

Whilst we are still just about clinging to Moor’s law, technology continues to grow at a staggering rate, and with it the choice of tooling for engineers to build software and deliver value. The choice of languages to use in production as an engineer continue to grow, each with their own paradigms and opinions. I often hear the phrase “strong opinions loosely held” thrown around, and sometimes it feels like having a strong opinion when it comes to software can be presented as a badge of honour (there are even evangelists who get paid for this!). Thus presenting my next point:

It’s okay to not have a strong opinion

With such a huge variety of tools and choice as an engineer out there, It’s easy for an individual to find a set of technology which fits within their way of thinking, and subscribe to that way of thinking- sometimes to a militant degree. I’m not saying it's bad to have opinions, but siloing yourself to being a certain type of developer I think is unnecessarily restrictive, or putting down certain languages or frameworks as inferior can be outright toxic. We are presented with so much choice it’s impossible to know which JSON parsing library of the infinite available out there is the best, and does it really matter which is!? This brings my next point:

Don’t subscribe to tribalism

Opinions drive design, and there are always trade offs in any design decisions. By subscribing to a fixed engineering ideology to the point of fault you are avoiding exposure to other views and schools of thought. Using the right tool for the job in all walks of life is generally the best way to go, by having a better appreciation of the tools out there as an engineer and learning from experienced developers with different views to your own you will be in a better position to solve problems. Don’t put up unnecessary barriers, go to conferences and meetups to expand your horizons, and don’t subscribe to tribalism!

To keep things concise here are a few further learnings which I thought worth including:

Architecture is temporary

Try not to constrain your thinking to your current architecture, sometimes to fit short term needs we have to build less elegant solutions but ultimately architecture is temporary. Think big, don’t be afraid to make drastic changes if the benefit is worth it and continually reevaluate whether past design decisions still make sense.

Experiment little and often

It’s easy to become comfortable with your current stack, but there are always better ways of doing things. Find opportunities to experiment with new design patterns, testing frameworks, or other technologies in a controlled and isolated environment and share your experiences with peers.

Take a step back and celebrate successes

Working in an agile environment we make small incremental changes over time, in retrospectives it’s easy to get bogged down with what you didn’t do rather than what you did.  This  can lead us to not really take the time to reflect on our achievements, and think about the accumulation of our efforts. Take a step back every now and then and think about the parts of your work you are proud of, extend this to your peers and give some positive feedback, spend your social team budget if you have one and hassle your manager for one if you don’t.

Make work as enjoyable as you can and show appreciation to your colleagues

Teams are temporary and things change, but (in pre-covid times at least) we spend more time with our colleagues than we do with our families. We tackle big challenges together as teams, learn from each other and subject each other to our annoying tendencies and quirks.

Have fun, whether that means buying silly hats to wear in meetings, playing games together online, starting a meeting with a ten minute chat about some pointless nonsense or playing questionable amounts of table tennis in the office. Some types of work are inherently less interesting than others but be open about this with your colleagues and make light of the situation. We are privileged to get to work with such a diverse range of interesting people within organisations which want to invest in building a great workplace, embrace it and show appreciation to those around you will be rewarded- Happy Christmas!



Laurence Bird

Laurence Bird

View Comments...