6 ms·

Writing code is about understanding, also. I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. Th

Writing code is about understanding, also. I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. They just tried every crazy thing they could think of until it eventually returned results that looked correct. Don't be that kind of developer. For one, all the other developers are going to make you maintain that code for the rest of your life. Two, never be too proud to ask for help. We can't know how to solve every problem on our own. It's not possible.

userbinator 11y ago
I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step. There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to know how to do it mentally" --- it fails miserably when debugging, precisely the time when the machine can't do it. I've heard it phrased thus: "If you don't understand precisely what you need to do, what makes you think you can tell a computer how to do it?"
- JustSomeNobody 11y ago
  I think a pencil and paper are a programmers best friend. I find it helps me work through complex logic easier when I'm debugging. I find it helps me write cleaner code when I'm tasked with something challenging. I keep a notebook next to me when coding or debugging. I try to write down my thought process when writing new code. When debugging, I write the recreate steps (if there aren't any already), and any insteresting notes about the bug while I'm tracking it down. I write down anything I think the 'fix' may impact (I also email the team about those). Basically anything and everything.
- mwcampbell 11y ago
  But how can I mentally execute code if the whole point of the code is to interact with a third-party OS facility or application that's closed-source and therefore opaque? In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. Might as well just let the machine run the real thing.
  - userbinator 11y ago
    It does get a little more difficult when execution flows into code you didn't write, but you can still validate your post/pre-conditions at those boundaries.
  - etingel 11y ago
    > In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. That's the whole reason why you would want execute the code mentally. If you don't execute the code mentally, you might not realize that your mental model of the third-party component was incomplete to begin with. Mentally executing code is a great way to test your own assumptions.
  - yuliyp 11y ago
    Your mental model of the code you're reading is probably incomplete too. Just be aware of where you're less confident and then you can use different mechanisms to build that confidence when it's the most logical thing to do (running a minimal test case, or log a function return value, perhaps).
- spiralpolitik 11y ago
  This scales up to about 10-15 lines of code before it becomes impractical in most modern imperative languages. Functional languages due to their higher level constructs get better mileage out of the technique but there is still a small practical limit to the technique. It also doesn't work if your team isn't co-located.
  - AnimalMuppet 11y ago
    What? No. If you can only scale that up to 10-15 lines of imperative code, you're writing imperative code completely wrong.
- taeric 11y ago
  I have a similar quip that not many in my office find popular. Basically, if you can't manually test something, what makes you think you can automated the test?
- ams6110 11y ago
  I tried telling a client once, "if you can't tell me what you want, how am I supposed to make the computer do it." Wasn't very well received.
duggan 11y ago
> For one, all the other developers are going to make you maintain that code for the rest of your life. Ah, if only that were the case. In reality, developers move between jobs, and bad code always becomes someone else's responsibility eventually. Instead, it's better to understand that as a professional you should be - if not proud of your results - proud of making the best of a bad situation for whoever will inherit your codebase, be that your future self or a colleague.

userbinator 11y ago

I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step. There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to know how to do it mentally" --- it fails miserably when debugging, precisely the time when the machine can't do it. I've heard it phrased thus: "If you don't understand precisely what you need to do, what makes you think you can tell a computer how to do it?"

JustSomeNobody 11y ago
I think a pencil and paper are a programmers best friend. I find it helps me work through complex logic easier when I'm debugging. I find it helps me write cleaner code when I'm tasked with something challenging. I keep a notebook next to me when coding or debugging. I try to write down my thought process when writing new code. When debugging, I write the recreate steps (if there aren't any already), and any insteresting notes about the bug while I'm tracking it down. I write down anything I think the 'fix' may impact (I also email the team about those). Basically anything and everything.
mwcampbell 11y ago
But how can I mentally execute code if the whole point of the code is to interact with a third-party OS facility or application that's closed-source and therefore opaque? In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. Might as well just let the machine run the real thing.
- userbinator 11y ago
  It does get a little more difficult when execution flows into code you didn't write, but you can still validate your post/pre-conditions at those boundaries.
- etingel 11y ago
  > In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. That's the whole reason why you would want execute the code mentally. If you don't execute the code mentally, you might not realize that your mental model of the third-party component was incomplete to begin with. Mentally executing code is a great way to test your own assumptions.
- yuliyp 11y ago
  Your mental model of the code you're reading is probably incomplete too. Just be aware of where you're less confident and then you can use different mechanisms to build that confidence when it's the most logical thing to do (running a minimal test case, or log a function return value, perhaps).
spiralpolitik 11y ago
This scales up to about 10-15 lines of code before it becomes impractical in most modern imperative languages. Functional languages due to their higher level constructs get better mileage out of the technique but there is still a small practical limit to the technique. It also doesn't work if your team isn't co-located.
- AnimalMuppet 11y ago
  What? No. If you can only scale that up to 10-15 lines of imperative code, you're writing imperative code completely wrong.
taeric 11y ago
I have a similar quip that not many in my office find popular. Basically, if you can't manually test something, what makes you think you can automated the test?
ams6110 11y ago
I tried telling a client once, "if you can't tell me what you want, how am I supposed to make the computer do it." Wasn't very well received.

duggan 11y ago

> For one, all the other developers are going to make you maintain that code for the rest of your life. Ah, if only that were the case. In reality, developers move between jobs, and bad code always becomes someone else's responsibility eventually. Instead, it's better to understand that as a professional you should be - if not proud of your results - proud of making the best of a bad situation for whoever will inherit your codebase, be that your future self or a colleague.