Two Types of Software Workers

May 5, 2025

Which Type of Software Worker Are You?

A large set of hiring mistakes can be avoided by understanding that there are two types of software workers. The first type likes to think and talk about how complicated a solution to a problem should be. This person is often highly opinionated about what this “should” is. My own experience tells me these people make up about 80% of software workers, and up to 100% at big cos that are not named SpaceX or Tesla.

The second type of software worker agrees to solve the problem quickly and solves it. Maybe this is the true difference between a software developer and a software engineer, but if that is true it hasn’t made its way into the public consciousness.

I will never forget the day I realized I was one of the former, and started my journey towards becoming one of the latter. It was the most important professional day of my life. I had just left a large co and joined a freshly funded startup as their ‘founding engineer’ alongside Scott - the 2x YC founder they had brought on to be the head of engineering. I spent one zoom call explaining just how much work developing product x would be to the business, when Scott pulled me aside.

Scott told me that our job was to make the business believe engineering could do anything. If we could convince them of this successfully, we would have a chance at succeeding in building an important business. I was stunned at how deeply correct he was, and just how far away my actions had been from living that obviously true and fundamental principle.

From that point on, when the business asked if we could do something, the two of us would say “yeah that will be easy” and get to work. We strived to deliver each solution within a week, and almost always did. It would take me a bit longer to understand at an intellectual level what I had realized at a fundamental level instinctually. Over and over again, we nailed delivering high quality solutions rapidly, and it was not an accident. There are three primary reasons I think this approach is so powerful:

Self-belief is paramount. In any competitive endeavor, self-belief is paramount. Organizations and teams each have their own collective version of self-belief. If a team starts from the assumption that they can use any tool on the table to win and use it with excellence, it is much easier to believe they actually can win. Creativity opens up and speed and excellence become operating expectations.
Complexity is an attribute of the solution. At the individual level this belief highlights the reality that complexity is an attribute of the solution to a problem, not the problem itself. If engineers at SpaceX can bang out dents from a rocket with a mallet just before launch, you can hardcode that setting that won’t need to change for two years. In my own case with my current product, the user base for each of the systems I run will likely stay under 1000 people, and each of those will stay under 1000 requests per week. This means that many of the solution elements required in mature production software solutions are not important to me (throughput, concurrency, memory management). Basic tools and patterns are enough. Type one software workers would choose to build my product as they know is right and account for those items, I have not and it makes all the difference.
In some cases (fewer than you would think), the baseline solution will be of a sufficiently high level of complexity that you will need to adjust your approach and/or expectations as you evaluate tradeoffs. In my experience this happens less than 10% of the time when working on features or products.
It opens your world outside software. Thinking this way opens up your world outside of software to do things that other people think are not possible. Solutions that don’t seem like they would scale do. Business and product decisions become the highest leverage tools in your engineering tool belt. Rather than sticking to ‘the right way’ when it is not working, you can simply discard an ineffective approach and start from the ground up.

If you are able to make this change, you will feel like the wool lift from your eyes, and your relationship with life will become more authentic. You will begin to make decisions that are right for you and avoid the common fiscal, relationship, and lifestyle traps that come with doing the things you “should”.

I have recently (accidentally) come across a simple heuristic for understanding which one of these two types of software worker someone is: by looking at how they react to the use of AI in creating software based systems. If the worker’s attitude is “AI can’t write good code” or some other non-real solution characteristic, they are the first type of software worker. The latter type, in pursuit of the solution, will have persisted past the first few challenges of using these tools and is currently using them to add significant leverage to their work. I have shipped extensive APIs that would have taken a month in a week, and iterated through 5 different UX layouts in a day. It obviously can write quality code quickly in a large existing codebase. I run o4-mini in full auto mode at this point.

If you are, like I was, in the first bucket - rest easy. Adjusting your attitude is simple. The next time you want to do something with software, commit to your counterpart or yourself that it will be easy, and do it in one week, no matter how large of a product or feature you think it is. Then figure out how to do it by the end of the week, and then do it. The secret is not to be perfect, but that this belief system will result in you performing more than marginally better compared to your current baseline. Good luck!