Wizards Are Lazy
Wizards Are LazyThis page is about people considered "wizards" for their programming ability (at least by the managers); WizardsAreDangerous is about program "wizards" of the sort that MicroSoft made famous.
The Wizards Are Lazy is something of an AntiPattern. It is the fact that managers who do not understand the technology can be fooled easily into thinking that a programmer is actually more productive than they really are. This leads to unrealistic schedule expectations and the conviction on the part of the manager that programmers are a lazy lot that only work hard when they are interested and doing all night gigs with rock music booming etc. The low-life nerd thing. I've had many managers tell me that this was the right way to treat programmers and I've had a number of young programmers tell me that they left the field because of these expectations and this treatment. Undoubtedly a software manager should be someone who has programmed and understands the strengths and weaknesses of programming technology. The programmer also has to explain to the manager who does not understand, what the limitations are of what he did and stop posturing and pretending to more productivity than is really there. -- RaySchneider
This happens to me a lot. I do quite a bit of scripting (most notably in Perl). It amazes me how many people who are well versed in software development processes and lifecycles and project planning, throw all of that out the window when it comes to scripts. They're all for doing requirements and analysis and design and testing for the software they write and manage. But then it comes to scripting and alluva sudden they think its just some trivial thing that can be hacked out in an hour (apparently "script" is mistaken as a synonym for "trivial"). And some of these folks are people that are well respected for their expertise in one or more aspects of "Software Quality". Go figure!
Since we're talking about "Perl" and "Laziness", Larry Wall writes in "Programming Perl" that LazinessImpatienceHubris are the three virtues of all great programmers. Of course the inverse is false: possessing all three of these virtues doesn't necessarily make you great (although it may make you a big jerk ;-). It has to be the right kind and mix of each: Laziness to the extent that you will go to extremes to avoid unnecessary and excruciatingly redundant or tedious tasks (usually by automating them and generalizing the result for future use); Impatience to the extent that your threshold for what you consider tedious or redundant is very low (so you don't wait as long as others might before automating); and Hubris in the same vein as personal pride in crafts and craftsmanship -- You feel your work reflects upon you and want others to think as highly of it as you do when they see it (so you make sure it is well designed, coded, tested, documented, and "polished").
-- BradAppleton
I faced a similar situation a few years ago when I contracted into Fleet Bank. I was there to "baby-sit" a vendor system that was in the process of being upgraded. This was on a Unix-type system, the Tandem. The application needed to be brought up and monitored the entire day, then brought down. Unlike most Unix systems, here the vendor did not provide scripts to do these involved, tedious tasks.
What to do? I was there for six months. I was not developing. I automated the process.
From that point on, I came in the morning, typed a command and proceeded to study some other stuff that interested me. Anything happened, I was informed, at the end of the day, I typed in another command. A very lazy (but productive for me) six months.
-- HergerThomann AutomationIsOurFriend
Heh. I know the stereotype VERY well. I own a consulting and technology firm where we fix broken computers,systems, networks, telecom schtuff and write custom software for clients. I've had people call my home past midnight because they "knew I'd be home and didn't want me ignoring them" (not thinking that, rather than ignoring them, I might have been on another client's emergency situation from 8AM until around 10:30PM).
People will leave 5 messages on the machine within a 1-hour period. When 2 or more clients have a problem and my staff is all tied up, we usually run out of machine space within 3 hours because they leave concurrent long, rambling, irritated messages.
I've had people request software prototypes for simple database apps in the morning, and they'll call me that afternoon to "check and see if it's about ready".
I've had clients squall at me for 3 days running while I work incessantly on their website (nevermind when I set up the wiki that they demanded be done NOW, they won't pay enough attention during the THREE 2-HOUR LONG CLASSES I had to give them to teach them to use it to learn how to do it, and thus it's my fault when "the thingy won't do".
We have one client whose computer was broken for 2 months before we got it. It caught fire on my workbench. I had to order parts for it, and I got 3 angry phonecalls a day (some at 6AM) stating that she NEEDS her computer and MUST have it back soon. Bear in mind folks, that this is a home-user who plays solitaire and surfs the web with this thing. Period.
When I relocate my business this upcoming year, I think I'm going to quit taking home-users. Businesses usually don't call after 6 or before 8.
-- DuffyWeber
Try telling your customers what to expect. What response times did you commit to? One must communicate expectations to one's customers and listen to their expectations as well. I am not sure this is happening in the above scenario.
I can sympathize with Duffy... I've been woken up at 4AM by clients claiming that 'the search function doesn't work' when they didn't type in keywords. It got better when we bumped up prices and started dealing with 'bigger' (read more corporate) clients. The truth is that there a lot of people out there who are ignorant and do not understand how much work coders put into their work to make 'simple' software features come to life... Still, a certain type of laziness in a programmer is definitely an asset.
EditText of this page
(last edited November 16, 2014)
or FindPage with title or text search