5 ms·

How do you understand the problem without writing any code? It's possible that people's experiences are different to yours because you work on a specific type

How do you understand the problem without writing any code? It's possible that people's experiences are different to yours because you work on a specific type of software and other people work on other specific types of software.

vlovich123 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. 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
carlmr 2y ago
>How do you understand the problem without writing any code? Not OP, but I find this a very good question. I've always found that playing with the problem in code is how I refined my understanding of the problem. Kind of like how Richard Feynman describes his problem solving. Only by tinkering with the hard problem do you really learn about it. I always found it strange when people said they would plan out the whole thing in great detail and code later. That never worked for me, and I've also rarely seen it work for those proposing it. It may be because I studied control systems, but I've always found you need the feedback from actually working with the problem to course correct, and it's faster, too. Don't be scared to touch some code. Play with it, find out where your mental model is deficient, find better abstractions than what you originally envisioned before wrestling with the actual problems.
- mixmastamyk 2y ago
  This is true when breaking new ground, but it’s a rare occurrence. Most business problems are a few thousand years old. Yes, there were taxes paid in the ancient world.
  - Espressosaurus 2y ago
    They weren't solving hard realtime nonlinear control for hardware running on a custom ASIC in a domain only a literal handful of companies even operate in. Not everything has been solved for ten thousand years.
    - mixmastamyk 2y ago
      You misread. Also, that tech has been around for decades.
  - gitremote 2y ago
    Most solutions to business problems are proprietary, not open source. Tax rules depend on an interaction between national and local laws that can change from year to year based on the ruling government. You can't just take tax rules from ancient Rome to generate 2024 tax software for Quebec, Canada.

vlovich123 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. 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

carlmr 2y ago

>How do you understand the problem without writing any code? Not OP, but I find this a very good question. I've always found that playing with the problem in code is how I refined my understanding of the problem. Kind of like how Richard Feynman describes his problem solving. Only by tinkering with the hard problem do you really learn about it. I always found it strange when people said they would plan out the whole thing in great detail and code later. That never worked for me, and I've also rarely seen it work for those proposing it. It may be because I studied control systems, but I've always found you need the feedback from actually working with the problem to course correct, and it's faster, too. Don't be scared to touch some code. Play with it, find out where your mental model is deficient, find better abstractions than what you originally envisioned before wrestling with the actual problems.

mixmastamyk 2y ago
This is true when breaking new ground, but it’s a rare occurrence. Most business problems are a few thousand years old. Yes, there were taxes paid in the ancient world.
- Espressosaurus 2y ago
  They weren't solving hard realtime nonlinear control for hardware running on a custom ASIC in a domain only a literal handful of companies even operate in. Not everything has been solved for ten thousand years.
  - mixmastamyk 2y ago
    You misread. Also, that tech has been around for decades.
- gitremote 2y ago
  Most solutions to business problems are proprietary, not open source. Tax rules depend on an interaction between national and local laws that can change from year to year based on the ruling government. You can't just take tax rules from ancient Rome to generate 2024 tax software for Quebec, Canada.