4 ms·

By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is

By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically. At many big tech companies I've worked out, an abstract design proposal precedes any actual coding for many tasks. These design proposals are not about how you lay out code or name variables, but a high level description of the problem and the general approach to solve the problem. Expressing that abstract thinking requires writing code but that's the "how" - you can write that same code many ways.

codr7 2y ago
If you haven't solved exactly the same problem before, specifying a solution before writing code is a bad idea imo. More often than not, it turns out that the prematurely defined general approach isn't very optimal. Which points at a pretty substantial limitation of LLM coding...
- skydhash 2y ago
  The solution is always out there. The code is just an automated way to get it without the error prone way of humans doing manual calculations. But sometimes, your understanding is flawed, so the code you write is not the correct way to have the solution. Which is why you have to get actual correct answers (specs) before writing code. Correctness is not embedded in software. It's embedded in the real world.
- vlovich123 2y ago
  Typically I find a novel problem domain requires roughly about 3 attempts from scratch to get a maintainable longer-term solution. However, that still requires having some idea in mind to try before just writing code. Of course you might also do some prototyping on certain subparts of the problem but there’s only so much of that that can be done and you’re still trying out what expressing high level ideas looks like / how it works. I don’t think there’s anything where the first step is writing code. It’s like saying the first step of solving a math problem is writing down equations.
skydhash 2y ago
> By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically. The whole argument behind TDD is that it's easier to write code that verify something than actually implement the code. Because it only have the answer, not the algorithm to solve the question. So for any code you will be writing, find the answers first (expected behavior). Then add tests. The you write the code for the algorithm to come up with the answer. Static typing is just another form of these. You tell the checker: This is the shape of this data, and it warns you of any code that does not respect that.
- vlovich123 2y ago
  And an even stronger approach than TDD would be to develop a formal proof in something like Coq. At some point you have to define your algorithm and it’s easier when you actually have some inkling of how it would work rather than just trying to blindly get a test suite to pass.
  - immibis 2y ago
    This is the extreme end of the static checking spectrum - so extreme that you can spend hours or days per line of code, and it's so slow that about five people in the world do it on production code (and their customers pay handsomely for knowing it has been checked this way).
    - vlovich123 2y ago
      Sure. But even there you start with an understanding of how you want to solve the problem and then spend all your time writing the proof in a way that the computer can prove that you have indeed solved it correctly. At all times you generally start with an idea of a solution - you might prototype stuff to test out different solutions and how you like them but with things that are less pure R&D you need to prototype less.
- 2y ago

codr7 2y ago

If you haven't solved exactly the same problem before, specifying a solution before writing code is a bad idea imo. More often than not, it turns out that the prematurely defined general approach isn't very optimal. Which points at a pretty substantial limitation of LLM coding...

skydhash 2y ago
The solution is always out there. The code is just an automated way to get it without the error prone way of humans doing manual calculations. But sometimes, your understanding is flawed, so the code you write is not the correct way to have the solution. Which is why you have to get actual correct answers (specs) before writing code. Correctness is not embedded in software. It's embedded in the real world.
vlovich123 2y ago
Typically I find a novel problem domain requires roughly about 3 attempts from scratch to get a maintainable longer-term solution. However, that still requires having some idea in mind to try before just writing code. Of course you might also do some prototyping on certain subparts of the problem but there’s only so much of that that can be done and you’re still trying out what expressing high level ideas looks like / how it works. I don’t think there’s anything where the first step is writing code. It’s like saying the first step of solving a math problem is writing down equations.

skydhash 2y ago

> By building a high level abstract understanding of how things operate & then understanding how that abstractions need to be expressed. Writing code certainly is more concrete and can highlight mistakes like when there's a gap in your understanding vs spots where details matter more specifically. The whole argument behind TDD is that it's easier to write code that verify something than actually implement the code. Because it only have the answer, not the algorithm to solve the question. So for any code you will be writing, find the answers first (expected behavior). Then add tests. The you write the code for the algorithm to come up with the answer. Static typing is just another form of these. You tell the checker: This is the shape of this data, and it warns you of any code that does not respect that.

vlovich123 2y ago
And an even stronger approach than TDD would be to develop a formal proof in something like Coq. At some point you have to define your algorithm and it’s easier when you actually have some inkling of how it would work rather than just trying to blindly get a test suite to pass.
- immibis 2y ago
  This is the extreme end of the static checking spectrum - so extreme that you can spend hours or days per line of code, and it's so slow that about five people in the world do it on production code (and their customers pay handsomely for knowing it has been checked this way).
  - vlovich123 2y ago
    Sure. But even there you start with an understanding of how you want to solve the problem and then spend all your time writing the proof in a way that the computer can prove that you have indeed solved it correctly. At all times you generally start with an idea of a solution - you might prototype stuff to test out different solutions and how you like them but with things that are less pure R&D you need to prototype less.
2y ago