Programmers are usually inherently logical people. We get the job done by breaking down big problems into small chunks that we can wrap our heads around. This gives us a feeling of being in control and in command of our environment. I think that feeling is a large part of why programmers enjoy what they do. But our reliance on this sense of control is also exactly why we can become so distraught when we lose even a sliver of that control.
Panic gives rise to supernatural self-pity
And losing control is mostly associated with the onset of bugs. Those pesky little critters that we infuse with a sense of drive and intent when we can’t pin them down. They’re out to get us, aren’t they? They’re like hobgoblins lurking under the bed, just waiting for us to doze off and then they’ll take over the room. Only the room is your mind and when they do take over, panic turns it straight to mush.
This panic usually manifests itself as self-pity: Why me? Why now? Why can’t this just work? Those are the questions of capitulators, someone who has given up on logic and succumbed to the supernatural belief that the universe is out to get him. Hogwash, of course, but extremely common none the less.
Bugs are always about a lack of good information
What keeps the panic coming back is that programmers fail to internalize the outcome of every single bug they’ve encountered in the past. There were never any hobgoblins, there was always a logical explanation, and it was usually just a lack of good information. You didn’t think that A would result in Y, but was convinced it was Z.
But somehow this fails to seep in unless you make an explicit point about it. So please do that. The next time you think something is bizarre or impossible, remind yourself that it is not. That the universe is way too busy to concern itself with mocking you. You’re just not that special. Then roll up your sleeves and find that bit of missing information that’s causing things to work counter to how you’d like or expect.
Alejandro Moreno
on 15 Nov 07It seems obvious, but it’s nice to put it into words, isn’t it?
I’d like to know what prompted this post, too :)
brad
on 15 Nov 07Well said. Programming does tend to lead one to think in rather irrational ways, oddly enough. But if we were purely logical beings, we’d be robots and the world would be a lot more dull :)
Noah Everett
on 15 Nov 07Thats a good way of putting it. I wonder how clients would respond to it. “Sir…its not a bug, just unintended causation”. Then charge a consulting fee of $250 dollars for using big words. Bam.
Jason Long
on 15 Nov 07Not so much relating to bugs, but in terms of your comment regarding breaking down large problems into smaller pieces – I’ve been thinking a lot lately about how this concept relates to the “flow” state as coined by the author Mihaly Csikszentmihalyi. I think this is what makes practices like test-driven-development and GTD enjoyable and productive for so many. One of the main things you need for achieving the flow state is small, achievable goals. I think if you are constantly focusing on breaking everything you do down into smaller pieces (programming problems in particular), you can really get in the zone and enjoy what you’re doing even more.
Sorry for the extreme tangent, but I’d be interested in hearing thoughts or strategies for this flow-based development mindset.
Marc
on 15 Nov 07I can totally relate to that post David. I can’t count the number of times I’ve hit an “unintended causation” I just can’t bust and I start to get irrational in my irritation at the problem. I’ve learned that I simply have to force myself to work on something else for awhile or take a break. Once you let your emotions play into your programming, especially frustration, you turn the logical part of your brain off and you’re much less likely to find the source of your problem.
TDD certainly does seem mitigate the occurance of these situations, but it sure doesn’t eliminate them. There’s still plenty of times where you’re clueless as to why you can’t get your test to pass.
Try to put a positive spin on “unintended causations.” Looking back on my experiences as a programmer, bugs have been the catalyst for me learning more about the language and frameworks I’m using. Thanks to bugs, I know a lot more about the internal workings of Rails and that knowledge has made me a better and more knowledgeable programmer.
So… don’t think of a bug as a roadblock, think of it as an educational opportunity. :)
Arne Hassel
on 15 Nov 07Haha, love that you used the word Hobgoblins in the text=D
Also, as always, good written and interesting read=)
Gary R Boodhoo
on 15 Nov 07technically, the system does exactly what the code describes, so code itself can never be buggy. Great point re: lack of information being the source of bugs. Very much also the case in human interactions.
Morgan
on 15 Nov 07Greetings, I get unreasonably upset when a bug ‘vanishes’ without any developer consciously doing something that would resolve it, and everybody gets happy that it’s gone. It needs to be understood why it happens, or it’s possible the bug has gone into hiding. There’s a palpable sense of relief when the actual underlying cause of a supernatural-level issue is finally resolved.
That said, the very term ‘bug’ implies something that creeps into your code on its own. I like the term, ‘Massive Foul Up’ (you can replace the F with…oh…whatever you’d like. :) It comes from ’ No Bugs!: Delivering Error-Free Code in C and C++’, specifically:
It’s not a great book, but that particular insight was valuable when I was a few years into my programming career.— Morgan
Ben
on 15 Nov 07I’d just like to point out that, in the most enlightened of software development shops, nobody blames developers for bugs. They are not a “massive foul up,” nor are they really anyone’s fault. Bugs happen. They are a natural consequence of turning ambiguous rules into explicit instructions.
One of the best parts about Test-Driven Development is the idea that “bugs are unit tests you haven’t written yet.” That implies, A: That bugs stem from ambiguous requirements – had you known to write a test for that situation, it wouldn’t be a problem; B: That bugs just mean that you’re not completely done yet; C: That you’ll always check for that kind of bug again, and hopefully remember that kind of unit test in the future.
-Ben
Carlo
on 16 Nov 07Unless you’re dealing with non-deterministic concurrency bugs. Then it’s just turtles all the way down.
J Fred
on 16 Nov 07It one of the unique talents of the Evil One that he puts bugs into our systems when we are not looking. Yet simultaneously everything that is in there was put by us. He directs our hands and minds off the path of truth and logic and into the shortcuts of fuzzy thinking. He has has His own miracles and distracts us with meetings and network slowdowns.
As Maimonides said, development of the intellect is virtue.
So, it really was the Devil, all along!
Lee
on 16 Nov 07‘Bugs’ for me are an integral part of developing something new and exciting. I actually relish bugs, they give me the opportunity to see exactly whats going, learn why it isnt working and more often than not, give me a better way of doing something (usually by simplifying the code). I’ve rarely coded something and it’s worked first time and worked exactly how I wanted it to. Developing and bugs come hand-in-hand for me, they shouldn’t be used as a negative point in development but embraced and used to develop your skills and give you better understanding of how and what information is being moved around.
The joy of finding that bug after interrogating your code for what seems like hours, then realising what an idiot you were for doing it that way, fixing it with a couple of keystrokes, sitting back and going “yeh! Got ya!”
Drew McLellan
on 16 Nov 07Well, sometimes there are bugs too. Not due to lack of information or anything other than the fact the programmers are human beings, and human beings make dumb mistakes. Not mistakenly thinking that A results in Y, but more not knowing what you were thinking at all. I mean, what was I thinking?
Happens daily. Embrace the opportunity to fix things.
Anonymous Coward
on 16 Nov 07The bug is not a “massive foul up.” That the interface of the app used has not been redesigned specifically to reduce certain errors probably is a MFU.
Going Beyond Syntax Highlighting would be a step in the right direction. And it would do more than the invocation of hobgoblins or “blame the user” diatribes - although it affords an amusing turnabout when the programmer is the user - it does not do much for the sense of control.
While it sounds dubious at first, the idea of “active debugging” as you code is intriguing as well. I’ve only seen a mention of this (somewhere) and never really checked out the latest developments.
This, to me, seems a more 37signals-like take on the subject.
Tom G.
on 16 Nov 07There are no car accidents, only unintended intersections of 4 wheel vehicles.
I’ve always hated the term “bug” as it really does a disservice to the true nature of the problem. It implies that some outside independant agent is responsible for the problem.
The original bug was really a bug that crawled into a relay causing an early digital computer to fail. This was a variable outside the scope of what the system’s programmer should be responsible for. This isn’t a good way to describe a software defect.
What most people refer to as bugs are truly mistakes – shortcoming of us humans to take all possible variables into account and a lack of care (or time, or budget) to test or restrict the complete range of possible program input.
It sucks when we realize our imperfections but it does can at least drive us to improvement.
This discussion is closed.