[ravenstine]

Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

The saying also ignores the fact that humans are not perfect programmers, and they all vary in skills and motives. Being a programmer often not about simply writing new code but modifying existing code, and that can be incredibly challenging when that code is hairbrained or overly clever and the people who wrote it are long gone. That involves programming and it's really hard.

[Yokohiii]

Isn't overly clever code a result of programmers doing simple things the hard mode?

Okay it's a spicy take, because juniors also tend to write too smart code.

Figuring out what to do and how to do it, is maybe not hard but it's effort. It's a hidden thing because it's not flat coding time, it requires planning, research, exploration and cooperation.

It's also true that some seemingly simple things are very hard. There are probably countless workarounds out there and the programmer wasn't even aware he is dodging an NP hard bullet.

Both arguments are valid.

I think the weight leans on effort, because effort is harder to avoid. Work, complexity, cruft piles up, no matter what you do. But you can work around hard problems. Not always but often enough. Not every business is NASA and has to do everything right, a 90% solution still generates 90% returns, and no one dies.

[anyonecancode]

> Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

Isn't this kind of true, though? Housing construction, for instance, isn't bottlenecked by the technical difficulties of building, but by political and regulatory hurdles. Or look at large, capital-intensive projects such as the always-proposed, never built new Hudson river train tubes. Actually building these will take billions of dollars and many years, but even they would be long built by now were it not for their constantly being blocked by political jockeying.

Building stuff _does_ often involve difficult technical challenges, but I still think that as a general aphorism the observation that this isn't the _hardest_ part holds true.

[llmssuck]

We might have different concepts of "hard", but if I were a construction worker I think I would agree. Hell, I'm a developer and I agree. Figuring out what to do definitely is the hard part. The rest is work and can be sweaty, but it's not hard as if it's full of impenetrable math or requiring undiscovered physics. It's just time-consuming and in the case of construction work physically tiring.

It might be that I have been doing this for too long and no longer see it.

[johnnyanmac]

I imagine the hard part isn't the literal building of the stuff. It's the months or years of politics, beauracracy, and bids needed to get to a point where you can build it.

That's not to discount the intensity of the labor. Just that the labor is rarely the bottleneck in building stuff.

[ravenstine]

I see what you're saying, and our labor isn't the bottleneck from the perspective of engineers. However, I'm pretty sure that business leadership would beg to differ. They see engineering as a necessary evil to getting their products out the window, and it can never be done fast enough. The solution is the bottleneck in their eyes. Engineers have a better understanding of why they do what they do, hence they get that their work isn't inherently a bottleneck in spite of how challenging it can be.

But yes, in reality, you're correct that programming itself is not (or should not) be a bottleneck, but the process around developing a product definitely can be. The irony here is that this bottleneck usually gets worse the more corporate a business becomes and the more they try to treat programming as if it were a bottleneck. Not a day goes by that my job isn't made more difficult because the business wants greater agility and efficiency.