Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Those words really ticked me off. I remember like it was yesterday, sitting there in a team meeting with the entire development team.
The team was quite diverse, and I don’t mean by ethnicity. I’m referring to diversity in age. There were shiny new developers and veteran, gray-haired developers.
Guess which ones thought they knew more?
Wrong! Both the oldies and newbies thought they were more brilliant than their counterparts.
I happened to fall into the newbie category. We were arguing about the need to improve performance on an inventory management application written in COBOL. I was showing off some performance enhancement tricks I learned on a prior project (something to do with signed versus unsigned fields) and insisted we go back and modify all the fields to improve performance.
The oldest developer in the room laughed at me. Literally.
“You want to waste everyone’s time for a few milliseconds of CPU? Give me break!”
I’m sure my face turned red. I was sure that these changes would be worthwhile because I had received a pat on the back on my last project for this suggestion. This was because every saved millisecond helped to ensure batch jobs were completed on time, overnight, for shipments to be sent on a timely basis.
What I didn’t understand at the time was that just because a coding technique was well received and made perfect sense in one environment didn’t mean it would achieve the same result in a different environment. Not by a long shot.
It turns out that book learning and limited real-life experience don’t provide all the answers. The main reason for this, of course, is because answers can be different depending on the context of the question. In a perfect world, all code is written perfectly with outstanding performance. It meets all the requirements, on time, within budget.
But our world is far from perfect.
On my new job, the emphasis wasn’t on processor speed, but on the backlog of requirements building up in conjunction to budget cuts.
See, in the real world that all “elder” developers have lived through, the answers aren’t always so black and white. You have to make difficult choices because of limited resources – staff, budget, equipment, etc.So you learn to make compromises. You have to.
This drives most new developers crazy.
A young buck (or doe) will dig in their heels and say “Not fair! I refuse to cut corners and write sloppy code!”
An experienced developer will say “Here we go again. Ok, how can I get creative to solve this problem?”
Granted, the results may result in a slower system. But as long as the results are accepted by your end- user, that’s all that matters – because they’re the ones who are typically writing the check.
This doesn’t mean you sacrifice coding standards across the board. Older developers who have inherited spaghetti code know the importance of clearly written software that is well documented for maintainability.
It only takes a few minutes to write codes to standard, but it may take hours of experimentation to find the most enhanced approach to stellar performance. You simply don’t always have that time.
Does this mean a manager should always choose an older, more experienced developer over the younger generation?
Of course not! Young developers bring a lot to the table.
Forgive my generalizations, but here is why having youth on a development team is a good thing:
Many youngsters start writing code as a teenager because they’re fascinated by technology. By the time they graduate with a computer science degree they have many years of experience. Not just any experience, but relevant experience with a great grasp of the latest technology trends.
They are very open to new ideas and aren’t tied to a particular design or coding approach. Youth often equals flexibility.
It’s much easier to train a puppy than an old dog. So if you bring in a young developer, you won’t experience as much entrenched resistance in training them on your group’s standards and procedures.
Young developers are less risk averse. Taking risks is essential to discovering new concepts that could be a difference maker.
It isn’t that older developers can’t also exhibit these traits, but my experience is that once you have worked with a technology for a long time, it is hard not to end up with a form of tunnel vision where every problem you tackle is framed in the technology that you’re so used to using.
Now before I start receiving hate mail from you older developers, let me state that, yes, it is true there are many gray-hairs (or very-few-hairs like me) that live and breathe technology and are just as up to date on the latest trends.
And let’s not forget that learning the business side of technology takes time. This is where the more experienced developer really shines – especially those who have worked in one industry for a very long time.
They’ve become experts in finance, manufacturing, etc. and therefore have a much easier time helping end-users come up with workable solutions learned through hands-on experience.
The key for any manager is that you must evaluate each person individually – you certainly can’t discriminate by age. Just keep an eye out for traits that may be inherent in new developers and develop over time in old developers.
It’s your job to help guide both of them to help them realize their shortcomings and help them become even better developers in the long run.
I have found it’s always best to have a nice balance of experience on a development team. Different generations of developers can learn from each other.
If you are a new developer with great ideas, don’t be afraid to share them. But do so keeping an open mind that you don’t know what you don’t know because you haven’t experienced it yet.
For older developers with great experience, don’t be immediately dismissive or threatened by new ideas proposed from your younger counterparts. They may broaden your vision. And you may actually find that the fresh-based developer really does know what they ‘re talking about.
ALSO SEE: Are You a Blue Collar or White Collar Developer?
AND: Are Software Developers Naturally Weird?
Eric Spiegel is CEO and co-founder of XTS, which provides software for planning, managing and auditing Citrix and other virtualization platforms.
