What I’ve learned in my first 5 years as a software developer

Today marks the five-year anniversary of beginning my software engineering career. Before then, I did undertake some work experience and completed some freelance projects — but I had no commercial exposure until I started my graduate scheme at Sky on this very day in 2012.

Rather than dive into some self-indulgent drivel, I’d love to share five of the most important things I’ve learned thus far; I believe that all developers should embrace them.

1. Throw yourself in the deep end

I remember my first day in the NOW TV Xbox 360 team. I’d just finished a 7-month stint on a graduate scheme, working on a number of small internal projects using Ruby and JavaScript. My new team, in contrast, used C#, .NET, and Silverlight. Needless to say, I had no idea where to begin; I covered C#, .NET, and a touch of XAML in the final year of my degree, but not to a commercially-acceptable level.

Although my colleagues were incredibly accommodating and helpful, I nonetheless realised that I had to get up to speed if I was to meaningfully contribute to the codebase. As well as working on tickets, I:

• studied the various aspects of the codebase and searched online for information on concepts that I didn’t understand
• paired with senior developers to gain insights into effectively implementing new features and refactoring others
• read books, documentation, and other literature covering: C#; .NET; Silverlight; design patterns; unit testing; and the software development lifecycle (SDLC)

Of course, one can only learn at a set pace, and as I’ll cover later, too much work will ultimately come to a head. However, by placing oneself on an alien project, one will naturally push oneself to work as hard as possible; humans are naturally curious creatures, and we thrive in new settings, regardless of how difficult the challenges ahead may be.

If somebody offers you an amazing opportunity but you are not sure you can do it, say yes — then learn how to do it later!

- Richard Branson

2. Be humble

Once one has gained enough experience as a developer, or in any other capacity for that matter, one consequently gains confidence, and is now in a position to contribute to more complex parts of a codebase, to open source projects, and to the community in general in a variety of ways, such as articles.

It can be easy to patronise others who may not have the same skill set, or general level of aptitude, as you. “That’s easy! How can you not know that?!” or “You obviously forgot to run the build script” may be tempting responses to simple questions, but remember that you were once naïve and lacking knowledge. Be kind and humble towards others as if you were at their level. Empathise!

Another important facet of humility is to admit when one is wrong. I’ve encountered my share of developers who, rather than admit that they’ve misunderstood a concept or take ownership of a problem they’ve created, attempt to bullshit their way out of a situation. “You’re incapable of understanding my work! I can’t be wrong.” Well yes, you can.

3. Listen and be open-minded, but don’t be afraid of demonstrating assertion

On the subject of humility, it is important to be open-minded towards both alternative points of view and new information regarding concepts and ideas to which one is completely new. While the latter case may seem natural, few people are willing to challenge their own views and ultimately alter their own positions; being malleable will allow one to refine one’s opinions and knowledge which can then be applied to a similar situation further down the road.

That said, there is nothing wrong with pushing back if one has experience within the domain of a specific problem and is therefore aware of common pitfalls and best practices. By demonstrating confidence and effective persuasion techniques, one might bring new information to the attention of one’s colleagues.

Being assertive does not make you an arsehole.

- Me

4. Embrace change, but don’t jump on the bandwagon

To a new developer, the rate of change that one witnesses might seem unmanageable; I would like to counter this by arguing that this is not necessarily the case.

In the JavaScript world, it’s clear that new libraries and frameworks are released regularly, and certain programmers (read: hipsters) will adopt them quickly without giving much thought to their applicability to a particular use case. One might therefore feel obliged to follow the emergence of technologies in order to continue to provide value as a developer.

I initially felt this pressure, but it’s completely avoidable when one views this in reverse. Whenever I’m starting a new project, I seek technologies from which it may benefit, and investigate them with the outcome of answering these questions:

• Does is naturally lend itself to my problem?
• Is it mature?
• Does it have a strong community?
• Is it well-tested?

This is by no means an exclusive list, but I’ve found that this mindset points me in the right direction. I was admittedly very cynical of React when it first emerged. “XML in JS?! Surely this is just a pointless abstraction of the DOM.” Then I tried it in a new role for an app that rendered large lists of items, which would re-render as a consequence of various interactions; it clicked that it was a great library for this particular application, and I thus realised how wrong I was.

One should definitely endeavour to be aware of new approaches, and to use them if appropriate, but there’s no obligation to use the new hotness for the sake of it; the main goal of software engineering is to, well, deliver software, and choosing the wrong tech could hinder this achievement.

5. Balance work and play

As soon as I wrote my first Hello World program at university, I almost became addicted to programming. Initially, my ability was limited, thus most of my code was ugly (but that’s OK; it’s part of the learning process.) Once I had worked in the industry for a while and became competent, however, I would spend my evenings and weekends working on all sorts of side projects, and I loved it. I felt that I had truly found my calling, and I just couldn’t stop.

Some of these manifested into relatively successful open source projects, as well as contributions to existing codebases. This really gave me a sense of self-esteem, so I kept going. I would enter JavaScript competitions, such as the brilliant js13kGames and JS1k, write articles, and go on to publish a screencast series for SitePoint. I even interviewed with some big tech companies, which resulted in lots of practice and reading.

By the end of this, I was completely burned out. I had lost all motivation and could no longer bring myself to program in my spare time. Furthermore, my other hobbies, which allowed me to escape technology when needed, were put on the back burner; I was essentially a code production unit.

It’s important to challenge oneself while one has the opportunity; these means not only enabled me to improve as a developer, but have really advanced my career. However, rest is critical. You’re a human being; your capacity to learn abstract concepts and work without sufficient breaks will naturally diminish, given our evolutionary origins.

If you feel burnout approaching, take a step back for a while. Not just for a week or so; I’m talking a month or two. Trust me, you’ll know when you’re ready to resume, plus your projects won’t be going anywhere.

Thanks for reading! If you like what you read, hold the clap button below so that others may find this. You can follow me on Twitter.