2 ms·

I just started programming (always been the biz guy, but thought I might as well learn to hack) and I have a habit of never starting a new module before the cur

by mixmax 19y ago

I just started programming (always been the biz guy, but thought I might as well learn to hack) and I have a habit of never starting a new module before the current one works without any known bugs. This might take a bit longer, but when I'm done I'm done - and usually there are only minor bugs to be fixed. Is this not the normal way of doing things, or am I missing something? Or is it simply because I only do simple stuff? (currently doing a website with user profiles, different sorts of to-do lists, ratings, gannt charts, a blog tool, calendar, and some ajax thrown in for the hell of it) Where, in your experience, does this last unseen mountain of work come from? Am I about to be hit hard with something unexpected?

yters 19y ago
Yes, your approach is good and should work pretty well. However, in my academic experience, the perception of "done" can be deceptive, even for a well defined problem. The purpose of the saying is to make people wary of thinking they are done. Similarly, it is said that the point of debugging is to find bugs, not to remove all bugs. Again, the idea is if you think you've found all the bugs, you're probably wrong. However, you may well be one of the lucky individuals who can understand the entirity of the program in one go. And, it is good to attempt to do so, even if you usually can't. Thinking through the entire logic of my programs helps a lot as I debug.
- mixmax 19y ago
  Thanks for the feedback.
trevelyan 19y ago
Usually coders put together a prototype and then develop the final version by either (1) fixing the prototype, or (2) developing it from scratch. When time becomes an issue, it's natural for teams to choose #1 instead of #2. But since the prototype is rarely designed with the exact use in mind (or even with things like security) that means lots of stuff to fix and design-around. Using a good framework, keeping a sense of the long-term architecture needed and following agile/DRY practices cuts down on the difference between prototypes and final products, and is one of the reason (imho) for the popularity of Rails and the 37Signals approach to web development. Most people just flail though.
niels 19y ago
You probably need more experience. Nobody writes bug free code. Furthermore it's often not a good idea to write "perfect" code the first time around. When your code base grows, you might need to change things around and refactor some stuff.

by mixmax 19y ago

yters 19y ago

Yes, your approach is good and should work pretty well. However, in my academic experience, the perception of "done" can be deceptive, even for a well defined problem. The purpose of the saying is to make people wary of thinking they are done. Similarly, it is said that the point of debugging is to find bugs, not to remove all bugs. Again, the idea is if you think you've found all the bugs, you're probably wrong. However, you may well be one of the lucky individuals who can understand the entirity of the program in one go. And, it is good to attempt to do so, even if you usually can't. Thinking through the entire logic of my programs helps a lot as I debug.

mixmax 19y ago
Thanks for the feedback.

trevelyan 19y ago

Usually coders put together a prototype and then develop the final version by either (1) fixing the prototype, or (2) developing it from scratch. When time becomes an issue, it's natural for teams to choose #1 instead of #2. But since the prototype is rarely designed with the exact use in mind (or even with things like security) that means lots of stuff to fix and design-around. Using a good framework, keeping a sense of the long-term architecture needed and following agile/DRY practices cuts down on the difference between prototypes and final products, and is one of the reason (imho) for the popularity of Rails and the 37Signals approach to web development. Most people just flail though.

niels 19y ago

You probably need more experience. Nobody writes bug free code. Furthermore it's often not a good idea to write "perfect" code the first time around. When your code base grows, you might need to change things around and refactor some stuff.