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 dont mean by ethnicity. Im referring to diversity in age. There were shiny new developers and veteran, gray-haired developers.
Guess which ones thought they knew more?
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 everyones time for a few milliseconds of CPU? Give me break!
Im 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 didnt understand at the time was that just because a coding technique was well received and made perfect sense in one environment didnt 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 dont 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 wasnt 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 arent 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, thats all that matters because theyre the ones who are typically writing the check.
This doesnt 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 dont 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 theyre 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 arent tied to a particular design or coding approach. Youth often equals flexibility.
Its much easier to train a puppy than an old dog. So if you bring in a young developer, you wont experience as much entrenched resistance in training them on your groups standards and procedures.
Young developers are less risk averse. Taking risks is essential to discovering new concepts that could be a difference maker.
It isnt that older developers cant 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 youre 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 lets 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.
Theyve 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 cant discriminate by age. Just keep an eye out for traits that may be inherent in new developers and develop over time in old developers.
Its 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 its 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, dont be afraid to share them. But do so keeping an open mind that you dont know what you dont know because you havent experienced it yet.
For older developers with great experience, dont 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.
Eric Spiegel is CEO and co-founder of XTS, which provides software for planning, managing and auditing Citrix and other virtualization platforms.