The Attitudinal Rabbit
As the kids and I were driving home from the video store tonight, the tale of the Tortoise and the Hare popped into my head. Not sure exactly why, perhaps it came from something the kids were talking to me about.
Anyway.
It’s got a good lesson for development, buried at the surface.
The moral of that particular fable is not about speed. It’s about … attitude. Aesop took two extremes to illustrate his point, but it could have equally been two hares, or two tortoises. The difference between the two was attitude.
It is the same with development. You can have two gurus, one who will continue to work at something long after the other is in the dust. It is even more true when you have the guru and the not-so-guru. The temptation to have a lazy/bad attitude to development are far greater when it comes as natural as breathing. When you have to work long and hard to break through, it’s easier to be more aware.
But whatever you are, however your brain works, it boils down to the same thing. Somewhere along the line, and probably for most of said line, it’s gonna be tough. The coding, the selling/marketing, the support/install/training, the “humility” when dealing with clients afterwards. All these things are going to have a fair percentage of hard work attached to them. Slog work.
This afternoon I was faced with this head on. I found a particular problem within the functionality. It could have lain anywhere within about 4 levels of procedures. Intimidating to my caffiene-slowed brain, to say the least. But slowly I pursued the goal. Like a hound, chasing down it’s prey. A slow, slow hound, who wanted a diet coke badly.
Eventually, after fixing an incidental problem that confused the initial issue somewhat, I discovered the cause, fixed it … and BOOM, the sums added up.
Oh happy day!
Anyway. Attitude. Apart from anything, you aren’t going to get anywhere in the complete picture with a bad attitude. You might succeed in some areas, but the more clients you get, the more people you meet, the more chance there is that bad attitude will turn them away.
So I’m turning around towards something Bill and I were discussing today, mentioned briefly above. Sorry Bill, wasn’t stealing your IP … heh heh. That another step in the development cycle, the complete cycle, is to be able to suck it in and take humility by the horns. Or rather, meekly submit, especially when you’ve got clients getting antsy.
Meekness doesn’t mean weakness. It means you’re okay with not being right in other people’s eyes all the time. It’s okay for them to think that they are right. After all, they just might be. But whether they are or not doesn’t matter. If it’s just a “mine is bigger than yours” argument, then it should never be an issue. It doesn’t make you any less of a developer, and most of the time, people respect strength of character and true humility far better than arrogance and meglomania.
Anyway … ‘Nuff said. Babbled on a little longer than I meant to.
Hi Stu,
I used to belive this - but after watching BS’s proflic work rate
I’m not convinced - seems like an attitude that suits MS dev
tools to cover for their tortoiseness!
Regards,
AdamR
QUOTEOFTHEDAY: “Work well, then hard.”
Comment by Adam — January 26, 2006 @ 11:50 am
For instance: a lot of software we write today will no longer be in use
in 5 years, or will have undergone a major upgrade anyway. Indeed
some software will be written and then never used!
For the overworked I currently take the attitude of building something
quickly that just works, then if it is used to build it up, thus minimising
wasted time.
Now if you know ahead of time that you are building the next MYOB,
sure you might want to make your code extensible and modular, and
add comments and documentation and add good generic error handling
and so forth. But the point is these things come with experience and
you should already be coding without much slow down.
The part of the dev. cycle I find more important to take time over,
particularly for the less endowed, is design. A bad coder who just
jumps in is guarnteed to write absolute crap. And by saying take
time over design - I mean actually just have an analysis and design
phase! I don’t mean waste any time…
We have these arguements all the time over at;
RogueLike Dev usegroup
and it is usually the newer inexperienced programmers who advocate either;
A) Taking time on each step.
B) Jumping right in with no design.
Perhaps there is a nice middle ground that keeps productivity high
and quality acceptable, like most things in computers - a trade off.
/message ends!
Comment by Adam — January 26, 2006 @ 11:58 am
Yeah, I see what you’re saying, but would say that there is a path that allows maximum quality and speed at the same time. There are companies out there that produce quality products, within a respectible time-frame. I guess it depends on the leadership involved, whether that be a team leader, management, or others.
I guess I’m talking about an ideal situation … but it takes discipline in and of ourselves to work within whatever boundaries we find ourselves in. You can code lazy whether you own your own business or work in a corporate environment. Conversely, the opposite is true. You can code awesome whereever you are, to a certain extent.
Anyway, I very much appreciate the discussions … heh heh.
Comment by Stu — January 26, 2006 @ 4:03 pm
Hey Stu,
I think we actually agree - the trade off should be that optimal zone of optimal
possible quality for most efficient development time. Then we load up the testing
phase (which has to be done anyway) and rely on it to provide the important bugs
that need fixing. And since the prog’s have rushed through dev they might feel
more inclined to test properly - who knows!
I wrote about it on codemonkey in an article that expands the idea here:
We are ALL NUBS!
Regards,
AdamR
Comment by Adam — January 27, 2006 @ 4:33 pm
Yeah, I think we do agree. But nice conversation.
Comment by Stu — January 29, 2006 @ 5:12 pm