This is a really helpful distinction. I have worked across a few different jobs with differing expectations across this spectrum. The really lean startups want to get places quickly and blending together a dependency soup is usually the most efficient way to get there. More established companies sometimes have the resources to allow more R&D and home-grown libraries and tools. They are really different jobs in a lot of ways but we haven't done a lot to distinguish them in how jobs are presented.
I wonder if this distinction is going to be even more helpful as the low-code/no-code trend takes off and more jobs can be done by those with fewer skills.
> The really lean startups want to get places quickly and blending together a dependency soup is usually the most efficient way to get there. More established companies sometimes have the resources to allow more R&D and home-grown libraries and tools. They are really different jobs in a lot of ways but we haven't done a lot to distinguish them in how jobs are presented.
IMO the correct thing is to hire people who are good at both and know when to use which approach. Otherwise the learn startups will never be able to transition to established companies. And likewise, the established companies have many problems to solve that don't require home-grown tools, so you don't want people who only know how to start everything from scratch.
Maybe seed round/earlier you can’t hire those folks? In my experience, the engineer who liked being on an early team does not enjoy being part of a 100+ eng org. So dependency soup engineers churn and you end up with a different type of engineer when they transition to a real company.
(Clearly this is one perspective. It would be great to hire the best engineers from day one but sometimes that’s not practical.)
I wonder if this distinction is going to be even more helpful as the low-code/no-code trend takes off and more jobs can be done by those with fewer skills.