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
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.
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.
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.