5 ms·

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. I’m growing tired of this aphorism be

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. I’m growing tired of this aphorism because I’ve been in enough situations where it was not true. Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole reason the business opportunity existed was that it was an extremely hard engineering problem. I can see how one could go through a career where the programming itself is not that hard if you’re mostly connecting existing frameworks together and setting up all of the tests and CI infrastructure around it. I have also had jobs where none of the programming problems were all that complicated but we spent hundreds of hours dealing with all of the meetings, documents and debates surrounding every change. Those were not my favorite companies

ravenstine 7mo ago
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 7mo ago
  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 7mo ago
  > 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 7mo ago
  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 7mo ago
  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 7mo ago
    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.
llmssuck 7mo ago
> it was an extremely hard engineering problem But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc. I might be misunderstanding, but I cannot see how programming itself can be challenging in any way. It's not trivial per se or quickly over, but I fail to see how it can be anything but mechanical in and of itself. This feels like "writing" as in grammar and typing is the hard part of writing a book.
- simonw 7mo ago
  I count "figuring out how to do it" as part of the work of programming, personally.
  - llmssuck 7mo ago
    Fair enough, but I think that never really worked all that well. What I mean is that the term "programming" would then essentially cover anything and everything that can be put into an algorithm of some sort. Neutrino detection, user management dashboards, CRUD APIs, basically everything is programming. It would explain a lot of misunderstanding between "programmers" though.
    - rstuart4133 7mo ago
      It's true that we often split software engineering into two pieces: doing the design and implementing the code. In fact I often prefer to think of it as computer systems engineering because the design phase often goes well beyond software. You have to think about what networks are used, what the hardware form factor should be used, even how many check digits should be put on a barcode. But then you go onto say this: > But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc. That implies LLMs can't help with design of something that needs voice recognition and missile guidance systems. If that's your claim, it's wrong. In fact they are far better at being sounding boards and search engines than they are at coding. They make the same large number of mistakes in design tasks as they do in software coding, but in design tasks the human is constantly in the loop, examining all of the LLM's output so the errors don't matter so much. In vibe coding the human removes themselves from the loop to a large extent. The errors become shipped bugs.
wmwragg 7mo ago
Yep, I think people who repeat this aphorism essentially equate programming with typing, or as you say just connecting existing bits together. Programming is the working out how to get a computer to perform some task, not just the typing, it's the algorithms, the performance balancing, the structuring, the integration etc.
- pydry 7mo ago
  Or theyre just picturing some CRUD app that needs to connect to a few APIs being made for a clueless exec who doesnt even understand their own business problem. To be fair, a lot of programming does end up being just that.
- yibg 7mo ago
  Probably difference in the boundary of what programming entails too. Eg is coming up with the algo itself part of programming or only the writing the implementation part after the algo is clear. The first is hard, the second much less so.
- Anamon 7mo ago
  I think that's fine and probably kind of their point, no? Because that other part before the typing is also the thing that LLMs are woefully shit at, unless it's a common and solved problem with 1000 published examples.
johnnyanmac 7mo ago
>Some times the programming part really is very hard even when it’s easy to know what needs to be built Sometimes. Most programming jobs out there just need a button on a website or a 2 line fix for some off-by-1 error, though. Those who are working on novel, cutting edge problems are relatively rare. As you said, most software enginering is connecting existing frameworks together and being in meetings on how/when best to do it. Not necessarily a bad thing at all, but that's why the metaphor of the mechanic or doctor works out here, where the labor to know where and how to fix something is worth much more than the actual part (or medicine's) cost.

ravenstine 7mo ago

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 7mo ago
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 7mo ago
> 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 7mo ago
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 7mo ago
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 7mo ago
  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.

llmssuck 7mo ago

> it was an extremely hard engineering problem But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc. I might be misunderstanding, but I cannot see how programming itself can be challenging in any way. It's not trivial per se or quickly over, but I fail to see how it can be anything but mechanical in and of itself. This feels like "writing" as in grammar and typing is the hard part of writing a book.

simonw 7mo ago
I count "figuring out how to do it" as part of the work of programming, personally.
- llmssuck 7mo ago
  Fair enough, but I think that never really worked all that well. What I mean is that the term "programming" would then essentially cover anything and everything that can be put into an algorithm of some sort. Neutrino detection, user management dashboards, CRUD APIs, basically everything is programming. It would explain a lot of misunderstanding between "programmers" though.
  - rstuart4133 7mo ago
    It's true that we often split software engineering into two pieces: doing the design and implementing the code. In fact I often prefer to think of it as computer systems engineering because the design phase often goes well beyond software. You have to think about what networks are used, what the hardware form factor should be used, even how many check digits should be put on a barcode. But then you go onto say this: > But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc. That implies LLMs can't help with design of something that needs voice recognition and missile guidance systems. If that's your claim, it's wrong. In fact they are far better at being sounding boards and search engines than they are at coding. They make the same large number of mistakes in design tasks as they do in software coding, but in design tasks the human is constantly in the loop, examining all of the LLM's output so the errors don't matter so much. In vibe coding the human removes themselves from the loop to a large extent. The errors become shipped bugs.

wmwragg 7mo ago

Yep, I think people who repeat this aphorism essentially equate programming with typing, or as you say just connecting existing bits together. Programming is the working out how to get a computer to perform some task, not just the typing, it's the algorithms, the performance balancing, the structuring, the integration etc.

pydry 7mo ago
Or theyre just picturing some CRUD app that needs to connect to a few APIs being made for a clueless exec who doesnt even understand their own business problem. To be fair, a lot of programming does end up being just that.
yibg 7mo ago
Probably difference in the boundary of what programming entails too. Eg is coming up with the algo itself part of programming or only the writing the implementation part after the algo is clear. The first is hard, the second much less so.
Anamon 7mo ago
I think that's fine and probably kind of their point, no? Because that other part before the typing is also the thing that LLMs are woefully shit at, unless it's a common and solved problem with 1000 published examples.

johnnyanmac 7mo ago

>Some times the programming part really is very hard even when it’s easy to know what needs to be built Sometimes. Most programming jobs out there just need a button on a website or a 2 line fix for some off-by-1 error, though. Those who are working on novel, cutting edge problems are relatively rare. As you said, most software enginering is connecting existing frameworks together and being in meetings on how/when best to do it. Not necessarily a bad thing at all, but that's why the metaphor of the mechanic or doctor works out here, where the labor to know where and how to fix something is worth much more than the actual part (or medicine's) cost.