I by and large agree with this post, but the points under "operation" seem... mismatched to the rest of the article.
> You're no longer "feeling around" while at the same time fighting compiler errors.
> Off-by-one, inverted conditionals, and error-handling are usually very obvious when stepping through code, but difficult to spot when only testing.
These problems feel way more basic than whatever problem you set out to solve initially. Like, several layers away.
If you have to make a fix in an environment that is so complex that you need to fully read many functions and take notes on what they do in order to get the logic right, you are pretty doomed if "will the compiler accept my code" is something that's even on your mind.
Don't get me wrong, it's completely true what the author wrote - it's just strange that these are the problems discussed in a scenario where the code/design is complex enough to warrant an explicit "pre-op" phase. Change my view?
Edit: Sorry, just now read the Conclusion section and it mentions how this article is targeting somewhat junior devs - in that case, I fully concur! ("Cakelisp and GameLib development still continues" primed me for something else.) And yes, the steps do become automatic, even as you deal with more complex problems (i.e. when "will it compile" is no longer conscious thought).
I'm sure that you can get away with a less thorough "pre-op", but how many times have we all made changes to code and then realized our changes didn't work after-the-fact? Even in very complex systems I've worked with, I actually find that not spending enough time understanding the code tends to result in small errors rather than big ones: by the time I feel confident enough to write code, I can usually write something that's basically (but not entirely) correct. As I read it, the author is imploring us to practice putting in the time upfront to avoid these kinds of mistakes.
> You're no longer "feeling around" while at the same time fighting compiler errors.
> Off-by-one, inverted conditionals, and error-handling are usually very obvious when stepping through code, but difficult to spot when only testing.
These problems feel way more basic than whatever problem you set out to solve initially. Like, several layers away.
If you have to make a fix in an environment that is so complex that you need to fully read many functions and take notes on what they do in order to get the logic right, you are pretty doomed if "will the compiler accept my code" is something that's even on your mind.
Don't get me wrong, it's completely true what the author wrote - it's just strange that these are the problems discussed in a scenario where the code/design is complex enough to warrant an explicit "pre-op" phase. Change my view?
Edit: Sorry, just now read the Conclusion section and it mentions how this article is targeting somewhat junior devs - in that case, I fully concur! ("Cakelisp and GameLib development still continues" primed me for something else.) And yes, the steps do become automatic, even as you deal with more complex problems (i.e. when "will it compile" is no longer conscious thought).