[smoll]

Imagine you’re working at a startup and trying to solve a tough real-world problem by creating software that involves writing some CRUD APIs. You bring on someone to the team who says, “we gotta stop writing these pointless CRUD APIs and write compilers instead.”

I’m not trying to be dismissive, but I think this actually well illustrates the central tension between engineers who are more interested in the business problem and ones who are more interested in solving technology problems. I know that when you get to a later stage as a company you need both kinds of engineers, but at an earlier stage company you have to ensure all of your engineers are of the former kind and not the latter kind or you will probably not succeed.

[Fiahil]

I work as a consultant, and we are also looking for talented people interested by solving business problems.

We actively avoid the technology-focused kind, because we know they will not be able to adapt to the work we do. To be honest, we write a ton of CRUD apps, but anyone who would come and say "let's write a compiler" is guaranteed to get funny looks. Even if you are extremely talented and can deliver to the same pace as we traditionally do, you will probably fail to consider one or two "little" things that would turn out to be fundamental requirements! Nobody is impressed by half-working cleverly written software.

[feoren]

It sounds like you're categorizing me as one of the people interested in solving technology problems more than business problems. In fact the opposite is true, to the extent that I've become a go-to person for questions on the domain I'm working in, even without any programming context around it (e.g. a senior technical review of an Excel document in the domain). I've become a recognized subject-matter expert in multiple business domains. If I'm not focused on solving the business problem, I don't know who is.

In fact it seems like it's quite the opposite: people who think in terms of loops, conditionals, and objects seem to be happy writing repetitive CRUD APIs all day. People who think in terms of business logic want to write business logic. You don't need to write your own compiler (it's weird that this became the thing I supposedly suggested), but you do need to develop good abstractions and data structures that fit your domain to get your code looking more and more like just a spec in the domain language.

The "don't reinvent the wheel" people who want their programmers to just bang out repetitive API code all day aren't any closer to the business logic than I am. They just don't understand what makes good software, and they don't realize that the wheels that are available to them out of the box actually suck for their task and always need some modification.