I 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: : ''Everything should be made as simple as possible, but not simpler.'' Of course, he (or E. F. Schumacher?) has another that is also great for these issues: : ''Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.'' I think most of us who have been around a while have experienced over-simplification leading to an AmorphousBlobOfHumanInsensitivity. This is particularly true when one ''goes too far'' deconstructing a problem into smaller chunks in an effort to understand it. You know you've gone to far if, in the end, there are so many chunks that the solution has become more complex than the problem. Simplicity has many facets. One might say that a short solution using abstract algebra is simpler than a very long, modularized solution using basic arithmetic. Others may say the long and twisty solution is simpler because even an idiot could understand the math. It really depends on your point of view. As always, '''be careful''' with the IdiotProgrammer concept. Personally, I would prefer to have a PragmaticProgrammer over an IdiotProgrammer. ''-- RobertDiFalco'' 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. 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 IdiotProgrammer''''''s 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 IdiotProgrammer''''''s 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 G''''etEnvVarForCobol(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! 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 Reductionist''''''Programmer or Minimal''''''Programmer or even Simple''''''Programmer. Idiot has a lot of connotations and while I understand the ''campy'' aspect of calling oneself an idiot, Simple''''''Programmer 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. ---- ProgrammerStereotype