Michael Goodfellow has another installment of Let’s Code up, and it’s packed with important ideas, wisdom, and difficult questions. I struggled a bit with this because I wanted to comment on almost everything. What should I do? Write a series of posts?
I don’t know. I don’t have time for another series. I have a fantastic volume of work staring at me right now, but I don’t want to let this slip by. So let’s just go over his post a bit at a time and see how far we get. Deal? Here we go:
Some of the comments on the blog are about working with other people. Why don’t I use more libraries, why don’t I get some volunteers to help out, why must I do everything myself?
I really enjoy programming, otherwise I would never take on a project this large. So asking me why I want to write all this code is like asking a chef why they want to make all this tasty food, when you could just go out and buy it.
Most professions begin with: I need money to live on. If I agreed to do this thing I dislike, will you give me the money I need?
For programmers, the cause and effect are all mixed up: I need to program. Can you give me enough money so that I can continue programming?
Then there’s the problem of debugging. Things go wrong and you need to isolate the problem down to a particular piece of code. It helps enormously if you’ve written it all yourself. If other people are working in the same area, it’s practically impossible to know whether the bug was caused by the thing you just changed, or by someone else’s change. It also helps that I know my own style and the kinds of mistakes I tend to make.
Using code from strangers is always a gamble. Sometimes, on rare circumstances (perhaps only a few occasions in your career) the clouds will open and you’ll find yourself in a beam of sunlight, looking at a link to the perfect library while angelic music plays. It does happen. But more often than not, you run into the usual chain of dependencies, missing files, lack of documentation, version incompatibilities, inscrutable bugs, missing features, and poor programming interface.
When you try to use someone else’s code, you begin a gamble. You wager, say, an hour of your time. You will find problems with using it, understanding it, getting it to compile, etc. You have no way of knowing if your current problem is the last one, or if another one will appear as soon as this one is sorted.
After an hour, it probably still doesn’t work. Now you’re in for an hour, but you feel like you’re close to solving your current problem. So… might as well wager another one, right? Then after another hour, you’re dealing with another problem. Do you really want to give up now, and walk away with nothing? Actually, worse than nothing, because you have to restore your codebase from a backup before you started and clean up all these files you’ve sprayed all over your hard drive.
Another hour later, and you still have nothing. You’ve fixed a couple more problems, and now you’re boiling mad. Mad at the idiot who wrote this thing. Mad at the forum trolls who sneer at your pleas for help. Mad at the one guy who has something that might help, but he’s offering it under a license that would require you to take your entire project open source. Mad that C++ is such a nightmare. Made at the jeering fanboys who tell you to use some other language that doesn’t have this problem, even though you don’t know that language and it doesn’t acually do what you need. Mad at yourself for falling into this trap. AGAIN.
Using external code is an iterative wager:
- Each round, you bet an allotment of time. You don’t know the odds of winning, and you can’t be sure if the prize is what you want.
- If you lose, you may wager more time. Your odds of winning will increase – although you still can’t know what they are or how much they improve. At the same time, the odds of the prize being useful to you goes down dramatically. After all, if it’s this much of a pain in the ass to use, it probably wasn’t well designed. And if it were genuinely useful, the documentation would be better written.
- Keep wagering an increasing amount of time until you either attain this [increasingly pyrrhic] victory, or run out of time you’re willing to wager.
And when you stop wagering, I promise someone – who wasn’t there to help you during the process – will accuse you of giving up “too soon”.
Sometimes I’m amazed anything works.
I’m also a difficult person to work with. Especially now that my health stinks, I have very erratic work habits, doing nothing for a day or two, then working late at night (it’s 3:30AM as I write this.) More of a problem is that when I decide something is wrong with the code, I’m brutal about just rewriting it. This means important interfaces and classes can squirm around quite a bit until I’m happy with them. I also tend to keep several subprojects going at once, switching between them when I get stuck or bored. All of this is a nightmare for other people to deal with.
Since leaving my day job, I’ve allowed my sleep schedule to spin freely as my muse carries me. I’ve found my schedule is similarly sporadic. This is really curious to me. With artificial lights, my schedule doesn’t need to be constrained by daylight hours, as in pre-industrial times. And without a fixed work schedule, there’s no clock to keep me waking at the same time each day. It seems like my default schedule is “random”.
When I can, I try to maintain the habit of getting up super-early, because I like having a large block of quiet time early in the morning. However, if my creative muse strikes as I’m getting drowsy, I’ll stay awake and indulge it. I’ve learned the hard way that going to bed while feeling creative leads to my mind spinning instead of sleeping, and in the morning the muse will probably be gone. I’ll end up short on sleep with nothing to show for it.
(For the curious, I got up at 3:30am this morning. It’s noon now as I write this.)
Finally, there are these intellectual property issues which have become more and more of a problem over the last twenty years or so.
I can’t even sum this part up. Go read the whole thing.
The Best of 2013
My picks for what was important, awesome, or worth talking about in 2013.
Deus Ex and The Treachery of Labels
Deus Ex Mankind Divided was a clumsy, tone-deaf allegory that thought it was clever, and it managed to annoy people of all political stripes.
A programming project where I set out to make a Minecraft-style world so I can experiment with Octree data.
So what happens when a SOFTWARE engineer tries to review hardware? This. This happens.
There are two major schools of thought about how you should write software. Here's what they are and why people argue about it.