While I'm a web dev and not a Windows coder, this post is a great example of why I come back to HN.<p>> From experience, I’ve learned that it’s always best to fully understand a problem before you fix it. If you just patch over its symptoms but never figure out what the problem really was, it will often come back to haunt you.<p>Philosophical-level statements like this really help me as a dev, since my one of my biggest hurdles is getting traction for even simple 1-2 line refactors that, in my opinion, can simplify code and improve maintainability. Far too often, I hear "just get it done", and I like to be reminded with statements like this of why "just get it done" doesn't always result in a better bottom line for the company.<p>>For some reason, I took this concept to heart in a programming sense and have found it is a good rule to code by. My version of the static discipline, adapted for software, is that whenever you are making a modification to a piece of code, you should always leave it in a state of stability equal to or better than how you found it. And preferably the latter.<p>I try to do this where I can too, and again, appreciate the philosophical explanation. It prepares me to more thoroughly and calmly explain my own work style.<p>The author laments Windows development, and I can only contrast that with my experience on an open source web stack (Ruby on Rails, Backbone.js). The upside of working with open source is that I can crack open the gem (library) I'm using and investigate the logic myself. I could fix the bugs or extend the code to do what I want. That is pretty cool.<p>The downside of working with open source software is that documentation is horrid. As the author states, man-hours are finite, and people who write OSS typically don't want to spend their finite hours documenting their code. I just take these as tradeoffs. It seems like Microsoft invests heavily in documentation, but I guess the author's point is that they can still do better.