Monday, April 22, 2013
Age Discrimination or Reasonable Expectations?
I recently saw a discussion about Age Discrimination in the IT Workforce (http://www.linkedin.com/today/post/article/20130422020049-8451-the-tech-industry-s-darkest-secret-it-s-all-about-age) and it got me thinking about it beyond the immediate knee-jerk reaction of fear about my own job standing. In general, while IT people tend to have an outsized impression of the value of their code within an organization (sometimes deserved, sometimes not) from an organizational perspective most code is simple depreciating assets that will need to be replaced over time. For that reason, the cost issue of paying a senior developer at 55 earning 2-3 times a junior programmer's salary for what is perceived as decaying assets begins to make sense.
Moreover, there are typically several career tracks which employers look for with technical people, and these are very much tied into age and experience. Looked at in that perspective, the age distribution within the industry begins to look a little bit more rational, but it also means that you should be thinking about career management from the time you leave college.
At 25, you're basically an apprentice - learning the "art" of programming, gaining experience, putting in the hours to prove yourself. You don't have a family, you're willing to work 80 hours for a 40 hour a week job, coding is still new and shiny, and the code that you write, while probably not brilliant, will likely be more innovative simply because you're not locked into specific patterns yet. Employers will hire you because they are generally less concerned with quality than they are costs. You're expendable, and for this age group being expendable is not necessarily a bad thing - it gives you exposure to different problem domains, and teaches you how to stay nimble in the market.
By 40, you're probably a good programmer, skilled in several languages, with a few major project successes and failures under your belt. However, your value to the organization increases if you can use that experience to train up, mentor and manage the younger programmers, learn how to knock heads to keep egos out of the way of making deadlines, or to transfer that experience more into architecture or product design. It's also a good time to go journeyman - gain experiences as a consultant, learn how to work directly with clients and how to recognize when problems are better handled with social programming than technological ones. Start working at the systems architecture level. Write a book or three.
As you head into your fifties, it's a better time to start a company, to expand your consulting to large companies or to go into research - it's also not a bad time to go back to school and get that PhD that you didn't have time for earlier, since kids are nearing adulthood by then if not already there, you have a much better breadth of knowledge on which to base your studies and you are far more likely to get into a faculty position or a research institute if you're seasoned with real world experience (and you'll be a better teacher to your students as well).
From an entrepreneurial standpoint you have the connections that are so critical to starting a business and building up a market. As a consultant, you don't have the demands of home and hearth to hold you back any more to the same extent you did when your kids are still young, so you are capable of travel and long distance gigs. You're also more likely to be acting in a mixed business/technical perspective, providing architectural or business guidance while some whiz kid in his twenties bangs out the cool code.
If you're 55 and still doing nothing but coding, senior management will wonder why they are shelling out so much for that code, no matter how brilliant, since they see the code as being ultimately expendable.
I'm fifty. I am a consulting information architect, have written more than a dozen books, and regularly consult with federal agencies and Fortune 100 companies. I still write code, but most of that code anymore gets put into my books or articles or becomes proof of concepts for clients when trying to sell a new technology idea. In other words, the coding is simply a tool in my suite of tools now, The pay is generally better, the ability to influence projects is considerably more significant, and I find it easier to deal directly with the C-level executives that make the decisions.
What this means to a young programmer in particular is simple - expand your horizons. The code is important, but it is not the only important piece in the puzzle, and in many respects no matter how good a programmer you are, it's your ability to navigate the social shoals and reefs that determine how successful you are in your career. As an employer, I'd be as skeptical about a 55 year old programmer as I would be about a 25 year old information architect - neither one has the experience that I need for the jobs at hand.