The two kinds of software engineer
I've realized that there are two rough clusters of engineers I've encountered. Understanding these archetypes helps rationalize why people make decisions in the way they do, and what makes them tick.
The artisan
To this engineer, the code they write is itself the end, not a means to some other outcome.
The fact that the software the artisan develops must sold or that there is a broader mission is just a economic reality for this engineer - it in its own right provides no motivation.
If you could design and develop high quality software with the right principles without needing to sell it, well that would be great and not detract from the experience.
These engineers care deeply about how you engineer just as much as what you produce.
In broader organizations, these personalities are essential to maintain long-term vision and high standards in a code base. Over time, bad decisions bring speed to a grinding halt and taking a bit more time up front can be immeasurably valuable.
In smaller startups where shipping fast and focussing on your user is essential to survive, I suspect it might be a challenge for the artisan, unless there is consensus on what is "good".
The unfortunate thing about having lots of people with intense opinions, strongly held is that if the opinions are incompatible then nothing gets done.
In a startup you want to ship quickly and having the "incorrect answer" and adapting is infinitely better than "doing nothing", and the strategy of the artisan can sometimes be untenable.
You need pragmatic "merchants" who aren't afraid to break a few things to reach an outcome and for whom decisions don't have binary "good" or "bad" outcomes.
The merchant/technical entrepreneur
The code is a means to an end for these people. Quality is important to the extent that it satisfies the user, and the code has as much value as the economic value it generates.
I recently listened to a podcast by some YC folks (Vibe Coding is the Future) on the subject of vibe coding.
I suspect opinons on "vibe coding" are a surrogate measure for how much of an "artisan" or a "merchant" you are.
Some main takeaways that they think is true. Emphasis on the they because we should keep their bias as folks building companies in mind:
- Using AI assistants and code generation tools is a no-brainer for going from "zero-to-one".
- Latest YC startups are generating 90% of their code using AI assistants.
- Going from "one-to-N" is still hard and requires traditional, "hardcore" engineering skills.
- Code has never been cheaper. You can rewrite more regularly.
These folks have a perspective that resonates strongly with the kind of person that sees coding as a means to an end - they want to build a business, and writing software happens to be a great way to solve the problem their business is tackling.
If you could solve the problem without programming, you would!
I think these personalities are clearly essential in small companies. A moderately successful business with product-market-fit rarely hinges on your choice of technical stack - Levels.fyi scaled to millions of users with Google Sheets as a database and Facebook did pretty well with php.
On the other hand, you see "artisans" begin to dominate at very large companies because business problems become bottlenecked by more challenging technical ones.
The "artisan" can be well-suited here since they can take a long-term view and the cost of taking time to make a better decision is much smaller; Instagram will still generate revenue if you ship your feature today or by the end of the week, but this time window might be existential for a small company with one customer.
Conclusion
It might read as if the artisan is the better programmer, and I want to emphasise that this is not the case. In fact this is completely independent from skill, and these archetypes only help to understand motivation.
As for me, I definitely skew towards the second category. The reason I got into programming in the first place was to build stuff for other people.
I derive a lot of my motivation from the outcome of the work, less so the process itself; I would feel little joy in producing a beautiful system with no users. That said, having a pure passion for the craft of programming is absolutely essential: sometimes building something that already exists, from scratch, is a great idea to learn something deeply or push the technical boundaries in a way that goes well beyond economic value. I do try to reinvent the wheel for things I really want to understand or read books to ensure I keep improving at the craft.
When debating technical topics, I've realised that sometimes it isn't the topic itself you are debating but the unwritten motivation each individual in the debate has.
This often leads to deadlocks based not on the technical facts, but personalities.
Recognising what each person values and can contribute helps find a way to thread the needle and find solutions that appeal to both the artisan and the technical entrepreneur/merchant.
I think these two kinds of software engineers have complementary roles to play and the best solutions often satisfy both the demands of business and good artistry in the long run.
Back