Softpanorama May the source be with you, but remember the KISS principle ;-)
	Contents	Bulletin	Latest	Last year	Top visited	Scriptorama

Ten Commandments of IT Slackerism

Version 2.01

1. Stupidity is not the same as the lack of intelligence... It's an independent dimension, quality of its own. It's unwitting self-destruction, the ability to act against one's best interests, social blideness...  It's a a typical quality of gifted programmers/system administrators and you need to cultivate skepticism and your sense of humor in order to fight this disease before it destroys you...
   
    
2. There is a very fine line between software development as job, as hobby, and as mental disease. Thou shalt cultivate other interests to ensure that evil software development spirits do not fully possess thy soul.  There's much more to life than developing software day and night including open source software. Remember about warning signs of a software developer addiction:

   "My personal appearance went downhill. I didn't care. My girlfriend left. I lost my job. I didn't care. I had become, yes, a open source programmer!". 

   Remember that sacrificing your life for developing some semi-useless and duplicative open source program might be not the best way to realize yourself as a person. Developers pay for OSS, and they often pay a heavy price. Just ask Larry Wall.
    

3. Value your time and use the highest level of language possible. Program in scripting language unless it is absolutely necessary to use compiled language or Java.  If your program does not work or is useless it is not important how efficient it is. If it is useful,  people will use it even it is slightly slower then compiled language version. Also 20% of code consume 80% of time, therefore concentrating on those you can speed the program much more that writing everything in lower level language.
   
   Ignore the proliferation of OO programming languages (all of which seem to have stolen countless features from one another). It makes it difficult to understand why all those features are needed, and, especially, why the hell you should study them.  That's not a warning sign that you cannot cope with the University program. That actually may means two things:
   • You are still normal despite studying software engineering for some time.
   • In software fashion rulez no matter what.
      
4. Thou shalt know by your heart that all software sucks, but Unix sucks less the other OSes. Beware of those who say that their software does not suck, for they are either zealots or liars or charlatans. There is no silver bullet in software engineering.  That includes Microsoft products, GCC, Linux, Solaris, Java, etc.  Most of the books/articles that worship some fashionable trends that promise some kind of breakthrough are either intentionally (written by software engineering charlatans)  or unintentionally ( written by religious zealots) misleading and will be forgotten in a decade or so.
   
   The only true revelation of the art of programming is contained in  The Art of Computer Programming written by Donald Knuth. In operating systems domain Unix is more elegant and sucks less that other OSes, but it still sucks.  Especially as a desktop. The necessity to tinker with OS to make some device work is a good training exercise during college days, but it became annoying and distracting masochism  later.
   
   Both Microsoft Windows and Linux are to operating systems what McDonalds is to gourmet cooking: too much fat.  Thou shalt try other OSes including minimized Linux distributions, OpenBSD/FreeBSD, etc, it is has features that make it more suitable to the task in hand. Never assume that any particular OS is good for all tasks.  
    
5. When people are free to do as they please, they usually imitate each other. It's better to destroy your health while you are being handsomely paid, that do it for free. Paradoxically a lot of great software was written by trying to meet tough deadlines in the commercial project.
    
6. Beware of "this needs to be rewritten" trap. More often that not this is just a manifestation of  "Not invented here" syndrome, which is a powerful motivator for doing stupid things. I've never seen an good programmer who examined the code and did not say or think "Well, this crap needs to be rewritten!" If code works, it usually doesn't need to be rewritten despite the fact that it doesn't fit your prejudices. Value your time and don't rewrite things that does not make sense in any language...
    
7. When you encounter ideas pushed by higher management that politely could only be described as “ridiculous” think twice before trying to enlighten those poor smacks. The chances are reasonably high that the "the one, the only" whom you try to enlighten is a sociopath and you will inflict severe punishment on yourself for your own stupidity.  Instead of boiling about stupidity of the idea, think about (possibly covert) ways to convert completely stupid suggestion into something at least workable without irritating stupid jerks. Or at least benefiting personally from this stupidity. 
   
   IT management jerks control much less that they think and circumventing them helps to polish your architectural skills ;-).  Think strategically and try to understand simple fact that in 3-5-10 years nobody will care about the fact that those jerks moved electrons in wrong direction. It's all like writing on a sand beach -- the next big wave will wipe everything anyway. Chances are that during the project you might have an opportunity to change the direction in some kind of covert action; also think about what you can learn while doing the project independently of the results and what training you can get  as a bonus for not questioning higher up judgment.
    
8. Initiative in any large company IT department is punishable offence. You will be better off writing open source software as a hobby under pseudonym, or taking a couple of courses at company expense, then trying to break the bureaucracy walls in your current company. Actually self-education including but not limited to writing open source software might get you faster to better position, salary, etc in a different company that might value your skills higher then current.
    
9. Remember that in any project the most suitable programming language is the language that project leader knows the best.  Don't fight such  idiosyncrasies even if you hate the language. You can always generate one language from another and create a prototype in the language you like (without advertizing this transgression ;-) and manually translate it into a target language.  Think strategically: the language is just one tool in the tool chain and if it has a good debugger  it's an OK language.  Otherwise try to find other people who share your resentment and present facts about debugger quality in an objective non-threatening to the ego of the project leader way.
    
10. Thou shall never believe that by clapping hands and chanting "La! La! La! Free/Open Software is the best!" long and loudly enough, it'll come true. That's Raymondism. Choose free over non-free only when it is better suits your needs or you have no money to buy commercial software and thou art willing to fix what is broken. Choose a license of thine liking for software thou writest and do not blame those who choose differently for software they write. Remember that Unix is more than 30 years old, GNU is more then 25 years old, and Linux is more then 15 years old. Never refer to anything that is more then ten years old as revolutionary. You should just laugh at those poor jerks who call  Linux a "the revolutionary operating system".  Linux is  "the last century operating system" and no better or worse then other flavors of Unix; it just more bloated :-).  Ask yourself if it really make sense killing yourself trying make it better or promoting it in your crazy corporate IT environment. Whatever flavor of Unix is present in your environment might suit you just fine :-). Open Standards are not equivalent to open source and are more important than open source. Like people benefit from knowing more than one language, programmers can benefit from knowing and using at least two OSes: one for the desktop and the other for the server. Monoculture of software is bad, diversity within reasonable limits is good.  Never put all eggs into one basket, be it Windows or Linux, Java or Python.

Acknowledgements

[Mar 09, 2012]  Hat tip to an anonymous reviewer who pointed out several inconsistencies in the text.

[Aug 10, 2010] Hat tip to Mark Gilsdorf for suggestion  that "The software language that a developer uses will be the one recommended as the best language to use for any project. "  that was converted in Commandment No. 9

[Aug 14, 2009] Hat tip  to Mikkel Alan Stokkebye Christiansen for several spelling corrections...

[Sep 21, 2008] Hat tip to Paul Cubbage who suggested  Commandment No. 6

Created June 1, 1998; Last modified: March 09, 2012