10 lessons I've learnt in my first 6 months as a Software Engineer

6 months, 115 stand ups, and 956 git contributions ago, I started a role as a Graduate Software Engineer for Alpha Group. Since then I have settled in to working life, and life in London, I've gone from getting on the wrong tube line on the way home, to knowing exactly where on the platform to stand so I have the shortest walk possible to the stairs when I get off.

Here are 10 lessons I learnt about Software Engineering, as I reduced my MSTTB (Mean Steps To Ticket Barrier) by 30%.

1. Nobody knows everything

During my first week, one the the seniors on my team told me I didn't need to worry about how the specifics of a service unrelated to my teams focus worked. I thought this was wrong. How could they, as a senior, go about their jobs without knowing the intricacies of every system the company has and their interactions. Well, it turns out they can go about their jobs quite well without knowing these intricacies. Nobody in the engineering team needs to know how everything works at all times, it's good to have a rough idea how things work, but it is frankly a waste of time and energy to learn how processes and systems that don't interact with the focus of your daily work operate.

2. Some people can know anything

Contrary to my first lesson learned, the top developers at my job have the incredible ability to know more about your work after a five minute conversation than you do after three days of working on it. They are masters of just in time learning, they posses a broad domain knowledge that allows them to identify what needs learning when facing the intricate details of a problem.

I hope to master just in time learning one day, if only I had a deadline to master it right before!

3. A blame free culture really means no blame

I have, unfortunately, made a few mistakes over the past six months, some have been more impactful than others, and some involved the spaghetti I made for lunch spilling into my rucksack. Fortunately for me, the people who work with me are understanding when it comes to making mistakes with your code and deploying bugs, although it has to be said that they were less helpful when it came to cleaning my rucksack in the sink. What has struck me the most about the help I have received after mistakes is the judgement free manner in which it was offered. Once a mistake has been made, there is no benefit to wasting time or energy assigning blame or judgement. Energy and focus is best spent fixing the mistake and rectifying any related issues. It much easier to understand how/why a mistake was made without those involved feeling persecuted or the need to be defensive.

It has required a large mental effort to adopt this mindset personally, but I've found the process of doing so is improving both my professional and personal life.

4. Perfection is the enemy of the good

There is a confession I must make, I am an Ego Driven Developer. Perhaps it is natural to try and show off, prove your worth, impress those around you with a unique clever solution, a beautiful refactor of some UI, or books worth of documentation for your pull request. But if a solution is too clever and unique, others may struggle to understand it and your code becomes a risk in itself, that UI refactor might look great to you, but have you considered how the other teams changes will work with it, and nobody is going to read a 400 word description for a 5 line pull request.

I've spent the last six months trying to stop my ego leading me astray, done and good is better than perfect and on going.

5. Write things down, a little goes a long way

I think you'd struggle to fill a standard A4 notebook with the notes I made during lectures at university, note taking just isn't the way I learn. Working in a job however, not everything is about you learning, it is also about doing. You might remember the outcome of a meeting but writing down the details means you're less likely to follow up for clarity. I might understand a solution myself, but if I'm not the one implementing or debugging it, that means nothing if my understanding hasn't been written down.

Above all of the benefits I've found of writing things down that I've found, is that putting something into words and reading them back forces you to test if you really understand something. I thought I knew what the company I work for did until I tried to explain it to my grandparents, then I found myself with more questions than answers. That's why I've started this blog, yes it is a nice tool for communicating my thoughts and ideas to the world, but it's an even better tool for testing the clarity and understanding of my own thoughts and ideas.

6. Software is a living thing and code ages quickly

They say one human year is roughly equivalent to five dog years, and I say that one human year is roughly equivalent to a software millennium, in which time the software can be expected to evolve into an almost unrecognisable species. Earlier I said that nobody knows everything, and I think on top of the other reasons I provided for that, a key factor is that it is impossible to know everything about a piece of software that is consistently being worked on by a team of engineers.

The great thing for my career is that a piece of software is never finished, there is always work to do, new features to be developed, new problems solved, and new upgrades to the tools and platforms that are being built upon. The bad thing for my sanity is that software never finished, there is always work to do, new features to be developed, new problems solved, and new upgrades to the tools and platforms that are being built upon.

7. Ask questions, then ask some more

Starting a new job in a new industry I didn't know meant there were a lot of acronyms I needed to learn, some tech related, and some industry specific. As I settled into my roles I was never sure whether a new acronym was industry specific, or a piece of technology I was "meant" to know about. Through a fear of embarrassment I didn't ask for clarity on all of these acronyms, and as a result it took me longer to develop an understanding of the topic.

I have now come to the conclusion that if don't know something, it is more embarrassing to continue to not know it than it is to ask a question and find out the answer. Often the process of asking the question gives me the answer before anyone else, there is nothing to be gained and everything to be lost through avoiding asking questions.

8. Most decisions involve compromise

Sometimes there is no clear winner. There is no path, solution, or answer that objectively better than the other choices. When the pros and cons between choices add up to zero, it is best to flip a coin, then go with your gut and compromise. Compromising on these decision is hard, it can feel like one more discussion or one more day planning can help you reach a satisfying conclusion about what is best. But ultimately that additional time spent deciding between two choices which ultimately lead to a very similar out come, is a compromise in itself, the compromise of starting later instead of starting now.

9. The value of time

There simply aren't enough hours in a day to do what I want. To have a productive day in the office, to exercise a bit, see my friends, work a bit on my side projects, watch whatever show I'm enjoying, spend time with myself, and get a full eight hours of sleep. Just like decisions in work require compromise, so does deciding how I spend my time.

I've adopted the mindset that my calendar, and how I spend my time, is the ultimate reflection of my values. Doing so has made me a lot happier. I now exercise almost everyday, but I am content sacrificing a run to go for a meal with friends. I find time to build my own side projects, but only when it isn't at the expense of my sleep and mental health. If my priorities change, which I know they will as my life progresses, then so will my calendar, and so will my time. I'm beginnig to discover how to best enjoy my time, and doing so is teaching me about what my values really are.

10. Everyone is rooting for you

I experienced a huge amount of anxiety and nervousness starting out as a software engineer, seemingly simple tasks would fill me with dread. Any message I sent to a big channel would be written, rewritten, and refined as much as I could. Even small deployments I was involved in felt like a high stakes game of poker. And any message about a mistake I'd made would sound negative in my head. The main thing I feared was not the mistake itself, it was the judgement the came attached with it.

As I grew into my role, I slowly started to realise that people aren't out to get you, my colleagues want me to be good at my job, it makes their lives easier. If I need help and ask in a public channel, I now view that as an opportunity for other engineers to help me, to improve their skills, share knowledge, and of course look good in front of their managers.

Conclusion: Always wrap up well

Another bonus lesson I've learnt is that wrapping up a meeting or conversation well, clearly agreeing on the outcomes, and clarifying any next steps, is a great way to create energy and motivation. So this is my attempt to do at a good wrap up for this article!

I am excited to see what the next six months of software engineering bring, it is a job and career I am thoroughly enjoying and I cannot wait to find out what it brings next. There have beens ups and downs, I haven't loved every day of it, but no day has ever been so bad it made me question if this was the right path for me.

I will continue to learn new lessons, develop new skills, and self assess regularly. Right now I think I am on track to build a fulfilling career and life, and to leave a legacy I can be proud of.