Idiot Programmer
Idiot ProgrammerI am an idiot. That has profoundly affected the way I code. Everything must be simple enough for a child to understand, and even then, I struggle.
Being an idiot has forced me to RefactorMercilessly. If I don't, there's no chance of my understanding my code. And if I don't understand my code, there's no chance of my getting it to work.
I've seen people who can solve complex problems, and I admire them. Alas, I'm not one of them. So whenever I have to solve a complex problem, I make it simple first.
If I can't make a problem simple, it's usually because someone else insists that it remain complex. In that case, I have to wait for someone smart to fix it (thank you, smart person), or for someone to change their mind and allow me to make the problem simple. -- WayneConrad
You should be careful with the above. I have seen over-simplification lead to just as many problems in implementation and design as over-complication. When simplifying complexity, it is always important to keep in mind the simple but powerful words of Einstein:
The particular incident that led me to write the above was being asked to help debug a particularly large and chunky function. These two programmers, who I consider to be much smarter than me, had been looking at it for half an hour and couldn't figure it out. Needless to say, neither could I. But when I suggested refactoring the method to make it simpler, they both refused. I had to leave them to their devices, since, being an idiot, I'm just not capable of fixing complex code. I didn't feel good doing that, but I simply couldn't help them if they required that I be smarter than them in order to do so.
The next day, a different programmer asked for debugging help, and I saw that he was stuck in another large and ugly function that someone else had written. I stared at it with him for 10 minutes, but again proved to be an idiot. However, when I suggested refactoring, this programmer said "ok!" I back-seated while he drove, and 15 minutes later we had a function that we could understand. The bug went away, too.
[Maybe it's still in there, hiding somewhere.]
A bug's preferred environment is complexity. If you clear-cut its environment, it has nowhere left to hide. -- WayneConrad
Indeed. When I was living at the Zen center in Honolulu, the big brown centipedes with the painful bite were our not-so-secret fear. In the banana patch, filled as it was with undergrowth, rotting remnants of stalks and leaves, was the centipedes' favorite environment, and no matter how hot it was, we went in with long pants, long sleeve shirts and hats. On the other hand, you could spot a midge flying in one end of the Zendo from the opposite end. But, we needed the banana patch, so clear-cutting it wasn't an option.
Wayne, I agree with this approach and, particularly the statement a bug's preferred environment is complexity. When faced with a bug in someone else's code that I cannot follow, I will often refactor (or even rewrite) that bit of code. Oftentimes, I find the bug while rewriting the code. Other times, the bug simply disappears. Of course, if it's a huge parser written using LALR, I abandon all hope. <g> In generally, I weigh the time it would take to rewrite some bit of code compared to the time it would take to understand it. However, this is usually because the code wasn't written clearly in the first place, not because you or I cannot understand complexity. Complexity and convolution are not the same. I'm sure you know that, overall, I agree with you. However, as of late I've become cautious of these pithy, extremist, one-liners. For example, I would prefer RefactorConvolutedCode? to IdiotProgrammer. ;-> -- RobertDiFalco
Robert, thanks for your great comments. I think your caution of pithy, extremist one-liners is well founded. I used the name because this is actually how I think of myself (and because I was pretty sure it would lead to a productive conversation, which it has). I've seen programmers who can figure out what's wrong with complex code and fix it, so I know there are much brighter bulbs in the box. I refactor mercilessly not because I'm particularly good, but because I'm particularly bad. -- WayneConrad
for (i = 0; i < 10; i) {
// some stuff
}
Find the bug! It took two IdiotProgrammers several hours to spot it. Since then, I always try to look for the dumbest of my own errors first, and I am merciless in my questions to others (did you think of this-stupid-thing?). Many people have a problem with the latter: Q: Do you think I'm dumb?! - A: I don't exclude the possibility. ;) -- JuergenHermann
To me, this is a different issue. This is more like always start with the primary constructs. For example, the second my eye hit the code snippet, I saw the unincremented i. But only after having considered whether or not i < 10 was correct - thinking that a hard-coded constant like this is often the source of bugs (i.e. max changed to 20 somewhere else). This isn't because I am so smart, but because I always start with the primary constructs when looking for problems and you isolated the primary construct so my eye could go directly to it. If there is no problem, then I go onto the next level of construction - I rarely start where the problem is being exhibited. I'm told this is much like repairing a car. The repairman does not start with the symptom - i.e. the dead battery - but follows its connections to its primary building block. Once you've located that, you start with each progressive level until you find the problem. After finding one, you keep going until you get to the battery again. -- RobertDiFalco
Did the IdiotProgrammers not have a debugger? Often, the smartest looking programmer only knows what tools to use or where to look for answers. This was sometime in 1989, with a big program, in DOS. No memory for a debugger in more memory than any human ever needs (i.e. 640K).
The trick is to get the code simple enough so that you can see the mistake.
Using a debugger to find the bug in complex code is valuable if you only have to do it once, but it's time-consuming. You might find the bug this time, and if you're lucky, there'll be a one-line fix for it. But the next time that code breaks (and it will, being complex), you'll be back there again with the debugger, wasting more time. Stop! Make it simple. Then you won't have to keep stepping through it with the debugger. -- WayneConrad
Try this one (C, mid-'90s, with a debugger):
void GetEnvVarForCobol(char *dest, const char *name)
{
dest = getenv(name);
}
They kept running it in the debugger, and checking 'dest', which had the correct value. But when they stepped up, through the return, the value never got to the calling routine.
I took a quick look at it in passing, and told them how to fix it, but they didn't believe me. Several hours later, they tried it. Fixed.
-- JeffGrigg
That would probably be grounds for dismissal in my group. For who? Jeff or the other guys?
I don't think someone is "an idiot" if they recognize their shortcomings and actively work around them. On the contrary, that puts them a lot closer to "intelligent".
My main reason for complaining is that I've met what I'd call idiot programmers, and if someone who realizes and corrects their faults calls themselves an idiot... What term do I use for the really bad programmers (those who don't think about what they're doing nor how to improve)? Managers. :-9
Etymologically, "idiot" means someone who only speaks his local dialect. More generally, you could say it's a person who fails to develop his intellect. So "idiot programmer" seems like a good term for the really bad programmers. To describe the foolishness that occasionally afflicts otherwise wise people, "dullard" (opposing sharpness), "insensate" (opposing sensibility), or maybe "asynetic" (literally, "without sense") are appropriate. But somehow, "What a dullard I am!" doesn't carry the same force as, "I'm an idiot!"
I vote for IdiotProgrammer and indeed IdiotArchitect?. The architect should be concerned with the users, with the details of the HumanComputerInteraction. I've never known real users who don't make the architects look like idiots. The only alternative is to make the users feel like they're the idiots. So of course we do that. Then return to the comfort of our impressive titles, borrowing false kudos from another discipline where at least when the building fell down the inhabitants weren't blamed. -- RichardDrake
The only alternative is to make the users feel like they're the idiots.
What a bleak view of the world you have! Let's see, either the architects are idiots or the users are. Not much of a choice. How about a world where neither are idiots! I mean, what kind of thinking is this - that for the architect or programmer to actually care about their users they must be idiots? Yikes! I don't understand you guys, you have huge insecurity complexes about what you (not I) call real architects and real engineers but think that software engineers and designers should think like Idiots and recoil from anything challenging or from viewing their work as important. Freud would have a field day with you guys! <g> Personally, while I don't mind thinking of myself as an empty rice bowl, I do try not to be an idiot. Even Don Quixote wasn't an idiot. -- RobertDiFalco
Another vote for IdiotProgrammer. If for no other reason, because it's an example of "riding the horse in the direction he's going". Chances are, those guys with the spaghetti code who asked you for help are thinking "idiot" as you retreat after giving refactoring advice they can't hear. Why disappoint them? Wear the pointy cap. -- WaldenMathews
Wow, you guys have such horrible engineering experiences. Whenever I read this sort of stuff, it makes me gain new appreciation for the environments, managers, mentors, and teams I've worked with. Maybe it's because I have the same view as EdwardYourdon in DeathMarch and leave if a situation is sub-optimal. I dunno, but anytime someone simplifies my code or untangles a mess I've made, I thank and admire them. In this same way, everywhere I've ever worked, when I untangle someone's spaghetti or simplify their design, I am thanked for the improvements I've made. Just this last week, I radically simplified someone's security model, just slashed off big chunks of it and I was thanked profusely afterwards. I really wish you all could have worked with the same teams as I because I have never had anyone call me an idiot for simplifying a complex problem. And I have never looked down on someone for picking apart and improving something I've done. Most of my early mentors would only ridicule me if I made something too complex!! I always thought this was the norm until I started hearing opinions like these on Wiki. It's very sad. Personally, I am going to stay in my world where people receive accolades for simplifying complex problems. I don't think I like the one where we are idiots. -- RobertDiFalco
Robert, you really shouldn't knock being an idiot if you've never tried it. -- WM
Robert, It's actually me calling myself an idiot. My coworkers don't (at least not to my face). They come to me for advice. The idiot part is because nothing I do takes a lot of smarts. It's all just doing the simple thing well, and avoiding the complex thing. Most of how I help my colleagues is to steer them towards simpler answers (or better, steer them towards simpler questions). The best thanks I get is seeing someone's eyes light up with delight as huge chunks of fat get melted off of the program, leaving only the lean. -- WayneConrad
Maybe you should instead call yourself a ReductionistProgrammer or MinimalProgrammer or even SimpleProgrammer. Idiot has a lot of connotations and while I understand the campy aspect of calling oneself an idiot, SimpleProgrammer might be more appropriate. If you strive to create simple, clean, and easy to understand code, you are definitely not an idiot. -- RobertDiFalco
Those would be good labels if I were able to do complex things but made a choice not to. But if I do the simple thing because I'm unable to do anything else... what should I be called then? Perhaps simpleton would be a better :) And yes, I kinda like the campy aspect of calling myself names. -- WayneConrad
Yeah, I see. It's kind of how I like the campy-ness of calling myself lord of the known universe and desired by all. The only difference is that you're not really an idiot. -- RobertDiFalco
Um, yeah. I guess a lot of us just know that we are too smart for our own good and have to watch out for this tendency those big brains of ours have of making us shoot ourselves in the foot. I can see how actually being an idiot might be an advantage. ;) -- LaurentBossavit
Maybe it's all just wishful thinking after all. -- WayneConrad
Whatever you call it, there are definitely differences among programmers both in the ability to smell complexity building, and in the preference for how much of it to tolerate before looking for something simpler. Competition usually seems to breed complexity, not simplicity, although I see no reason why it has to be that way. The nice thing about the IdiotProgrammer moniker is that it breaks the positive feedback loop of professional one-upmanship, and gives good quality a chance. I'm for that. Plus, I like campy titles. -- WaldenMathews
A mnemonic phrase doesn't have to be accurate. It just has to spur your mind in a fruitful direction. All these fussy attempts to replace IdiotProgrammer with something more precise are exactly the tendency that "IdiotProgrammer" opposes. -- BenKovitz
Taking this stance leads you to the benefits of EgolessProgramming.
EditText of this page
(last edited July 15, 2005)
or FindPage with title or text search