Posted on

Five Pervasive Myths About Older Software Developers

I recently celebrated my 40th birthday.  A friend joked to me, “Hey, guess that means you’re too old to program anymore!”  I laughed on the outside, but it gave me pause.  Age discrimination is nothing to laugh about in our field.  COBOL guys faced this problem years ago as Java guys like me were ascending the ranks, and we laughed heartily about legacy code and their inflexibility with new technology.

Now the joke’s on me.  Maybe you too.  And if it’s not now, it will be soon enough.  Still laughing now?  Yeah, I thought so.

Computer Science Degree Trends 1996-2008
Source: CRE Taulbee Survey, 2007-2008, pub 5/09
Computer Science Enrollment Trends, 1995-2008
Source: CRE Taulbee Report

Our field is ripe for age discrimination in so many ways.  We value hot, new technologies, the ability to absorb them at unheard of rates, working insane hours to push products out the door–all things attributed to the younger workers of our field.  And did I mention that younger workers are cheaper?  A lot cheaper.  But the trends of computer science degrees do not bode well for having a plethora of young, cheap workers at a manager’s disposal indefinitely.  In fact, all data point to one conclusion:  CS degrees enrollments have been declining or flat for almost a decade.  And if anything, the candidate pool for hiring is getting worse, at least according to Jeff Atwood.  You’re going to have to hire someone to write your next project, and with the backlash against outsourcing, who you gonna call, Egon?

If you’re thinking you’re going to avoid the “grey matter” of software development, think again.  There are a number of myths about older software developers that continue to be perpetuated in IT and software development that somehow put older, experienced workers at a disadvantage in our field.  But they’re largely crap and considering the degree trends, ignoring everyone 40 and over because we’re too old seems plain foolish.  Let’s debunk these myths one-by-one.

MYTH: Older software developers are more expensive than younger ones, making younger developers more desirable.

REALITY: The real reason experienced developers are labeled as expensive is because staff salaries are the #1 expense of any software organization.  The fact is, younger means cheaper.  But, while inexperienced, younger developers may save you budget, but they will cost you in the long run if that’s all you have on your team.  Younger developers haven’t taken the lessons of failure to heart.  They haven’t had enough time to learn those lessons yet. And guess whose money they’re going to be learning on?  Yours.  Think that won’t cost you money in missed deadlines and incomplete projects?  Think again.

Yes, older software developers have higher salaries than younger ones.  But what exactly are you paying for here?  With an experienced software developer, you’re paying for all the experience that comes with past project successes and failures.  Those are expensive lessons if you want to pay for them directly during your tenure as a manager.  But if you buy into an experienced worker, that’s like getting insurance against some of those classic mistakes in project management and software development that you don’t have to repeat.  Meaning you look better on your annual review because you hired smart people that know how to get the job done.

MYTH: Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.

REALITY: It’s actually because of their past experience, that more experienced software developers can migrate to new technologies, frameworks, and systems more quickly and in greater depth.  For example, if you learn a GUI framework in C/C++, you have a mental model about message passing, event handling, MVC patterns used to design the system and separate presentation from back-end logic.  The very first time you learn a GUI framework, in addition to the syntax, the examples, and the quirks of the library, you also need to learn all the conceptual stuff.  And after two, three or more GUI frameworks, you notice that they all have very deep similarities outside of the syntax.  You might even notice newer frameworks have overcome substantial limitations that you used to have to work around with complicated hacks.  Those insights are lost on someone new to the framework.  And those insights can really boost productivity in ways you’re not able to directly measure.

MYTH: Older software developers are less able to perform the arduous tasks of software development (read:  work long, painful hours) because of family commitments and other attachments that younger workers don’t have.

REALITY: I think it would be fair to state that experienced software developers are less willing to work those long, painful hours because they’ve learned the hard way that there are productive limits to pushing yourself 80 hours a week for months on end.  It’s called burnout, and I’m willing to bet that anyone who has already experienced it in the past simply isn’t as eager to go there again.  But with that said, the supposed reason of “family commitments” is bogus.  High-quality, experienced software engineers are ruthless time managers, and those with families are even more motivated to get things done in allotted times.  They may have dance recitals and soccer games to attend to, but they also make up that time in off hours and highly focused work during the 40 hours they’re given in a week.  Good software engineers with families must become highly efficient with personal time management or they quickly get buried with the deluge of work coming their way.

MYTH: Older software developers are less mentally agile than younger ones.

REALITY: Aging does affect the brain and it is measurable to show that older workers think more somewhat slowly than younger ones.  But mental agility is only part of the equation.  Thinking faster isn’t always better.  What about judgment?  There’s an old expression:

Good judgment comes from experience, experience from bad judgment.

Lost mental agility is a poor excuse to not hire an older software engineer in light of the fact they’ve seen, done, and lived many more successes and failures than a younger developer.  Experienced developers have tons of past projects to draw from and assist in avoiding bad decisions today.  Younger developers have new ideas which are important, but often untested and unproven.  Having both perspectives on your team is of great value.

MYTH: Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones.  Younger developers are more enthusiastic than older ones.

REALITY: Anyone who believes this is probably someone who doesn’t like their ideas criticized by those who’ve been around long enough to see really stupid decisions put into practice again and again.  Experienced software developers smell crap a mile away.  They don’t buy your stories about how the product isn’t well received in the marketplace because they’ve been interacting with the customers for years and know you’re trying to cover up a future layoff in the company.  They won’t put up with managers asking them to work 80 hours a week because the customer wants the software next month and they already told you it will take 3 more months to complete with the features agreed upon.

Younger developers haven’t been in those situations as frequently and therefore, have less resistance to bad management practices.  The only desirable trait management wants here is naivete.  If you want a great team and great products coming out of it, having people that can call you out on bad decisions will save your bacon again and again.  But only if you have the courage to admit you don’t know everything.

And as far as enthusiasm goes, you can’t tell me age dampens enthusiasm.  If that was the case, Donald Knuth, Ward Cunningham, Bill Joy, Bill Gates and hundreds of others who’ve crossed the magic 40 barrier would be less interested in our field just because of age.  But they’re not.  Passion is passion. If you have it when you’re 40, chances are you really love that field.  That kind of love isn’t going to die overnight.  Younger developers still finding their footing in the world may have short-term passion, but that can be swayed in the face of obstacles and challenges in the field along the way.

In conclusion, let me be absolutely clear about a few things:  Young is not necessarily bad. Old is not necessarily good. And most importantly, anyone who can’t program their way out of a wet paper bag shouldn’t be hired, no matter how old or young they are. Keep your teams a vibrant mix of age and experience–where diversity exists, learning can take place.  But if you’re the person looking to hire someone, don’t write off the dude with the gray hair sitting across from you.  Let go of your age prejudice and see if they can impress you.

Someday that dude (or dudette) may be you.

Posted on

Trust But Verify, A Consulting Love Story

About 12 years ago, I was a member of the Professional Services Group for a C++ tools company.  They created a great framework for C++ classes, particularly dates and strings, that really didn’t exist in a standard format at the time.  They dominated the market because their tools were second-to-none.

One of my many gigs at the company took me to Dallas, Texas, home of great bar-b-que and technology companies.  My observation upon arrival is that the density of the two is approximately 1:1, or at least it was at the time.  Coincidentally, another colleague of mine from the same company was also on assignment during the same two-week period at a company just down the road, a major telecommunications company (let’s call them “Lint Communications”).  Not coincidentally, I think lint was all that existed between some of the managers ears at that company.

My friend was tasked with porting the C++ toolkit over to OS/390 for Lint Communications.  This sort of work was typical for our group–anyone who wanted support for our libraries that was outside the supported platform list usually hired Professional Services to come on-site and create a custom build for them.  After you did a few of those, it was mind-numbing work usually consisting of chasing down obscure compiler parameters and libraries in paper manuals at a time when Google and the Internet were not really up to the task of storing that information.

Oh, did I mention that our company charged about $500,000 for a single OS/390 license?  Yeah, so there was serious cash on the line.  That might be important later.

This gig started out innocently enough.  We had dinner about midway through the week, during which we traded war stories:

Me: How did it go today?

Friend: Uh, it was kind of weird.  They are telling me to finish the port, but they are talking to the sales guy like they’re not all that interested in it.  Something about it not working right.

Me: Did you run the standard test suite?  Did it pass?

Friend: Yeah, flying colors.  No problems.

Me: Did you offer training or help?

Friend: Yeah, they tell me they don’t have time right now.  One other thing though…

Me: What?

Friend: Every hour, on the hour, the file system slows to a crawl.  Kind of seems like they’re taking backups of it or something.

I should tell you that my friend was a junior engineer working in our group and this was one of his first gigs.  He seemed to think this felt wrong, but he just wasn’t sure.  At this point, my alarm bells were ringing.  Here we had a customer that was paying good money to have an engineer on site, but telling the sales rep that the product wasn’t working and they didn’t want help to fix it.  And taking snapshots of his work.

Our conversation continued:

Friend: What should I do?

Me: Finish the port like they asked.  However, just in case, put in a time-bomb.  Something not easy to find on quick inspection inside of our headers that will kill the library after a certain date.

He completed his work and put in the Trojan horse in the string library, something like:

#if !defined(SOME_OBSCURE_COMPILER_OPTION_THEY_WOULDNT_GUESS) {
      if (today > some_magic_date) { exit(DONT_STEAL_ME_BRO); }
}

After we returned from our jobs, we learned from the sales rep that they decided not to purchase the software license and they deleted the software from their mainframe.  We considered the matter dropped and went about our other projects.

About 45 days later, our customer support department got a call from Lint Communications.  They complained that our toolkit was crashing their application every time they launched it, based on stack dumps.  A quick search of their customer information confirmed they had no purchased licenses.

Sure enough, they had continued to use the OS/390 port without paying for it.

Our sales group negotiated a nice settlement with them to the tune of almost $3 million for a license deal after agreeing not to sue them for piracy.  After that, my friend turned over the compiler option to Lint Communications that was required to shut it off.

I learned a critically important lesson in consulting that day:  Take the customer’s word, but make sure they are telling the truth.

Trust, but verify.

Posted on

Developer Lessons from Diablo II

Diablo II (DII) may be an old game but it’s a classic.  I’m one of thousands who gave up hours and hours of my life to it.  I have very fond memories of those times, staying up late with my friends on the phone, hacking evil monsters to bits, making the world safe again.  I think it’s a great form of geek therapy where no matter how bad your day was at work, taking out all the monsters on the Arreat Summit would somehow make things feel right and good in the world.

And with all that time invested in the game, there were a few lessons that are very applicable to real-world software development.  With Diablo III now generating a new wave of excitement for Blizzard’s series, I thought I’d share my insights from my favorite game of the early 21st century.

Take care of the monsters that spawn other monsters first

In the second act where you’re in the Kurast jungle, there are these incredibly annoying and potentially dangerous witch doctors.  Each witch doctor can summon more helpers that continue to attack you and drain your resources.  If you’re surrounded by 10 witch doctors and those incessant little critters they spawn, you’re in for a world of hurt, especially if you just focus on the spawned critters.  You need to hit the witch doctors first, ignoring the rest of the group, before you start attacking what’s left.

Lesson learned: Any problem that is creating additional, more painful problems, needs to be addressed early on in the process before worrying about others.  For example, if you have some serious bugs that continue to crop up and cause your team to spend cycles constantly nursing production systems along, but the fix is going to be hard and take away from your current development, perhaps the fix is worth the time considering the amount of time wasted in keeping the system healthy.

Brute force counts for a lot most of the time…

Subtlety is not really rewarded for the majority of DII.  Your best bet as any class is to pick the weapon, spell or skill that basically will take out the highest number of monsters given the situation.  That “silver bullet” is constantly changing depending on the Act or the area as monster vulnerabilities and resistances change.

Lesson learned: Pulling out your best code tricks for each and every part of the system can potentially be a waste of time.  This is just another way of saying that premature optimization is the root of all evil.  Use the simplest algorithm, framework, or idea that solves the problem.  Go ahead, put that brain dead String concatenation method in there…chances are, it won’t matter all that much in the larger scheme of things.

…But you need to be subtle around the Boss

When you face the Boss creatures on any level in DII, suddenly you’re forced to adopt a clear cut strategy.  Brute force won’t cut it, and even with a larger party you still need to work together and with great care to take down the Boss creature because he will most certain pwn the unprepared.  Certain character classes have advantages when facing the Boss depending on their vulnerabilities.  When I was a Necromancer, facing the Boss at the end of Act I was a real bear for me alone, but my Barbarian friend could easily take him toe-to-toe while I dumped damage into him from afar.  Together we made a big difference.

Lesson learned: You can’t always beat the code down with brute force.  Some very specific problems require a lot of thought, time and energy.  Pick your battles and choose your weapons to attack these problems carefully.  Sometimes, you’re not the best one to deal with the problem…maybe you had a hard time implementing the original solution.  Ask a colleague to step in and pair program it with your, or maybe even offer up their solution ideas for a fresh perspective.

There’s always a new shiny thing to go get

There’s always a better, bigger, faster, shinier, more powerful item to go get.  Whether you’re 10th level or 90th level, the quest for the Bigger, Better Mousetrap will always go on.  You will never have enough Elite Rare items, no matter how many of them you get.  There’s no winning this game but patience and persistence will get you what you seek if you’re willing to put in the time and effort.

Lesson learned: Newer technologies, frameworks and languages are always out there.  They will continually tempt you into thinking that your current technology isn’t nearly as good as What Is Out There.  Never let technologies drive your solutions past the original choices phase unless you’ve discovered a critical flaw in your original analysis.  For example, if you find that your database connection pooling solution simply cannot perform at the level you specified or tested that it would, it would be worth reexamining that particular choice.  Make a choice, stick with it for long enough to finish something with it.  Wait for the right moment to upgrade.

There’s no one best way to play the game

One of the great things about DII and other MMORPGs is the variety of characters you can play–Amazon, Necromancer, Druid, Barbarian, Sorceress, Paladin, Assassin or Monk.  Each has its own unique abilities, skills and fun factor.  I personally enjoyed the Necromancer and the Assassin–the former for summoning hordes of skeletons to do my dirty work and the latter for having the coolest looking claws to take monsters to the mat.  Anyone who says that <insert character here> is the only way to win the game, clearly hasn’t tried the others with similar zeal.

Lesson learned: Trying out new languages and frameworks is a great way to chase away boredom in your career.  Just because you did your last 5 projects with Java doesn’t mean it wouldn’t be interesting or worthwhile to try the same kind of project out with Ruby to see how it varies.  Maybe it will make you a better Java developer because of what you learned in Ruby.  Language snobs are boring and generally one-dimensional.  You’ll be a better developer for stretching your boundaries and limits in things you don’t understand as well as your native language(s).

Blind experimentation is a waste of time and resources, better to leverage others work first

The Horadric Cube was an essential piece of the game in DII but it could be a source of frustration if you didn’t know what really worked in it.  You had two choices with it:  Spend lots of time systematically putting things in and pressing “Transmute” to see what happened (which, depending on the items you stuck in, could be hours or days to re-find if you later discovered you made a mistake), or just look up the recipes online and then start hunting for the right items to make things work.

Lesson learned: Spinning your wheels experimenting with a problem when better and more complete information about it exists in other places is just a waste of time.  Reinventing the wheel might be fun, but it’s unlikely to be the best use of your time when the project clock is ticking away.  Stand on the shoulders of giants and leverage all that great information others have posted on the internet about your framework, language or technology.

Sometimes there is a secret cow level and it’s fun

If you found Wirt’s Leg and a Tome of Town Portal, put those in the Horadric Cube after you defeated Diablo on a level, there was a red portal to a secret cow level:  you got to go whack some cows for a change.  But not just any old heifer.  These were mean cows.  Big, bad cows.  Cows you wouldn’t be tipping anytime soon.  But damn, it was hilarious.

Lesson learned: Unexpected surprises are fun.  And never underestimate the Power of the Bovine.  Celebrate the absurd every now and then.

No matter how deep you are in Hell, it can always get worse

You made it all the way through Diablo II’s Normal level thinking, “Wow…that was hard.”  Until you turned on Nightmare and realized that you ain’t seen nothing yet. Those little rats from the first Act?  Wow, they’ve got serious bite now.  And Baal?  Well, let’s just say that Full On Bad Ass is an understatement.  You might have gotten away with quick and sloppy the first rounds with the Boss scenes, but that’s not going to cut it this round.

Lesson learned: If you think your performance problem is bad in production, consider what might happen if the entire server farm crashed.  Or if you’re dealing with a major crash, what would happen if you had 50% hardware failures instead of just a software problem?  The list goes infinitely deep, each more terrifying that the previous.  Complaining about the problem isn’t going to help.  You might as well be thankful your situation is not worse and deal with what you have.  If you did something that was sloppy during the product development, own up to it, fix it and move on.

There you have it.  Eight fun lessons from Diablo II.  Got a lesson that I missed?  Talk back below!