3 ms·

I think it can be interesting, but only if the guy is a great developer. And if he is, he should spend more time thinking than typing, so not sure it'll make a

I think it can be interesting, but only if the guy is a great developer. And if he is, he should spend more time thinking than typing, so not sure it'll make a fun video to watch. The hard part of coding is the design. A lot of programmers think as they code. They try something, get stuck, try something else, understand the problem better and so on. It's a kind of intellectual laziness which is not optimal. I've been doing competitive algorithms for a while, and I learned that the best programmers don't start programming until they know exactly what their algorithm will be. And an other thing is that they rarely have bugs. Also testing/debugging is extremely time consuming: they think carefully that everything is right before testing. Which is unlike the lazy approach which is to have something working asap and go into debugging mode. It takes a lot of discipline to be able to work like that, esp. under pressure.

ZeroFries 12y ago
This is really good to know because I think I fall into the "try something in code, test, and debug my way through it" category a lot. Do others agree that thinking it through completely before hand is optimal? Are there any studies out there which compare amazing programmers to just average ones on brand new material (where the more experienced programmer doesn't necessarily have the advantage of just more knowledge but has better principles/strategies of breaking down the problem)?
- blakehaswell 12y ago
  Yeah, my experience has lead me to believe that planning the solution in relatively high detail before touching my keyboard leads to faster feedback, better designs, and fewer bugs. I’ll generally take a pad and pen and write down my requirements and assumptions. This helps flesh out any further information I’ll need before I begin. Once I’m satisfied that I understand the problem I’ll sketch out a planned architecture (dependency graphs, data structures, etc). If this uncovers more missing information then I’ll get that information and revisit the requirements and assumptions. Sometimes the missing information is that I don’t actually know how to do something in the particular environment I’m coding in. In that case I’ll prototype the minimum code I need to figure out how to do what I need to (I never use the prototype in production code). Once I have a planned architecture that I’m happy with, writing the tests and code is relatively mechanical and straight-forward. I’ll do this for pretty much any change to a codebase that is more complicated than changing a single function.

ZeroFries 12y ago

This is really good to know because I think I fall into the "try something in code, test, and debug my way through it" category a lot. Do others agree that thinking it through completely before hand is optimal? Are there any studies out there which compare amazing programmers to just average ones on brand new material (where the more experienced programmer doesn't necessarily have the advantage of just more knowledge but has better principles/strategies of breaking down the problem)?

blakehaswell 12y ago
Yeah, my experience has lead me to believe that planning the solution in relatively high detail before touching my keyboard leads to faster feedback, better designs, and fewer bugs. I’ll generally take a pad and pen and write down my requirements and assumptions. This helps flesh out any further information I’ll need before I begin. Once I’m satisfied that I understand the problem I’ll sketch out a planned architecture (dependency graphs, data structures, etc). If this uncovers more missing information then I’ll get that information and revisit the requirements and assumptions. Sometimes the missing information is that I don’t actually know how to do something in the particular environment I’m coding in. In that case I’ll prototype the minimum code I need to figure out how to do what I need to (I never use the prototype in production code). Once I have a planned architecture that I’m happy with, writing the tests and code is relatively mechanical and straight-forward. I’ll do this for pretty much any change to a codebase that is more complicated than changing a single function.