4 ms·
While I'm a web dev and not a Windows coder, this post is a great example of why I come back to HN. > From experience, I’ve learned that it’s always best to fu
by eric-hu 14y ago
While I'm a web dev and not a Windows coder, this post is a great example of why I come back to HN.
> 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.
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.
>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.
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.
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.
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.
- josephlord 14y ago> 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. Not universally true (although it probably is true in most cases). PostgreSQL has great docs and I've heard good things about Open BSD although I haven't looked myself.
- eric-hu 14y agoYes, I agree. I made sure to include 'typically' in my statement because I do see exceptions. Backbone.js has excellent documentation, as does Coffeescript and Underscore.js
- shabble 14y agoI invariably end up reading the library/framework/whatever sources as well, if only to clarify a particular point of documentation or something. But, when bughunting, there's often the dilemma of whether to fix the bug at the source (and hopefully, submit a patch to upstream), or to work around it (which can lead to horrific hacks) in your app code. With the former, you're stuck having to deploy custom packages with your fix in until/if it gets accepted into upstream and a new release is rolled, so all too often I've found myself doing both. I don't know what the solution is; even a perfect patch to a superhumanly responsive maintainer is going to take some time to merge and deploy. On an entirely unrelated note, a superb way to drive yourself insane is to edit the currently installed system version of the package in question, and then forget that you did some time later.
- eric-hu 14y agoI'm only about 1-2 years into web dev and OSS, and a couple of months into feeling like I can contribute meaningfully to a gem. With that said, this is my current ideal Github workflow: - fork the gem to make changes/fixes - complete fix and point my app dependency to my branch - add testing and docs around my fix - submit pull request to project owner - point my app dependency back to original gem when merged That all said, I consider the activity of a gem before I even bother submitting a pull request. If it hasn't been touched in a month, or if there are open pull requests from 1 month or older, I weigh heavily just writing a 'my team only' solution. This is admittedly selfish, but I'm hedging my time and emotional energy. I don't want to put care into crafting something that I believe to be useful only to watch it sit around unused because someone else doesn't want to review my work.