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?
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 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.