Some time ago, I was in a work meeting with someone who spoke in a tone far too loud for my ears, with a level of technical self-assurance that was a little unbearable, to be honest. When he spoke to me, it felt as if he were examining me. Later, someone told me about his professional background, and I was deeply disappointed, with all due respect. Two years earlier, I had worked on a promising, interesting, growing project led by undoubtedly capable people—but throughout their careers, they had only known that one promising, interesting project. Every now and then, I receive résumés from computer engineers whose work experience consists of far too many years at the same company, in the same department, doing exactly the same thing.
Of course, everyone does what they can to advance their career. Ultimately, we’re all free to do whatever we want with our time and lives. Spending years on the same kind of work isn’t good or bad in itself; what I want to point out is that it can be dangerous. Sometimes people oversell themselves, presenting a professional image based solely on their years of experience, or even boasting about having worked for many years when they’ve actually spent that time doing a very limited set of specific tasks.
What bothers me a little—and I’m sorry—is when someone waves their years on the job as the sole proof of their technical or management competence: just that, a long time, as if that alone made their résumé more credible.
In my opinion, the number of years you’ve worked in one field or another isn’t the only thing that matters; so does what you’ve done with all those working hours at one company or another. Working on two or three similar projects is nothing like working on twenty completely different ones. The person who has done the latter has a much broader and richer perspective, even if they’ve spent half as long doing it as someone who has spent twice the time on the same kind of work.
What isn’t always obvious is that you can work for many years and still have just one year of experience, because for the rest of that time you’ve been repeating exactly the same activity. In a way, you keep waking up in the same place every morning, like Bill Murray and Andie MacDowell in Groundhog Day.
After working on many completely different software projects, you may develop a certain intuition for choosing one technology over another, making design decisions, and even sensing whether someone might be a better fit for one team or another. When you’ve worked in depth with certain kinds of large systems, you broaden your perspective when approaching new ones.
It’s true that everyone likes working in a comfort zone where they have everything under control. But I learned a long time ago that staying in it for too long is harmful in a profession as volatile as it is complex. Before you know it, you can become a dinosaur who will struggle to fit in anywhere outside your company.
Yes, you can have fifteen years at a multinational company and still be a technology dinosaur. There’s nothing wrong with that, but keep it in mind if one day you have to leave the only comfort zone you’ve known for so long.
This is especially problematic for technical professionals who move into management as their only activity and, after a year or two, quickly lose most of their technical skills.
You can’t claim to have fifteen years of experience if you’ve spent all that time updating operating systems, maintaining an application written in COBOL or C, or programming a particular type of device—and then proudly cite your years in the industry when, in reality, your professional world has been quite narrow.
In other words: quantity (time) matters, of course, but quality (a variety of experience) matters much more. Ideally, you have both: time plus real experience across many different projects.
If you’re a technology dinosaur (just a metaphor), there’s nothing wrong with that, of course. But it can become dangerous when you suddenly have to change course, get laid off without warning, or find yourself having to make it on your own.
I’ve also found that working in a range of very different areas can enrich a new project you’re starting, even when you don’t yet know how to build it. For example, Drupal’s extensibility mechanism, and those of similar environments, is a good architectural model that can be replicated in other kinds of systems. A simple, useful module like Squel can show you how useful method chaining is when you need to build a client for an API with a completely different purpose. And knowing several frameworks well can give you ideas for how to approach things when you’re the one making design decisions for a new one.
But it doesn’t help to say you’ve spent fifteen years developing WordPress-based web applications and little else, developing firmware for remote-control devices, working on the same system for the same company, or maintaining a project that’s been running forever for the same client—and to say it with an air of self-satisfaction. Don’t fool yourself. You may not realize it, but your experience is quite limited, no matter how much time has passed.