Simplicity always wins

Software engineers love complexity. Complexity is an inherent part of writing software because the medium itself (programming languages) is complex on its own. When you put together with it the discipline of doing software engineering, where you add time constraints, customers, budgets and changing requirements… well… it’s complicated.

Some of the technologies are in fact, so complex, that some job postings require decades of dedicated full-time experience with the technology to simply be considered qualified enough to apply - C++ game develoment, embedded systems and some financial trading firms come to mind, to name a few. All of this just adds to the complexity of our daily craft, and, while in recent years, the accessibility to get new people into the field has been praised for “making it so easy to get started”, I believe that is actually harmful for the industry in the long run, and reasons are twofold:

  • first, ease of accessibility can’t be a synonym for “ease of becoming a professional”. There is a big difference between cobbling together a few tutorials and attending a coding bootcamp and becoming a professional software developer whose code a certain business or client will directly or indirectly depend on. This is the biggest misconception prevalent in today’s industry, sadly spread on podcast platforms and social media by a few people who somehow got “an audience” after attending a coding bootcamp or starting a podcast and spread their journeys like gospel. Don’t be fooled. There is much more to the craft than having a successful podcast or having completed a few JS bootcamps. Heck, there’s more to the craft than simply working on the web side of it.

  • second, the accessibility bias spreads like wildfire, and, sadly or not, most of it seems to be centered around JavaScript/TypeScript and NodeJS. This is precisely because this is what these bootcamps will teach, and what people on Twitter deem to be: the easiest to get into, the easiest and surest way to make money. This creates the very dangerous belief that its all about the technology you choose.

Have you ever wondered why there aren’t any bootcamps teaching The Real Stuff™? You know, software estimation, proper architecture, requirement scoping, managing client expectations, etc? That is because, these aspects can be seen as part of the social side of software engineering, where human interactions define how things evolve and move forward, and that, fortunately, can’t be “sold” or “bought”. It can’t even be taught, it’s just knowledge that can be transmitted, but, unlike hard-skills like coding, it can’t simpy be learnt by osmosis.

This is the real stuff and you can only learn this by doing it. By being involved, by taking part in discussions, and, more importantly, by working in a team on something larger than yourself. Be a contributor to a larger mission.

By working at a product-based company, the biggest thing you will learn that not a single bootcamp or tutorial online can teach you, is that software engineering is about people, and for people. You will gain the understanding that your code is translated into a given feature within a product and that feature will make someone else’s lives easier, by automating some task they needed to perform repeatdly before, and, thanks to your work, their lives are simplified now. This is truly the crux of the matter: it’s all about people. And, people are complicated enough on their own, so, it’s only natural that software engineering follows.

Since this is all about people and about outcomes, remember that it pays off to keep things simple at the technical level. Don’t blindly follow trends or cargo cults if they can’t help you with your direct and most immediate problems that you can actually help your customers with. Depending on the level of maturity of a certain business, or, for example, if you want to validate your own business idea, remember that customer feedback is the most important thing you can collect, remember that performance is never a problem, until it needs to be and remember that it can pay off tremendously to not overengineer anything from feature implementation to your own tech stack or the tech stack being used at work.

People love validation and, validation is best gained when it can be seen or experienced firsthand by the people who will be using your products. The complexity appears only as a derivative of the engineering process of creating customer value out of the code, but, that complexity is well within your control and it can be managed to be kept to a minimum.

For many of my side-projects, I am both creator, stakeholder, customer and, 99% of the time, the sole user of it. Sometimes, I can make some small simple web apps used by me and my family and a few friends very sporadically, basically, 0 traffic. And, in these times, the best thing I’ve learned is to stick with the simplest thing that can possibly work and just leverage that to its full potential.

By doing this, I can focus on building something that is of use for me and my family and friends, without being slowed down by details or unnecessary complexity.

You would be surprised how far you can take a project hosted on Heroku free tier connected against a simple DB instance. In fact, it might be robust enough for the first few dozens of potential clients you would have, and, if you can lay the foundations based on tested and tried technology and iterate from there, you will be in a much better position to be flexible with your own code and to respond to client requests. Simplicity at the code level will, usually, percolate to simplicity at the “customer level” meaning that you can more confidently say that you can meet any demand or adjust to any situation and always be in a position to evaluate trade-offs, because you’ve kept things simple.

Simplicity is key to agility. Agility allows for faster feedback loops and faster feedback loops allow for faster client validation and satisfaction.

And that’s what software engineering is all about! Keep things simple, to move fast and with confidence.

Written on November 29, 2021