Next article: Performance Comparisons of Common Operations, Leopard Edition
Previous article: Leopard: First Impressions
Tags: humor programming rant
In my experience with various programmers over the years, I've realized that most of them fall into one of several cults which describe their behavior. I've compiled a list of cults and brief descriptions you can use to identify them. (Note: if you're easily offended and think you might fall into one of these categories, please forego reading the rest of the article.)
Experience Cult
Members of the Experience Cult believe that it is impossible for any person to do anything they haven't already done before. They can be identified by their characteristic refusal to solicit advice from anyone who hasn't already worked with the exact problem at hand, by their horrified reaction when presented with any APIs they haven't used before, and by constant requests for ridiculously specific sample code.
Prognosis: may be led toward greater independence if shown that doing new things is actually possible.
Optimization Cult
Members of the Optimization Cult value fast code over all other virtues. They are often found asking questions of the form, "What's the fastest way to...?" They are horrified when presented with any suggestion which doesn't fit with their view of what is fast, but also have a hilariously wrong view of just which operations are fast and which aren't.
Prognosis: may eventually become productive with education on the actual capabilities of modern hardware, the true speeds of various operations, and the need to properly optimize programmer time.
Ease Cult
Ease Cultists value ease of implementation over all other virtues. They are often found asking questions of the form, "What's the easiest way to...?" They tend to assume that the frameworks have built-in facilities for everything they want to do and the major problem is simply finding them. They are horrified when it is suggested that they implement some functionality of their own.
Prognosis: if persistent enough, may outgrow these tendencies after finishing a reasonably sized project.
Fastness Cult
Although superficially similar to the Optimization Cult and the Ease Cult, Fastness Cult members value speed of implementation over all else. They do not have a characteristic question but can often be identified by their habit of trying to identify as many different ways as possible of accomplishing their goal so that they may choose the one which takes the least time to implement. They frequently scoff at any suggestion to experiment, research, or invest time into learning tools.
Prognosis: may be rehabilitated with frequent examples of the utility of experimentation, research, and tools, but often hopeless.
Uncertainty Cult
Members of the Uncertainty Cult believe that nothing is truly known, and it is best to be as sure as possible before proceeding. They are characterized by repeatedly soliciting advice for the same problem even after a good solution has already been proposed in great detail. Frequently seeks other venues for advice after exhausting the first one, or posts the same message to multiple mailing lists or web sites simultaneously.
Prognosis: when starved of information, may realize that it's possible to begin a trip without knowing the location of every footfall in advance.
Perfection Cult
Perfection Cultists know that perfect code exists with mathematical certainty and devote themselves to finding it. They are frequently seen endlessly refining code of no practical value. They occasionally solicit advice on how to choose between esoteric alternatives which to non-cultists appear to be equivalent and irrelevant. Their code would be absolutely masterful if it weren't for the fact that it is never finished.
Prognosis: graduation and employment are often cures, although active Perfection Cultism may continue in free time.
Cargo Cult
The Cargo Cult is the classic cult of pseudoscience which goes far beyond programming. Programmer Cargo Cultists do not grasp the need for deeper understanding and frequently don't even grasp that it exists, working entirely by imitation. They tend to write code which looks correct when skimmed but which barely makes sense when examined more thoroughly. When flaws are pointed out they make corrections which fit the letter of the suggestion but which miss the point entirely. They can often be identified by frequent arguments on strange topics with experts in which they refuse to admit that they don't know what the heck they're talking about.
Prognosis: hopeless.
What's your cult?
Comments:
I always want to rewrite my own code because I'm unsatisfied with organization or speed. I usually wind up with virtually the same code again.
Perhaps this is a subset of the Perfectionist, because, much like the Perfectionist, you can't ever finish such programs. Deadlines may be the cure, not unassociated with graduation and employment.
My cults would be Ease and Optimization; also a bit of Perfection when I rewrite code to make it marginally faster and easier to use.
There's a subset of the Ease cult worth pointing out in the context of Cocoa programming: we could call it the Single-API Cult. These people only want to use a single API for their entire program and are horrified to find that there are facilities only available using lower-level APIs. They can be heard complaining "what do you MEAN there isn't an NSUDPSocket?" or "I want to do vector operations but vecLib doesn't support NSArrays". There's a bit of he Experience Cult there too, in that they believe CoreFoundation APIs can only be learned by subterranean Morlocks, and POSIX/BSD APIs by bearded gurus.
Ease Cult is the best since we worry about code working and doing what it should and if performance are bad we fix it then and dont have nightmares about bad performance.
Perfection Cult is also good option since I lately saw methods that have 3-5 full screens and that was scary. I got bad habbit from my java teacher about formatting code and now i have to unlearn it since that kills svn annotations.
You forgot about code coverage cult, i lately did some code coverage and that thing is addicting, i dont care now about the code, i only want to get as much % as possible.
One glaring omission I must point out: the Hype Cult. This is the one that automatically adopts whatever the Hot New Thing is this year and tries to convert everybody else to it. I confess I follow the Hype Cult around from time to time when I'm in the mood to explore.
I think we might want to think about adding a "match the way the code does it" cult. If you work on a big project you are always stuck trying to decide to do it the "good" way, or the way that is like how the code already does something similar elsewhere. Yes, you could refactor, but I usually work in corporate settings, where you would have to refactor 50-60% of the time to make a dent, and nobody is willing to pay.
"fan of the Laziness, Impatience, & Hubris cults"
I'm not sure which cult I'd fall into but I probably tend toward Perfection Cult over the others.
All programming problems can be reduced to HashMaps.
With XP comes ligthweight documentation, the use of spikes to reduce technical risk, test driven design and automated functional and unit tests.
With Scrum comes sprint demos, which are demos staged for the users so that corrections can be made during the project.
One way to get out of the optimization cult is to use XP rule "make it work, make it right, make it fast". Then when you have to make it fast, make sure you have all tests in place and that you don't change the functinal code, but the libraries or abstraction layers by using cache proxies or some of the same sort, so that functionally you can't see any difference, but it performs faster.
One (or two) subcults of the Perfectionist cult: the Refactoring cult and the Design Pattern cult - this may be one and the same cult, as most of the Refactorers I've worked with like to refactor to design patterns.
http://slashdot.jp/developers/08/01/04/001246.shtml
I may be an cargo Cult.
Part of my ease-ness though is, if it isn't easy already, I should try to write something to make it that way. That's where the perfection and sometimes the uncertainty end up coming in...
I've been guilty of all of these at one point or another.
Skorgu, you are correct that that is research, but a Fastness Cultist takes it too far. A true cultist will find a perfectly workable solution with no downsides but will keep looking for alternatives far beyond the point of diminishing returns. A fanatic can end up with a two-line solution and will still keep searching in case there's a better way.
- Cargo
We believe that whatever you can/want to do, you can do it better if you do it in lisp. Also a member of generalist/simplicity/lazyness/hubris cults is our lisper.
If you follow the first half of this truism but not the second, you're not a member of the Perfectionist Cult and you should be.
If you follow the second half and not the first, you need to resign from the Perfectionist Cult because your premature enhancements are crippling your getting something done.
As you can see, I'm in the Truism Self-Reminder Cult. "Keep it simple, stupid." "Don't prematurely optimize." Etc., etc. That little voice in my head has to keep stomping on temptation.
In fact all those cults have their proper application. If I need an application badly I don't give a f*** to what is the problem. It should work. Now. So fastness cult (for me strictly related to defaults setted to recursive solutions).
If I have all the time of the world I'll very likely create a study on how much ram would be allocated at runtime, which CPU is more likely to run the program for the end-user etc.
Everything in order of the hands-on imperative. Control over the machine and no god-damned skynets in my computer is what I always repeat myself (just think, skynet would be a product of bad, bad, bad programming, creating a program that doesn't what it should and has a switch to kill-all-humans mode).
Yes i am reading this in Dec 2014....Thanks Mike for the great articles.
Usually the adherents are relatively young people who do not know that there are other ways of doing things than those they were indoctrinated into at college.
Such as: an old fashioned manager that actually manages rather than just having the word in their job title and, for many projects, good old procedural programming that is faster to code easier to read and understand, and consequently is delivered sooner, has fewer bugs and is easier to maintain.
Comments RSS feed for this page
Add your thoughts, post a comment:
Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.