This post is the thirteenth part of a ramble-rant about the software business. The current posts in this series are:
This post is about why I don’t work on my car.
I Still Work on my Truck
I have a 90 Jeep Comanche with the Pioneer package. Christy kissed me for the first time in that truck. I love that truck. I don’t do major surgery on my pickup but I change the oil; tune it up – plugs, wires, distributor, air filter.
Christy owned a 98 Accord when I met her. She now drives an Odyssey. I do very little work on the Accord and I don’t touch the Odyssey. Why?
Cars certainly do. I wouldn’t know where to begin working on the Odyssey. Cars aren’t the only things that change. Software changes too. In fact, I’ve often said one software year == ten car years.
This is one reason eighteen months of software developer experience is a lot. I started flipping toggle switches that represented bits just about 35 years ago. Does 35 years experience building software really mean the same as 35 years experience in another field? Well…
…Yes and No.
Yes, I have a large and deep bag of coding tricks. It’s difficult for me to quantify how much I call on that experience – especially the older knowledge. More than the knowledge itself, the decades of experience give me confidence I can architect software that works well.
And No, I do not think I call on the older knowledge often enough for it to make a major difference in my developer skills. In fact, I rarely call on any tricks more than ten years in the past, and probably five years is the practical limit.
When I’m interviewing developers I’m looking at what they’ve done in the past eighteen months. That’s about how long it takes to become a proficient software developer. Two and a half to three years developing enterprise-class projects, or four years maintaining similar-sized applications is enough experience for a senior developer.
“I Used to be a Developer.”
When I hear this on a project, someone is usually trying to tell me they know how to do my job. They are saying “I can do your job – I used to do it.” But that’s not accurate if they have been out of the developer field for more than eighteen months. Software changes that much with each release, and new design patterns emerge in the field every six months or so.
Unless the person telling me this has been coding on the side, I’m not buying it. Sorry. Not really.
If you want respect from developers, here’s a suggestion: Demonstrate respect. How would you feel if the developer said “Your job isn’t that hard. I bet I could do it.”? Is that what you’re intending to communicate to the developer?
Then stop communicating that to the developer.
Here’s the odd part: I don’t hear this from folks who stopped developing software a year or two ago – I hear it from folks who’s last line of code was COBOL. I have nothing against COBOL.
But batch programming from decades past bears little resemblance to multithreaded, OO, stateless, or even RESTful applications of today. (Note: I did not say “no resemblance.”) This is a different coding world. And it’s about to change even more when Visual Studio 2010 is released.
One advantage of coding over the past 35 years is perspective. These days I don’t call myself an application or web developer; I won’t insult the field by claiming to be part of it. But do I create applications? Yep. Services too. But coding up a single-threaded GUI does not a developer make – especially in 2010.
I can work on my old Jeep pickup but I do not work on the Odyssey.