The Lazy, the Obsessive & the Greedy
I’m sure you think of me as being a little off. After all, who would like to team members to be lazy? We all want everyone on our team to work hard, be balanced, logical and calm in his or her approach, not obsessive. And the first thing we were told as children was to share, not “be greedy”.
However, thinking back over the couple of decades spent in building software, my best developers have always had all three traits. I mean this in the most positive way — I have enjoyed working with them at all time, found them energising and inspiring me to work better — and would love to work with them again.
Why?
Let us explore lazy. In a developer context, what does it really mean? Given a scenario where it is needed to extract data from one table and insert it into another, with a high volume that will take hours for each operation, what approach would you like to take? Your first option is to do this to blocks of data, say a million rows every time by using a query, then validate the data and then finally insert it in the new format.
The lazy way would be to find/write/find & modify a tool that will do this for you.
Why? Because repetitive tasks are boring. Because tasks that do not require brainpower at every stage are not challenging, do not motivate team members to excel and can leave teams and individuals disengaged and demotivated. At this point, there are several choices for the individual. Keep repeating the task, or find a way to do it better by way of engagement for e.g. several teams competing to see who finishes the most work in a given timebox, or find a way to automate it so that no one has to ver work on that again.
Guess what the lazy developer would do?
Exactly.
Lazy is good.
Move on to Obsessive.
An application I was managing was having an intermittent issue with how data in a grid was being populated on the screen. A single ticket had been raised by a user in production and inspite of our best efforts, we were not able to replicate the issue. We are talking of a team of 50+ here across various departments from business to IT. In fact, even the user who had reported it could not replicate it. It was very tempting to dismiss it as a wrongly reported issue. However, when it had been discovered, the user had taken a screenshot, so we knew it existed.
After 2 frustrating days, the ticket was parked, no progress was made. A few days later, however, one of the most junior developers breaks out into an impromptu dance — he had managed to replicate the defect — it did exist and deserved to be fixed. The issue existed if
1. The number of lines in the grid exceeded what was visible initially (you could add unlimited lines in the grid, but only 4 would show up — you had to scroll for seeing further lines)
2. You used the mouse to scroll and clicked back into the grid for a cell — the earlier rows were reset
The fix turned out to be a couple of lines of code. But the only way we found this was to have this one developer who could not sleep at night because he had an open ticket against functionality he had developed in first place.
Obsessive is good.
What about Greed? Not sure about you, but I’ve always found that the best folks in any profession always want more — knowledge, experiences, war stories, challenges. Give them half a hint of anything and they want in.
I know someone who was a C++ developer (a really good one too), who got asked if he wanted to interview as a Java developer (sometime in 1999/2000 — early days for java). He was asked around 4 PM and the interview was at 9 AM the next day. He went off to get himself a book on java programming, then spent the next 6 hours trying out things in java.
Guess what? He got through with flying colors. His basic programming concepts were solid and his passion for learning was strong enough that he did better than others who had been writing code for months in java. Greed for knowledge and challenges is always good.
So that’s it. My twisted preferences for my fellow teammates. What kind of team mates would you like to have?
