3 ms·

This is a bit of a specific idiosyncrasy I just can't plan things on paper. Sure, I can try to plan then, but then I see I have no idea how things can/should w

This is a bit of a specific idiosyncrasy I just can't plan things on paper. Sure, I can try to plan then, but then I see I have no idea how things can/should work or how to best arrange things unless I'm actually typing code Also the planning on paper usually looks nice but doesn't consider all the real-world imperfections, so your beautiful planning becomes "ugly" quickly

jpgvm 3y ago
My experience is that it's a skill like any other, I was bad at it, I wanted to be better at it so I did it more often and now I'm good at it. Being able to anticipate and find nice design level general solutions for hairy real-world problems is where systems design becomes most rewarding.
Megranium 3y ago
It might also have to do with how programming was taught to a certain generation? At least from my own experience, when I was at university OOP and UML was all the rage, so we had to specify through diagrams in fancy diagram editors, then generate the code from that, and then still re-write everything by hand because it never really worked out quite that well. I never touched UML again after university ...
- kunley 3y ago
  UML was an abomination, and it's a relief it's completely dead.
- bux93 3y ago
  Well, the code generation was a mistake, but drawing diagrams is explicitly what the guy in this story did: He started by sitting at his desk and drawing a lot of diagrams. I was the project coordinator, so I used to drop in on him and ask how things were going. "Still designing," he'd say. He wanted the diagrams to look beautiful and symmetrical as well as capturing all the state information.
Cthulhu_ 3y ago
I think the modern-day equivalent would be test-driven development; in both cases (unless I don't get it) is that you make sure you understand the problem and write verifications before you start on a solution. Of course, this doesn't work for every problem / task.

jpgvm 3y ago

My experience is that it's a skill like any other, I was bad at it, I wanted to be better at it so I did it more often and now I'm good at it. Being able to anticipate and find nice design level general solutions for hairy real-world problems is where systems design becomes most rewarding.

Megranium 3y ago

It might also have to do with how programming was taught to a certain generation? At least from my own experience, when I was at university OOP and UML was all the rage, so we had to specify through diagrams in fancy diagram editors, then generate the code from that, and then still re-write everything by hand because it never really worked out quite that well. I never touched UML again after university ...

kunley 3y ago
UML was an abomination, and it's a relief it's completely dead.
bux93 3y ago
Well, the code generation was a mistake, but drawing diagrams is explicitly what the guy in this story did: He started by sitting at his desk and drawing a lot of diagrams. I was the project coordinator, so I used to drop in on him and ask how things were going. "Still designing," he'd say. He wanted the diagrams to look beautiful and symmetrical as well as capturing all the state information.

Cthulhu_ 3y ago

I think the modern-day equivalent would be test-driven development; in both cases (unless I don't get it) is that you make sure you understand the problem and write verifications before you start on a solution. Of course, this doesn't work for every problem / task.