James Cunningham

My Engineering Principles

January 2023

I’ve been a professional software engineer for twelve years now, and there are some principles I’ve come to believe and live by that might be non-obvious, or at least I haven’t seen written often enough. This is not intended to be an exhaustive list, or a mantra for anyone else to live by, just my thoughts.

I intend this to be a digital garden project, something that I curate over time, come back to and update as my views and experience evolve, rather than a one-off blog post.

1. Story telling is just as useful as writing code.

This is applicable to almost everything we do as engineers, whether we are writing specifications, proposals or documentation; and is probably the number one thing I repeat when I’m coaching other engineers.

Technology is a means to an end, we exist to solve some larger problem, and thus everything we do requires buy in from the powers that be within our organizations. The number one way to get buy in, is tell a story. Get people involved in your journey, get them to see your perspective, get them to champion you.

Every engineer learns this the hard way. We have a brilliant idea, but the organization just doesn’t see it, and shuts us down. This doesn’t mean you or your idea was wrong, you’ve just not told the right story.

Figure out who your audience is, and take them on a journey. What do they care about? What problems do they see? Can they even see the problems you see? If not, show them. Convince them this is pressing. Then, offer the solution. Don’t just offer a solution, convince them you are the one to fix this problem. Show them the better world you want to take them into.

2. Write code for your colleagues, not the computer.

This took me longer than I care to admit to realize. Computers don’t care, they will take your code, and run it. That is all.

They don’t care how perfect your abstraction is, they don’t care how optimized that algorithm is, they don’t care about that variable name.

Do you know who does? Your colleagues. Those you work with, those that review your code, those who come after you long after you’ve left the organization.

Write code for them. Write code for your future self. Write the code you’d like to be reviewing.

Last updated January 2023