4 ms·

Time spent at the keyboard is definitely not the mark of an effective coder. Code is just the implementation of a design. For any nontrivial module, the design

by ken47 4y ago

Time spent at the keyboard is definitely not the mark of an effective coder. Code is just the implementation of a design. For any nontrivial module, the design should take up the majority of your time. If you're designing as you're writing code, you're probably doing it wrong.

random_kris 4y ago
Problem for me, probably because I'm inexperienced developer is that no matter how much I plan things will change. So for me it is better building multiple small things and then wiring them together. Only after this im capable of doing any realistic implementation planning
mypastself 4y ago
My platonic ideal of a developer is this older, hacker-type guy, whom I’ve witnessed spending days mulling a problem without writing any code. Then one morning, he simply transferred the implementation from mind to code, completely self-documenting, with all edge cases covered. He said something like “from my point of view, this code is perfectly written”, and it actually didn’t sound arrogant, partly because it was true. I still have to think with my fingertips (i.e. write code before I know the solution), but his is the kind of approach I strive for.
- Sakos 4y ago
  I've been trying to work towards this. I'll sketch out a prototype and reason through it on paper sometimes before writing code. It's an interesting exercise.
- p4bl0 4y ago
  There is no problem with thinking with code by trying things out. We left the punched tape and printed result listing era, we can write and tests partial solutions to the problems we try to solve almost for free, and that's a good thing. Don't beat yourself up for doing that :). Also, there are some limits to what one can entirely store and efficiently think about in their mind. Of course, it doesn't mean that one should always start writing code straight away without actually thinking first, or without using pen and paper to lay down some facts and think about edge cases if necessary, for example.
  - mypastself 4y ago
    That’s true. Sometimes you have no idea how some black-box API will behave until you try it. The “think-first” approach usually applies to algorithmic solutions to novel problems. They do both have their place.

by ken47 4y ago

random_kris 4y ago

Problem for me, probably because I'm inexperienced developer is that no matter how much I plan things will change. So for me it is better building multiple small things and then wiring them together. Only after this im capable of doing any realistic implementation planning

mypastself 4y ago

My platonic ideal of a developer is this older, hacker-type guy, whom I’ve witnessed spending days mulling a problem without writing any code. Then one morning, he simply transferred the implementation from mind to code, completely self-documenting, with all edge cases covered. He said something like “from my point of view, this code is perfectly written”, and it actually didn’t sound arrogant, partly because it was true. I still have to think with my fingertips (i.e. write code before I know the solution), but his is the kind of approach I strive for.

Sakos 4y ago
I've been trying to work towards this. I'll sketch out a prototype and reason through it on paper sometimes before writing code. It's an interesting exercise.
p4bl0 4y ago
There is no problem with thinking with code by trying things out. We left the punched tape and printed result listing era, we can write and tests partial solutions to the problems we try to solve almost for free, and that's a good thing. Don't beat yourself up for doing that :). Also, there are some limits to what one can entirely store and efficiently think about in their mind. Of course, it doesn't mean that one should always start writing code straight away without actually thinking first, or without using pen and paper to lay down some facts and think about edge cases if necessary, for example.
- mypastself 4y ago
  That’s true. Sometimes you have no idea how some black-box API will behave until you try it. The “think-first” approach usually applies to algorithmic solutions to novel problems. They do both have their place.