Software Engineer

I am a software engineer. What I'm not is a programmer, or a developer, or a coder, or a ninja. Simply writing code is the easiest part of developing software. Anyone can write a competent for loop given a day or two of training. The difference between that and engineering is in setting up the project so that development can be done sustainably at a predictable pace and at a high level of quality. I'm often asked what I would look for in a new opportunity. What I want is a team and a culture that prioritizes those things. Not having them leads to missed deadlines, frustrated teams, and burned out developers. Companies are usually looking for people who are "passionate" about building software. This is how you keep that passion from turning into a chore (or worse).

So, how do you actually do that? Well, I've written about it before and I'm sure I will again in the future. But in general, it's about all the things that surround actually writing code. Broadly speaking there are two components: testing and process.

Testing is pretty straightforward. There are a lot of styles of testing, but the really important thing regardless of the level of testing being done is the team's commitment to them. When there's a deadline coming up, or you're just feeling off one day then it's easy to skip out on writing or running tests. What's needed is for the whole team to keep each other honest in that regard. Tests should never be optional.

Process is a little more complicated, but it still comes down to commitment and discipline within the team. I prefer an agile philosophy, and the central idea of that is to collaborate across different roles and among all the stakeholders. And then to schedule work so that it can be demonstrated and reviewed often. Responding to change is a core component of a good process. That demo and review process should provide frequent opportunities to reorganize priorities or change requirements. But outside of those windows the team needs to be able to focus on the work they have planned and to reject any changes that would be disruptive to the plan.

Assuming all of that is in place, then writing code becomes easy. Problems get surfaced quickly. Everyone has a chance to understand the problem they're working on, and how the application addresses that problem. That means I can understand how changes should interact with the existing code. I can anticipate future requirements. I can reason about the merits of one solution vs another. I can make more informed decisions when some trade-off is necessary. Basically, I can work at the same pace on day 100 of a project as I did on day 1. I can make realistic estimates and deliver consistent and predicatble results. And that makes everyone's life better.

That's the difference between a software engineer and a programmer or developer. I don't even know what a code ninja is, but it sounds like a bad thing to me. I don't just make software, I make it easier to make software. And that's what I look for when I'm considering new opportunities. A team and a culture that values that kind of quality and consistency, and is willing to do the unglamorous work that it takes to achieve it. It's the software development equivalent of eating your vegetables.

Update, June 2019

Even more about me.