= 27d567bc2d48d9f40e9ccc20ea370b15)
Morendil comments on Open Thread: March 2010, part 2 - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (334)
Programming is different from medicine. All the good programmers I know have learned their craft on the job. Silas doesn't have to wait and learn without getting paid, his current skill level is already in demand.
But that's tangential. More importantly, whenever I hear the word "maintainability" I feel like "uh oh, they wanna sell me some doctrinaire bullshit". Maintainability is one of those things everyone has a different idea of. In my opinion you should just try to solve each problem in the most natural manner, and maintainability will happen automatically.
Allow me to illustrate with an example. One of my recent projects was a user interface for IPTV set-top boxes. Lots and lots of stuff like "my account", "channels I've subscribed to", et cetera. Now, the natural way to solve this problem is to have a separate file (a "page") for each screen that the user sees, and ignore small amounts of code duplication between pages. If you get this right, it's pretty much irrelevant how crappily each individual page is coded, because it's only five friggin' kilobytes and a maintenance programmer will easily find and change any functionality they want. On the other hand, if you get this wrong... and it's really fucking distressing how many experienced programmers manage to get this wrong... making a Framework with a big Architecture that separates each page into small reusable chunks, perfectly Factored, with shiny and impeccable code... maintenance tasks become hell. And so it is with other kinds of projects too, in fact with most projects I've faced in my life. Focus on finding the stupid, straightforward, natural solution, and it will be maintainable with no effort.
That happens to take a significant amount of skill and learning. Read a site like the Daily WTF and you see what too often comes out of letting untrained, untaught programmers do what they're naturally inclined to do. One could learn a lot about programming simply by thinking about why the examples on that site are bad, and what principles would avoid them.
In practice you're right: people have different ideas of maintainability. That is precisely the problem.
But I don't know of any way to acquire this "programming common sense" except on the job. Do you?
Oh, no. What a terrible idea. If you do this without actually pushing through real-world projects of your own, you'll come up with a lot of bullshit "principles" that will take forever to dislodge. In general, the ratio of actual work to abstract thinking about "principles" should be quite high.
Open source.
Another case of "let them eat cake". The very gap in my understanding is the jump between writing input once/output once algorithms, to multi-resource complex-UI programs, when existing open source applications have source files that don't make sense to me and no one on the project finds it worth their time to bring me up to speed.
Between one-input, one-output programs and complex UIs are simple UIs, such as a program that loops in reading input and output, and maintains state while doing so.
The complex UIs are mostly a matter of wrapping this sort of "event loop" around a given framework or UI library. Some frameworks instead have their own event loop that does this, and instead you write callbacks and other code that the event loop calls at the appropriate times.
Thanks, that helps. Now I just need to learn the nuts-and-bolts of particular libraries.