Introduction
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?
Things Change
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.
Odder Still…
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.
Conclusion
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.
:{> Andy
You realize the Odyssey just has more plastic on it? It probably has some simplified electronics on it too. Perhaps a few other abstractions, but it is for all practical purposes just an internal combustion engine.
Software development isn’t much different in that respect either. There are simplifications, other abstractions, but at its core the similarities to C or other languages is still there.
Far too many who practice the art of data modelling, don’t know a bit from a byte and do not understand that designing for efficient storage is tightly coupled to designing for performance. These people use nvarchar for all string/character data, and bigint for all integers, because they don’t want to ask questions about the business need, and don’t know how to profile existing data. When I explain to a data modeller that a smallint or tinyit was a better choice than the bigint they installed, the comeback is "it doesn’t really make much difference, and besides, storage is cheap". And my unspoken response is: Go back to school. You just don’t get it. I guess my point is, both education and depth of experience are valuable and relevant across the broad area of IT practice. Too often managers hire the person right out of tech school, or fresh off the boat, because he/she comes with fresh experience in exactly the right xyz technology, and a low end price tag. And then the entire user-community suffers with a sluggish database. Add up the cost in manhours of the whole team waiting on the database. Did you really save money with that hiring decision?
Os carros novos realmente têm uma sofistificação aparente fantástica! Coisa que os velhinhos carros não apresentam. A tecnologia cresce e permite disfarçar alguns pormenores que aos olhos de outros parecem milagres! Mas nem tudo é o que aparenta e a velha tecnologia, o velho saber está lá.
Isto é válido também para a informática. Vejo tantos "técnicos" a consertarem computadores…"hum, o windows não arranca? Ok, vamos formatar!"…chamam a isto técnico?
A nossa experiência, o nosso saber fazer está acima de tudo. Quando trabalhamos há anos numa arte não temos medo de tocar em qualquer coisa moderna, temos a experiência e o bom senso para conhecer falsos conhecimentos e falsos técnicos.
A questão dos dados da DB, por ex., é típica. Tenho colaboradores que colocam qualquer número como sendo real ou int. Mesmo sabendo que o nº em questão não passará dos 5000!!! "É tudo o mesmo, que interessa isso? Quero é programar" – dizem eles.
A performance não é preocupação…
…para resolver esses problemas temos cá os velhinhos que conduzem o velho Jeep. Esses asseguram sempre a estabilidade e calma necessárias ao bom funcionamento de todo o circuito.
Cumprimentos,
JG
The problem is, automobiles are falling into the software trap. More and more control is taken from visible mechanical systems and handed over to inscrutable algorithms (including the infamous throttle controls). I find this dependency and needless complexity very troubling. We are seeing more and more cases where failures of computers, algorithms or sensors have serious (occasionaly dangerous) effects on the car. What happens as these complex systems get older?
Think about it: your Jeep is 20 years old and still viable. How viable is a 20 year old computer?
[I have an 89 Jeep, my wife an 87 MB; blessedly computer free]
I disagree. Technologies change, but someone equipped with solid programming concepts can quickly digest new technologies, even if it’s been 18 months or more. When I look at hiring someone, I look at the foundation more than the specific technologies used. Education and experience mean a lot.
I disagree with Daniel above (to a degree). Build the program first, then optimize. While yes, I also cringe at nvarchar(4000) everywhere, however bigint — ya know, 64 bit OS’s and databases — assuming that the os and database developers didn’t totally screw their apps by not leveraging the hardware correctly, use that 64 bit bus.
That’s not to say use it everytime. But use it if there is doubt. No need to ask billy businessman how long that field needs to be — he won’t know anyway.
Tim, this series is addressed at helping people like YOU!