Using a library versus building internally is a tough trade-off and can have long term consequences. I think everybody is comfortable with the downsides of building. But we sometimes forget the costs of dependencies. My framework is that introducing a new concept whether written internally or through a dependency has a cost. Each class hierarchy, external tool, build system, etc. has a cost and we must weigh this cost against the benefits. Dependency sprawl is expensive especially in languages like Python or JS where libraries break backward compatibility on a frequent basis. I like that Rachel is bringing up the longterm cost of dependencies, they can often be more expensive than just writing a simple function or HTTP call without supporting libraries. Building may be cheaper.
Some people just hate managing systems they can't fix. Other people enjoy the challenge of reverse engineering complex systems and squeezing the best out of them. It is only reasonable to ask for the job expectations to be explained upfront. Rachel's post about onboarding https://rachelbythebay.com/w/2020/05/22/boarded/ goes into this idea in more depth. There's so many differences even in Silicon Valley. Companies should share more honestly what the day to day will be and their appetite for building. This would restrict recruiting funnels upfront but make people happier.
The problem is that inside a company there are many perspectives. The representatives of the build faction may achieve a temporary ascendancy and will obviously try to hire then and paint a rosy picture, but then the buy faction will see the hires and become highly incentivised to point out the lack of immediate results and trammel scope, causing the conflict Rachel is writing about.
But I don't think it's valued much on the open market.
As in, it's hard to be recognised for that kind of skill. Established, larger companies tend to have a structure in place and, at least on the open market, try to fit people into narrower roles. Even if there's a laundry list "tech stack", it's usually a narrow role.
As ritchiea said, it can seem as if the only place where the range is a good fit is at early-stage startups, with plenty to do and good judgement needed, but limited earnings on offer.
I think the OP has a fair point about one mode of development being substantially different than the other, but I don't think it's appropriate to partition them into separate roles. Part of engineering is knowing which path forward is most appropriate under uncertainty, given information about the team's skillset composition, available resources and time constraints.
A good software engineer is capable of holistically considering the options. If your third party library is considered like a paved road, this involves knowing when your vehicle can tolerate veering off the paved road, and knowing when you need to build a new road yourself.
Now maybe you read that and think I hadn't earned the kind of responsibility I was asking for. But 1) I had it at other companies previously, bigger companies than the last job 2) again, it was the type of responsibility they teased in the hiring process. I ended up leaving after a few months for a role at a company that actually offered me a leadership role with autonomy.
For some domains, the 80% solution is perfectly fine to launch with. For others, it is quite sloppy and you end up with paper cuts in normal use. Problems arise when you, as a consumer of a library, expect a 100% solution and discover it's only an 80% solution. Worse, most libraries do _not_ tell you what design decisions were made.
Having worked at a FAANG-level company in systems contexts, I think that most people with similar experience would say Rachel is spot on.
Yes, sometimes there are really solid libraries that solve the problem you are facing well, but often engineers will reach for a Swiss army knife when all they need is a screwdriver. It has a screw driver on it, but because there is so much else there (trying to be all things for all people) the screwdriver isn't even that good.
Moreover, solving a problem quickly is not the same as solving a problem forever, and we are responsible for every instruction we import, at some level. If the problem is small (see left-pad, etc.) the smaller total cost of ownership is often to write the specific implementation you need, if you are capable.
Multi-tools like Victorinox Spirit come with a ratchet and bits. Leathermans also have bits, but they typically attach directly to the tool and therefore suffer from the same limitation regarding ease of use.
Resources are one obvious constraint. The stage a company is at in its lifecycle is another. There was a time when Google had security issues so egregious that if you bring them up to current employees you will be accused of lying. Company growth rate is a constraint. Why solve a problem perfectly now if you know you'll have to solve it again in a year when the company outgrows the current solution? Employee workload and performance assessment is another constraint. Employees will only give the company so much time, and if the company doesn't allocate enough of that time towards keeping the house in order then the house will not be kept in order. Cultural stigma is another constraint. Sometimes people are not willing to say why they are doing (or not doing) something in a certain way.
If you file an internal bug, come away dissatisfied with the fix, and conclude that the fixer is some lesser-than-engineer who is lazy and doesn't care about doing things the right way you might be ignoring any of the above constraints or many more. Or they could be bad at their job. There are plenty of people like that in this industry, too.