Artists and athletes who create and achieve at the highest level in their career have a fascinating aura. They make it seem as if it was so easy for them as walking in the park.
I feel similar about people who craft amazingly high quality products by hand. Melting and forming metal into simple shapes which are then bended and twisted together into an end product which leaves you in awe.
There's something to quality that you can always see and feel.
Before the industrial revolution it was the norm for most things to be crafted by hand and these products often lasted a human lifetime or even more.
Today it is rather rare and most products are manufactured in highly automated factories.
The machines used are fascinating themselves and there are bits and pieces that are still being made by hand but the drive for mass production and efficiency has inevitably made the overall quality worse and it's even part of the economy model to not make things that last forever.
It's an inevitable dynamic, which one may not like but it makes many things we take for granted in everyday life accessible to a growing population.
Also, it has - perhaps - changed the perceived value of manually crafted products.
Software can also be a product. Sometimes even art.
It may serve a useful purpose - or not. And sometimes it's even the bridge between human interactions on multiple levels. Communication, the exchange of goods for money, the idea of money itself.
Nowadays, software more often than not is an irreplaceable fiber that's interwoven into our everyday lifes.
So we should strive for and value high quality in software, shouldn't we?
In recent years, with the rise and ongoing sophistication of Large Language Models (LLMs), we've come to a point where something similar to the industrial revolution is happening to software development.
The domain of software development is one of mental work. It rarely consists of precisely repeatable patterns which will lead you to successfully building the thing you envisioned.
This may also be the reason, why it has always been perceived as very difficult and as if only smart and talented people could effectively do a good job in this domain.
However, since LLMs learned to code on command, this perception seems to have shifted. More and more people, who often don't have experience themselves in software development, come to believe that the task of developing software can be either completely automated or at the very least it doesn't require smart individuals anymore.
Why? Perhaps because the ability to write valid code is being mistaken for the ability develop a software application.
I'm not neglecting the power of LLMs in any way and I enjoy using them as a software developer myself, to ease my everyday work.
Funnily, software developers themselves are the ones who are celebrating AI powered coding assistants the most - while every other workforce would be terrified of a tool which automates their own job.
But making to code so easy for everyone, degrades the overall quality and undermines the reasoning why one should think really hard about actually making good software, when (perhaps) "good enough" is generated in seconds.
Why would you pay a craftsman to carefully craft a tool for you, when you can easily 3D-print it yourself in seconds?
There's a parallel to the addictive nature of "instant gratification"... does this ring a bell?
But does it really matter in the end?
Non technical businessmen or investors often get annoyed by engineers who they deem too perfectionist. And they do have a valid point. In business, perfectionism can be a curse and make a business fail.
For a successful business it is vital to focus on actually delivering value to the customers and not draining resources just for the joy of building something.
So, when these shortcuts exist, it is tempting to use them. Rightfully so.
The fastest and safest way to creating a good product is to gather as much feedback from actual users as fast as possible. That's possible if you have something functional to show them and let them try it themselves.
The way to do this, often is - or was - a design prototype. However, many people and I myself have found it to be kind of double the work.
You have to create the design. It has to be interactive, so people can try it and understand it. You have to make sure that what you design is actually feasible to do in code. Then you have to transform the design and UX from the design prototype into an actual software application.
And even then the result is still a prototype, because you by no means have knowledge of all the things that will change and most likely you were in a hurry when going from design to code. And if there are changes (and you want to keep the workflow intact) you start over by changing the design prototype.
Soon you'll have at least some diverging looks or features between the two. So you might as well do the prototyping in code directly and there you can easily leverage the advantage of AI powered code assistants.
The danger lies in mistaking a prototype for a product. And then, how would you argue with a non-technical manager that the dev team needs a couple of months to actually make the software good, when you can already click through and use it functionally?
This does not only apply to products that have some visual front-end but to all software. And it's often the reason why really bad code ends up in production and stays there forever.
Nothing is more permanent than a temporary solution.
When you end up with prototype code in production - without the acknowledgement that it is prototype code - you continue to build the product and new features on a flawed foundation.
I'm not going after the "obvious" and wide-spread argument of "it won't scale". This argument has it's own flaws and is a heated topic, because most of the times it leads people - especially engineers - to over optimizing for things that are just not relevant and might never become relevant for most products. Very few products need to support millions of daily users or terabytes of data being processed.
Even though performance does matter more than one might think. Oversimplifying things to "just make them work" can lead to poor product performance and thus users not liking it, but there's another hidden cost.
The ability to maintain or improve quality of the product, long term.
If your "product" consists of many generated pieces of code, which no developer cares about and no one feels responsible for, because it was not and won't be valued whether or not some deep thought has gone into it, who will care and fight for little details that make up the quality of the product in the end?
It's like a huge pile of trash that keeps getting bigger and bigger and management starts wondering why it doesn't shine like gold, like it did in the beginning. And worse, it will be blamed on the developers. Who might even have warned and protested against piling up trash.
The company looses it's best and talented people because it sucks all the joy out them and their daily work degrades to the meaningless and soul-sucking task of just writing code. At this point, the job can in fact be automated by AI - and it even should be automated, because no one wants to do such monotonous work.
What's the solution then?
People are not robots. Especially very talented people have their own values and beliefs, which often may have gotten them to the point where they have turned talent into amazing levels of skill.
There are many examples of opensource software libraries which are being used by almost everyone in the industry and these libraries were often created and are maintained by a single developer who has put his passion into creating the thing.
Software development is a craftsmanship. And to leverage the ability, to craft wonderful pieces of software, in business (to make money from it), one has to acknowledge this. As long as you let developers express themselves and their love for their craft in writing good software, you have very powerful allies.
I acknowledge that, if you are (only) a business person it can be very difficult to see and understand the difference between a software project that was just quickly prototyped to make it work and actually good software. And if you are "only" a developer, who loves to build things, it is difficult to prioritize what actually matters for the product.
Therefore it is an art to understand both worlds.
A good starting point is listening to and caring about the opinion of people. They will tell you, if you listen and value what they say. Don't employ an environment where only praise for how "good" everything is is wanted! Treat people as allies.
I believe, however, if you're a talented software developer with a passion for good software, it's actually easier for you to master the world of sales and good product management (that is, sculpting the product in a way that people love it).
Learning sales, is learning about people and relationships. That's something every human being should do and it benefits everyone at any age. But becoming an exceptionally good software developer is very difficult and it is getting even more difficult with AI pushing into this domain while everyone is hooked on the "instant gratification" culture.
I'm learning about sales and people more then ever and I find my experiences from building a startup for the last 5 years and being involved in software development for over 15 years absolutely invaluable.
I'm happy to finally share my thoughts with you.
You're welcome to join me on my journey!