My personal engineering principles

2019-10-23

“What are your personal engineering principles?”

This is one of my favourite interview questions for experienced developers or engineers. Problem-solving approach and mindset are in my view more important than any specific technical knowledge in an engineer, and a good answer to this question evidences this in a candidate.

A typical answer (unfortunately) goes something along the lines of “Well, I strive for quality of course, and I write unit tests, and also I think documentation is, like, important.”

I received this answer a couple of times before realising that my answer wouldn’t be all that different if I didn’t give the matter some though!

So here are my principles; hey speak to my approach and mindset more than any specific practice. They could in fact probably be derived from a general starting position of scepticism and humility.

You are not so smart

I like to remember that my brain, although I it’s capable of some pretty neat stuff, has limitations. Any software system more complex than a pet project is likely too complex for me to have full, detailed knowledge of all of its components and all of its behaviours.

This is why I write tests. This is why I write non-obfuscated code. This is why I design systems to be failure tolerant. This is why I seek broad input on a problem, and the shape of the solution.

No matter how much it looks like it, ‘writing code’ is not your actual job

So easy to forget, because what do I spend most of my doing? Writing code.

My actual job is to learn things and solve problems.

Direct contact with users or go home

There’s a richness of information you get about your product/tool/system/whatever that comes from observing it actually in use that I’ve never been able to get any other way. What you learn from this doesn’t only relate to some narrowly construed idea of ‘UX’ – and even if it did, that is still valuable enough to make the whole exercise worthwhile.

What you learn from direct contact with users may cause you even to reassess fundamental assumptions you’ve made about what makes your product valuable, your data models, your non-functional requirements, and more. I like to do it early and often.