[red_admiral]

Doesn't it make you the go-to person when something goes wrong, and someone has to debug it?

My own experience from a time at a SpringBoot/iBATIS/Hibernate etc. shop (so server-side not UI side) is that it's all well and good running on "rocket fuel" as the consultants say, until something goes wrong. Then at some point you need the person who understands HTTP and SQL and other antique stuff to diagnose the problem, even if you can fix it at the abstraction layer.

One of the problems we had one day, was that a particular script "just wasn't working" and it turned out the file was being sent correctly, but with the content-type set to "text/html" by mistake because someone's "clever trick" interfered with SpringBoot's "magic" so the content-type detection wasn't running the way you'd want. Easy to fix, but you need to know what's going on in the first place.

Over time I also developed a feel for code smells of the form `return SomeItemDAO.fetchAll().size()` which runs just fine on the test server with a few thousand items, then you deploy it to prod where there's tens of millions and the database is on a different machine. It turns out SELECT COUNT is a thing!

[mywittyname]

> Doesn't it make you the go-to person when something goes wrong, and someone has to debug it?

Assuming anyone cares enough. Alternative approaches include, ignoring the problem, working around it, or changing business requirements so that the feature isn't available anymore.

There are a lot of people in the industry that just throw up their hands at roadblocks they can't solve and say something is not technically possible. These people include "tech leads" or other high-level software roles at companies.

[amtamt]

> These people include "tech leads"

I have known a tech lead, one-self a java developer, who could not compile java code to class/ jar file that could be added to a docker layer in a pipeline.

[austin-cheney]

There are people who do care about that, but it’s astonishingly rare. Just consider it abandoned knowledge. Most of the people who continue to care about these things do so in open source contributions far away from their employment.

As a proof occasionally somebody will post something on HN about performance (asking for guidance, showing off a refactor, claiming performance is a critical must, whatever). I show them how to achieve load times of less than 100ms on a OS like GUI with full state restoration and the feedback is always the same. Either they can’t hire anybody who is capable of following that guidance or the juice isn’t worth the squeeze. Nothing in the guidance is challenging. It’s just not framework bullshit.

[rescbr]

> they can’t hire anybody who is capable of following that guidance

This is the main constraint when designing some solutions. Oftentimes I know the best path (or that something deemed impossible is completely doable), but it might be arcane knowledge and I would be the only one to know how it would work and be responsible to keep it working.

Bus factor of one strikes this right away, unless there are no alternatives.

[austin-cheney]

Again, it’s an economics problem. More specifically what you are addressing is not an availability problem, as everyone most commonly believes, but a selection problem.

Seriously, think about this logically. The compile target of the browser is the DOM. What is it these developers are so deathly afraid of: the DOM. Yes, it is raw emotional fear processed in the amygdala, qualified with poorly formed bullshit excuses. So, what about this induces fear? It’s not the technical challenge, because it’s not that challenging and easily taught to non-developers. I know this from experience. That’s how I know it’s a selection problem.