How to become an awesome engineer

One subject that always fascinates me and is something I have thought a lot about is what makes a truly awesome engineer. I think the real differences are quite subtle between a good engineer and a really great one — at least on a behavioural level.

Those differences applied over time result in someone very different though.

To be clear these are more ways of thinking and approaches to situations than they are specific talents. They are things that applied over time will result in a stronger engineer, a more useful member of the team and all in all a more capable individual.

I wanted to avoid making a big list of obvious things, and really focus on the 2 things that I think are either underappreciated or skipped over all the time.

Probably THE biggest thing that I think is under-appreciated and truly makes a difference is that of good diagnostics. By diagnostics I mean taking a complex problem, breaking it down, narrowing in on the issue and fixing it — for example an unknown system with a live issue, tracking down that issue and resolving it.

I’m sure its something everybody thinks they’ve got nailed, but personally I think its something people don’t work on enough and that I see little training or guidance around.

This actually spreads pretty far and wide when you really start to elevate it. Being great at diagnostics applies incredibly widely — fixing bugs, solving production issues, optimising for performance….even understanding your customers problems.

If I were to give a new engineer some advice it would be run at these types of problems.

Whilst others want to play with the new tech, the new language or framework, talk about design patterns or have philosophical debates — run at the problems and get great at finding them, then fixing them. Don’t see a system with a bug or an issue as annoying or boring, see it as an opportunity to hone your craft — they will be the moments that you truly build a useful skill-set.

I think there’s several reasons why this skill alone turns out great engineers, beyond the obvious:

Which leads me on to my second point

I wrote at length in my article “no more software sausage machines” about engineering being about creative problem solving, rather than simply writing code. The article was more focused around what that means and why we should care as an organisation, but here I want to address it on an individual level — why is this important to a prospective / up and coming engineer.

One of the most common misconceptions of the software engineering role is that your job is to write code…this may surprise you, but in 99% of circumstances the organisation you work for does not care about the code. They care about the problems the code solves, or the outcomes the code delivers — for the business, for your colleagues and for your customers. If you think that it’s not your job to care about the actual problems the code solves you’re absolutely wrong.

If you want to be a great engineer it is critical you understand this, that you understand why you’re in the building and embrace it. I can say without any doubt every great engineer I have ever worked with has understood and embraced this.

The implication is that you need to think more about the domain you work in, more about the organisation, the people in the organisation and the customers of that organisation. It means understanding the customer problems and the value drivers. This way you can truly understand why the work you are doing is important and what the desired impact is…you can challenge if something isn’t going to address the problem or even if the problem isn’t clear.

Most importantly if you’re going to be truly engaged and motivated then you need to align your motivations with your organisations. If all you want to do is implement the latest design pattern, and don’t care about solving your customers problem then there will always be an unhealthy tension between yourself and your organisation. That isn’t to say you shouldn’t consider and use those patterns, but more making sure you do so in alignment with the problems you’re trying to solve (rather than in-spite of those problems!).

Never forget — you’re here to solve problems, not be a code monkey.

The main reflection to take away is that the true difference makers in becoming a great engineer have little to do with technical skills, technologies, design patterns etc. They’re all about attitude and approach. Its easy to lose sight of that when you start learning and developing your skill-set.

I’m sure there are other important things that can make a great engineer that I’ve missed, but these 2 are things I’m very passionate about an in my opinion the real difference between good and great.

Related posts:

If viruses could think, they would surely regard humans as upstarts — late entrants to a crowded biosphere; blowhards, who believe they’re far more important than they are and certainly far more…

Invader. Darkness is uninvited yet he pours into my windows and whips around my neck, chocking me. He has become too frequent a resident of my soul….

Artificial intelligence (AI) is rapidly changing the way we live and work. From self-driving cars to virtual assistants, AI is being used to automate tasks, make predictions, and improve…