Given a choice between spending an hour doing a task manually, or spending three hours writing a program to do it automatically... a geek will write the program, every single time. And, if not given the choice, if explicitly ordered to do the job manually, we'll disobey and write the program anyway. I've heard it said that a good geek is lazy, but I think it's more precise to say that a geek dreads boredom above all else. We'll move mountains to accomplish a task, as long as it's interesting.
This is not nearly as crazy as it sounds, because after we've "finished" a task, without fail, the requestor will return and say, "I know I said that would just be a one-time change, but...", or, "Actually, it turns out we don't need A B C D, we need A B Q D C", or whatever. You will reuse that program, no matter what they say; never throw it away!
14 comments:
yeah, hell...it's true!!!
I know I am a geek.
A few days ago I needed to brush up on some (Math) trig. calculations.
(for game-unit movement)
I could have used pen and paper to practice... but I made a draw application...
It was fun though :)
Laziness is one of the three virtues of a programmer as outlined by Larry Wall. The other two being hubris and impatience.
Lots of truth here. If you actually solve the problem you won't have to do it again in the future.
EVERY SINGLE TIME!!!!!!111111111elevenone
maybe i'm not a true geek?
I think this is a bit more of a nerd trait than a geek trait, but that might be quibbling. :) -- This is how I got into programming as a career. I built little tools for all the crappy tasks I had to do on a daily basis, and when people wondered why I was so much more productive than my peers, they noticed my talent.
I *just* had a conversation with a co-worker about how I spent a week of night shifts writing a routine to automatically execute a task my department had been doing manually for several years. How long did said task take on average? Less than two minutes ...
Geeks FTW!
Manual execution every work-day for seven years means about 7*200 = 1400 times.
I doubt that any task can eat less than 10 minutes or work time (because of the time required for attention switch).
So, 1400 * 10 = 14000 minutes = 233 hours = 30 working days.
+ manual execution is error prone.
So I would say that spending a week for automating that task could make sense.
That said -- there are many cases when automating rarely executed manual task doesn't make sense.
On top of that there is another reason for doing stuff manually -- it's very hard to automate task properly without doing it manually at least once.
Bottom line: whether it make sense to automate task or not depends on the circumstances.
The problem is that the "one hour" manual fix almost always ends up taking just as much time as the script, once you account for the fact that you're a human and you will make errors.
So, what's wrong with that? Just this morning, I had to do a menial formatting task over a few hundred files. I remembered doing something similar a couple of years ago, and sure enough, there was the script that I used. An hour or so of hacking adapted it to today's situation, and I was done. I now have a few hours in the bank for the next hack.
Python and Oracle, or any real database, is nirvana. Cool.
This is so true... yet not always desirable. The one hour versus three hours ratio is a good one, for the reason mentioned by other commenters (you usually end up reusing your code and save some time on the long run), but it is sometimes worse than that.
As a geek-turned-manager-of-other-geeks, I sometimes have to pull the plug off some projects with ratios of 1 hour (manual) versus days (coding). With this kind of ratio, it is VERY difficult to rationalize this attitude.
Sometimes we geeks are just like spoiled kids who just cannot get things done is the most appropriate way. Like you wrote, the problem is that we are far more repelled by boredom than by work, which may be related to a tendency toward AD/HD.
Maybe all this is a polite way to say that we'd rather play than work, even though some of our games look pretty much like work to non-geeks.
One collateral effect is that since the code needs to be... well... interesting, in that kind of situation, you often get some obscure code that only its author can understand and leverage efficiently.
Sometimes I catch myself thinking "well, that would be a great use case for Haskell, where's that download for the compiler again ?" then have to force myself stop right there and use more mundane (AKA boring) means.
This is all very well for bragging and geek mythology, but from a manager point of view, it means that you need to be aware of this problem (being a geek helps) and know how to deal with it in order to get the best bang (net result) for your buck (wages). Otherwise, you'll end up watching countless days of productivity end up in another one's dream to reinvent the wheel in an interesting fashion.
Geeks are lazy only in the Puritan "work harder" sense. If you want a guy to go into the forest and saw all day with a dull saw, a geek is not you're man. But if you want someone who will take your task and not only accomplish it but improve the process along the way, a geek is the way to go.
There's a saying in chemistry circles that "An hour in the library will save you a week in the lab every time." But it never sinks in because most people who hear this admonishment hate the library and love the lab. I think it's a similar sentiment.
Post a Comment