[wmccullough]

I’m not fully willing to accept the plumbing analogy myself. While I do agree that most of our work is CRUD over REST, I think there’s another element of skill that isn’t uncovered in the article. If we are humble plumbers, why does it take me six months to find engineers that understand basic concepts like cohesion and loose coupling beyond a text book level (and I live in a metropolitan area with several software schools!)?

Perhaps a more apt analogy is that we are more like home renovation specialists. If things go well, we can update your plumbing to get away from lead pipes, but if we have to route the new plumbing through a joist, we are going to have to educate you on why we should do something a certain way. If we find a water leak and rot that will put your home (business) as risk, count on us to tell you about the risk and let you decide if you want to address it.

I’d argue that we are simply doing plumbing when things are going really well, perhaps even when the house is small and was well built to start with. If plumbing was all we did, I’d argue that our field would be way more saturated than it is.

[FLUX-YOU]

>why does it take me six months to find engineers that understand basic concepts like cohesion and loose coupling beyond a text book level

If it's so basic, just hire them and take a day to teach them those things.

WTF is with this trend of waiting 6 months for a hire vs. spending a day to fix the holes in someone's knowledge.

[BoiledCabbage]

Because someone introduced the term "rockstar" to our profession and we've been addicted to the concept ever since.

An expert is someone experienced and well trained, a rockstar is some inherent quality that's selected.

Our industry needs more of the former.

[bluesnowmonkey]

Cohesion and loose coupling are hard to teach. You need big examples not just to understand what they are but more importantly why they matter. They specifically help you work on systems that you couldn't just read and understand in a few minutes.

If the examples have to be so big, they might as well be real systems. Then you're not being taught so much as learning on the job as you go.

It's accurate to call them basic concepts but you only learn them through extensive experience.

[cimmanom]

Because it takes way more than a day to fix those holes and instill new habits and ways of thinking and to demonstrate the value of them. In fact, it can take 6 months. Or a year. Or three. And in the meantime you have a developer with bad habits introducing debt that is going to cost even more time to fix down the line.

[booleandilemma]

Because every company thinks they’re Google.

[icebraining]

Because of Brooks's law. When you're already working overtime, you don't have a day to fix those holes.

[laurentl]

And yet you can afford to wait 6 months to find someone who doesn’t have these holes?

I’d wager actively recruiting for 6 months takes a lot more effort than training someone for one day, for that matter.

As a manager, I find it more interesting to develop someone’s skills than hire a rockstar (and deal with ego issues). It’s more work, and you can’t always afford to do it, but at the end of the day you’ve contributed to fixing the long-term problem by adding one more resource to the talent pool. And it’s way more rewarding, and arguably one of the best uses of your time as a manager.

[mmt]

> And it’s way more rewarding, and arguably one of the best uses of your time as a manager.

I'd say it's also one of the best uses of the time of the more senior engineers who will act as (additional) teachers/mentors.

Having been in the position of needing to explain a concept or even just "show my work" has helped me not just better understand what I'm doing, but sometimes even catch fundamental mistakes in my thinking.

It's also why I like commenting on technical matters on HN. Sometimes forcing myself to articulate my thought to someone else will reveal the absurdity of a long-held assumption, or something similar.

[Apocryphon]

Maybe you (meaning a garage-level bootstrapped startup) don't, but surely not every single firm that's out there is in such dire time constraints.

[rbalicki]

Agreed. I think the free market argument that "if advanced engineering skills were so unnecessary, some company would scoop up all the underpriced, underemployed junior engineers and make a killing" is a compelling response against the strong version of what the OP is saying.

That's not to say that tech screens are perfect, or even testing the right thing. But they do play an important role: they're an attempt by the company to not give too much responsibility to someone who will use it irresponsibly: whether by accruing technical debt, or dropping tables willy nilly, or by taking down the website.

99% of engineering isn't plumbing. It's pushing back on all the feature requests that can't be done responsibly in the amount of time allotted. It's using your intimacy with the code base and inner working of the company to anticipate problems. It's taking advantage of your prestige as "some smart wizard that makes crazy things happen" to slow down and fix problems before they occur.

Others in the company can't tell whether you're acting like a spoiled brat or doing your job. To them, it's literally indistinguishable. And that's why it's very important to not vest anyone with this amount of authority unless you're very sure that they're going to use it well.

[ryandrake]

> Others in the company can't tell whether you're acting like a spoiled brat or doing your job. To them, it's literally indistinguishable. And that's why it's very important to not vest anyone with this amount of authority unless you're very sure that they're going to use it well.

I agree with the rest of your comment, but I don't think you're giving non-engineers enough credit here. Sure, in lots of companies, the managers/executives are non-technical, and might as well be managing a packaged goods company. They think software development is wizardry and have no idea what you do. In most tech companies, non-engineer roles are somewhere on a spectrum of technical knowledge that might surprise you. Maybe they've been through dozens more software release cycles than you. Maybe they are currently practicing software engineers trying out a new role. Maybe they co-wrote the standard that you're now implementing. I've seen all of the above in actual companies. Careful about jumping to incorrect conclusions based on someone's title or the actions their role demands.

[rbalicki]

Ah, fair enough. I should've said "in many cases, the non-engineers will have trouble distinguishing between and engineer contributing to the business in a hidden way and over-engineering things."