What Makes A Great Software Engineer?

Photo by Helloquence on Unsplash

This is something I’ve personally thought a lot about. Not just for the purposes of finding other engineers to work with, but also to discover a metric that allows me to better myself and my own skill set. After much thought this is what I’ve come up with…

“Given the same amount of time, a better software engineer will write less code. The best engineer will write zero code.”

— Elliot Chance

There’s three parts to this, let me explain…

1. Simplicity Reduces Code

It’s quite common for software changes to be fast and easy at the start of a project and become more difficult and slow as the project progresses. This is for a variety of reasons but one of those is usually complexity. As the software has more moving parts there’s more things to maintain, more potential for bugs, higher build and testing times… the list goes on and that’s before we take into account all the other less ideal things like poorly written code, business pressures and myriad of other things that push software inevitably forward.

“I didn’t have time to write a short letter, so I wrote a long one instead.”

— Mark Twain

Using more code is actually the lazy fix. It is often not the best solution, for now and in the future. Take more time to find a more simple solution, then hopefully less code is produced.

2. Experience Reduces Code

I believe software engineers go through three career phases:

1. Thrown in the deep end. We’ve all been here. This is when you’re new and absorbing as much as possible. You probably want to do the right thing by yourself and/or your employers but your lack of experience and time pressures make it hard to produce high quality software because you simply haven’t made much of it yet. You will (or at least should) make lots of mistakes, this is how you learn. Hopefully you are surrounded by engineers that give you the right support and guidance.
2. Too smart for your own good. This is when you think you have mastered your software stack, language or framework. It tends to produce software that is overly clever with a high focus on trying to write lots of code that reinvents the wheel, contains a lot of “magic” code or goes against the norm because “I can do it better”. Perhaps this is a natural over-compensation for all the mistakes made in the past, or a self-denial that allows us to justify that we don’t need to learn anything new. I know I am guilty of this more times that I can count.
3. Engineering maturity. If you’re looking back on your work and saying to yourself things like “Why did I make this so much more complicated than I needed to be?” or “Why didn’t I research how others have solved this before I had a crack at it?” and you truly understand these are actual flaws in yourself as an engineer then you can move on and write much better solutions going forward.

“Programs must be written for people to read, and only incidentally for machines to execute.”

— Harold Abelson, Structure and Interpretation of Computer Programs

I think one of the biggest misconceptions with software engineering is that we are coding machines. After all, that’s what we do right? Give us a problem and we’ll write you some code to fix it. I believe this is incorrect. Our job is to solve software problems to a level of quality and maintainability that suits the environment we are working in. That doesn’t always have to involve writing code. Code is the glue that ties together the rest of our experience and knowledge, it’s not the most important thing to focus on.

3. Understanding Reduces Code

What is the worst by-product of creating and maintaining software? Most people would say ‘tech debt’. Technical debt can be many things but a large part of it is the source code. I want to emphasise that it’s not always poorly written code. Standards, frameworks and even languages change over time. Code that was written very well at the time may simply be unusable or incompatible years later and require large refactoring.

If you have been writing code for several years I’m sure you could look back at an earlier time when all you wanted to do at the start of a problem was dive in and write some code. The drive to find the best technical solution is what makes most of us love what we do as software engineers. At the same time your former self will also admit that you may have dived in without fully understanding what was needed for the solution — this causes a lot more code to be created.

Code can not easily be undone, both while it’s being written and even more so after it has been published. Even the best written code will become technical debt at some point, even if it’s just the next engineer (or yourself) trying to understand what it does.

Communication is key. Not only between the engineers and the non-technical people driving the project forward but also between the engineers themselves. Generally, if you can spend more time finding a way that requires less code you have found a better solution.

In Closing

In one sense you could say the moral of the story is to avoid all your natural instincts as a software engineer. Maybe, but above all, KISS.

I understand that in a lot of this I am over generalising and over simplifying. There are plenty of exceptions to the rule. It’s also an unobtainable goal for a software engineer to write very little code in their day-to-day work. However, if you can write a little less, that’s a little less that can go wrong and lot less that needs to be maintained in the future.

Thank you for reading. I’d love to hear your thoughts and perspective, or any other unrelated feedback.

Originally published at http://elliot.land on July 9, 2016.