Engineering thinking
More and more of us are building software, but how is that different to software engineering? And can we learn to think like engineers?
The barrier to building your own software has never been lower. With the explosion of AI tools, SaaS products and low-code and no-code solutions, more and more of us are able to do things that 10 or even 5 years ago you would have needed a dedicated engineering team to accomplish.
I like to distinguish between software building and software engineering, because to me software engineering is so much more than just building something. Whether you’re writing code or using software tools to create apps or bits of functionality that make life better for yourself or others, getting something built is quite often the ‘easy’ bit.
If software engineering isn’t just building software, then what is it? Different people will have different answers, but for me, engineering is a mindset. It’s about bringing a level of consciousness to creating software that extends beyond simply ‘does it work?’.
I believe this mindset is not only available to professional software engineers. Because it is our profession, successful software engineers learn and incorporate this mindset into our daily working lives. But more and more of us are software builders now in some way shape or form, and so the value and importance of the engineering mindset is only becoming more important in modern life.
My intention with Engineering Thinking articles is to share the parts of the engineering mindset that are useful and applicable to anyone using software to create things of value to themselves and others. These will often be unrelated to the actual building of software, such as writing code, although they may well touch on and include that. Instead, I will focus on principles, ideas and heuristics that I believe are useful and valuable to anyone who works closely with software, whether they are building it themselves or working closely with those who are.
My conviction is that promulgating these ideas more widely, and expanding the language and references we can hold in mind when thinking about and discussing software with each other, will lead to sharper ideation, more fruitful conversations, and better outcomes.
To start with, I will be focusing on the concept of optionality in software. Being introduced to this simple idea has profoundly changed how I approach and think about software, and I believe it is incredibly valuable to both technical and non-technical stakeholders alike.
As an experiment, I will be writing this article as a series piece by piece throughout this week. I look forward to sharing it with you, and welcome any feedback you may have along the way.