Old School vs New School Programmers Problems and/or Benefits

Question

I am a recent college graduate working for a large corporation that has an aging workforce. I am curious for peoples experiences on working with an age gap preferably from both sides.

Examples Issues I have encountered so far:

• Agile practices vs Waterfall
• Collaboration between programmers vs individuality
• Working early in the morning vs late at night

I learned primarily agile programming in school while the project I am on (and most of the developers are used to waterfall)

I am used to collaborating with classmates and friends on projects while I tend to see older programmers like to do their own thing. I feel like I pester them asking them questions.

I find myself more of a night programmer, but most of my older colleagues are early morning (5am)

Any experiences on the age gap in the technology work is relevant.

Answer 1

Waterfall is an example of a flawed, non-working software development model. Unfortunately, it doesn't sound like you're in a position to point this out to your aging co-workers. :)

I recommend you keep asking questions to different people until you find someone (or a few) who seem interested in mentoring you. No education or training that I've received in my career has ever been as valuable as the advice of a few really good mentors that I've had.

Once you find a mentor, I suggest you try to work around their schedule, at least for awhile. Don't feel too bad about asking questions, since that's the only way you can learn (Google it, or ask your question on here first, so you don't ask them too many easy questions).

Good luck!

EDIT: Since only the first two sentences of my original answer seem to be getting read, I thought I'd better provide some more links to support what I said.

• The Staggered Iterative Waterfall (Anti-)Pattern
• Waterfall development model considered harmful
• Don’t draw diagrams of wrong practices - or: Why people still believe in the Waterfall model
• Managing the development of Large Software Systems (PDF)

Note that the last one is Royce's original paper.

Answer 2

I have been on both sides of the fence, so to speak.

The problem with agile programming is that, like any tool, it isn't always appropriate for the task. In some environments a waterfall methodology is still effective.

I don't think the collaboration differences come from an age difference, but rather that is the style that has been fostered by that company and the work environment. I worked at a defense contractor for a while just out of school where almost everyone on the project was considerably older than I was but there was a very high amount of collaboration. On the flip side, I have worked for companies where everyone was around the same age and there was almost no collaboration.

People will either like answering questions/mentoring or they won't. Age doesn't necessarily make much of a difference. I have worked with people that are older and younger than I am but there have only been a few people that genuinely like answering questions (whether they were project related or not).

Answer 3

You need to fit in with the group, They won't change to match you, but that does not mean you cannot gradually bring in change.

While you will find some people who don't like to answer questions, most people will especially if you show you are genuinely interested in the subject.

Ask the team leader / manager for a small project you can do using more modern methods (agile might be difficult to do by self). Show people that it works and demonstrate how it is better.

Be tactful and try not to upset people. remember "old age and treachery will beat youth and skill". Don't get in a fight you cannot win. People will resist change.

Answer 4

When I was right out of college, I was a night owl, and I would roll into work in late morning, even though I stayed late for hours after everyone else left. It was really hard to build rapport with other people. It was no surprise that I also felt unwelcome when I tried to ask questions or work collaboratively.

Even though your coworkers use waterfall methods that are considered outdated, it doesn't mean they work ineffectively. An successful project has more to do with teamwork than any particular methodology. Agile methods have codified this idea, but it's still practiced informally in any successful team.

You aren't going to change the way the whole group does their work, so try it their way for a while. Come into work at the time they do. Talk with them at coffee breaks and go to lunch with them. Ask open-ended questions and listen to their answers. You might be surprised to find they have some useful experience to offer.

I'd also recommend against trying to persuade them to adopt agile methods. Instead, you can practice some agile methods de facto. For example, simply ask someone to look over your shoulder to help on a tough problem (people are usually willing to show their skill at solving tough problems). Voila! You're pair programming. But don't call it that! :-)

Answer 5

I don't think the issues you are dealing with are age dependent. I've had great experiences with programmers twice my age and have learned a lot from them. The converse is true as well.

Someday I'll be an old programmer, but that doesn't mean that I have to be "old school".

Continue learning and be open to accept new ideas.

Answer 6

I'm a recent college graduate as well. I work with aging developers, but for the most part they embrace agile methodology and understand why it is a necessary for our purposes to use that instead of waterfall. I'll admit that their execution of it sometimes isn't correct, but at least they try.

I find that corporate interests put a much bigger strain on trying to correctly use agile methods. Try using agile when you got a corporate executive on you telling you to plan all the tasks and estimate the hours for 10 sprints at once. Trying to tell them that it will probably change and there's no point will cause spouts of anger. Problems like that make age differences seem trivial.

Answer 7

As always it depends on the environment and company culture. If you work a corporate job that's open 8am-5pm, it doesn't really matter if you prefer nights...

As for the different methodologies, it really just depends on how "on board" with it everyone else is and, ultimately, whether it produces anything. I'm from the Cowboy Coder methodology group, myself, but I have to reign that in a bit when I'm working on a project that requires a lot of collaboration. And no matter how great the methodology is, if it gets in the way of delivering the product on time, no one is going to care.

Answer 8

Excellent question. I've been in this business almost 50 years, and I'm still learning things.

I guess if I have a gripe it is that nearly all younger programmers had classes in programming, and their heads were filled with normative judgements. It reminds me of the Arthur C. Clarke novel "The City and the Stars", in which the population were indoctrinated with a fear of going outside the city limits that went well beyond reason.

I'm mainly self-taught (in programming), and I have a background in other kinds of engineering. In other kinds of engineering, no idea is feared like the devil (i.e. goto) or elevated to mythic status (OOP). Rather, every idea has pros and cons and situations in which it has more or less utility. Everything is based on math, and inventiveness is valued.

While the younger programmers are bright, willing, and energetic, I wish they were more curious and open-minded.

Answer 9

i apologize in advance if the tone of this sounds harsh, i am actually very amused as i write this because your situation happens all the time, i.e. you're not the first to notice the difference between the 'noobs and the 'oldsters at work ;-)

the first flaw: "old school" vs "new school" - assuming your seniors are "old school" and therefore inferior is called prejudice, and is not a very good way to start your career.

chances are, the "old schoolers" can and will code circles around you, especially in their domain. Since your new job depends on learning their domain perhaps you should learn and befriend them first and try to teach them later, after you have earned their respect...

...and definitely keep your "new school vs old school" prejudices in check; if your "aging" coworkers (as if you are immune from aging!) perceive you to be a know-it-all "punk", no one will want to help you. It really doesn't matter even if you actually do know it all, no one likes a punk. ;-)

so pretend to be humble for the first few months, listen carefully, and be ready to learn more in your first year of real work than you ever learned in college!

as for your specific issues so far, here's another way to look at it:

• waterfall works fine with experienced developers and a target that isn't moving too fast
• what you call "collaboration" i might call "interrupting my concentration"; code tends to be written most efficiently by individual programmers working alone and uninterrupted; continual multi-tasking is inefficient
• working during normal business hours is what normal employees do; get used to it. There is an advantage to being in the office when your customer is also in the office. Of course there are also disadvantages. The balance between the two is called "time management" ;-)

as a corporate noob, you are expected to ask a lot of questions. Just don't jump up and interrupt the seniors every ten seconds like a toddler, save up a hand full of questions and interrupt them only a few times per day.

the good news is, the fact that you asked this question means that you care, and as long as your seniors can sense this about you they will care about you, too.

Answer 10

It sounds to me as if the corporate culture is not one that you feel comfortable with. You have two choices, either get used to it, the culture is not going to change for one very junior programmer, or find another job where the culture is more what you want in a work environment.

The biggest issue of age I've seen in the workplace is that many young people come in with the idea that they are the best, most knowldgeable of the group and what they want is the only way to do things. They think that the work place should revolve around giving them special treatment even though they have accomplished nothing to deserve such treatment. They think they should get the most interesting tasks becasue the boring tasks are beneath them. They don't want to do the hard work of understanding the existing system before trying to change it to whatever is to the coolest new thing. The corporate world just doesn't care if something is cool or fun nor does it care particularly about what the most junior person on the team wants. Maybe that doesn't seem fair to you, but that's the way things are in most companies.

Older workers understand more about how corporate politics work and understand the rules of the game better, so they are more effective in getting what they want. Mind you, I'm not saying that my generation was any better when we were young.

Someday you will be senior, too, and you get to complain about the young and how much worse they are than your generation was. Scary thought, isn't it? (Just when did I turn into my mother? Why am I not still 26?)

Answer 11

From everything I've seen, albeit in a somewhat short period of 3 or so years of industry experience is that all developers fall into 1 of 2 categories regardless of age or experience.

1. Those that are always learning and realize change especially in the software field is inevitable and accept it happily or full out welcome it.

2. Developers that feel they are good enough and just "do their job" and have no interest in growth as a developer.

I've seen many developers both younger and older fall into each category, I would never want to work with any person that falls into the category #2 as they really are inferior and are only a detriment to a project. I would gladly take a college intern that is focused on learning and growing (assuming they can work logic correctly) than any person even with decades of "experience" that falls into category #2.

Too often people don't seem to want to bring this up. Experience isn't by itself a description of what to expect of results. There is bad experience and developers that either fall into category #2 or are subjected to category #2 developers all the time will frequently bring worse experience and more poor decisions into a project than a developer that has no experience and such no preconceived notions.