As soon as I started working in IT, I avoided getting too attached to any specific framework or language. Every company has their preferred framework(s) and language(s), and when you’re working on a specific project, you need to commit to a set of tools and concepts. That doesn’t instantaneously pigeonhole you into them, though. I saw myself as doing software engineering; period. I had, and still have, no interest in being more specific than that.
The problem with that approach is obvious: most job offers will list a specific group of skills that employers expect you to master. In my experience, a lot of employers prefer that you be a framework guy or gal instead of an engineer that has a solid foundation but needs a few weeks or months to catch up with a new toolset. Put it another way, a lot (maybe the majority) of companies prefer hiring what are derogatorily called code monkeys—developers who spend more time executing rinse-and-repeat tasks than reflectively using their intellects to solve problems.
The pigeon and the monkey
I think those jobs and employers suck and you should stay away from them. I mean, whenever you can. (Yes, money does play a crucial role in our lives.) As you may imagine, I took those jobs myself and worked for those employers… More than once. I hated them. A lot. Every cell of my body hated them to the maximum possible intensity. I would wake up in the morning and wish I was sick. Sometimes I would even fantasize myself getting a flat tire on my way to the office and having to take the bike for a fix: “Two sweet hours away from that shithole,” I’d think to myself.
You may rightly object by saying that getting pigeonholed to a technology and being a code monkey are two different things. Indeed, I know amazing people who are very comfortable with a specific toolset and not only solve difficult problems with it but also make a decent amount of money from that work. I also know people who are passionate about a specific technology and blog effusively about it or even contribute to the source code. That’s all great, but those are the exception; the reality is that technology pigeonholing and rinse-and-repeat coding go hand-in-hand most of the time, especially early on in our careers.
Because said companies/sweatshops encourage such level of specialization, employees become very knowledgeable about the language and framework of choice, to the point of memorizing full method signatures and library function names. And there lies the problem. That knowledge, which in that context is comparable to a horse blinker, is actually celebrated as a quality. They’ll call you a “Django ninja,” a “Ruby guru,” a “Hibernate hero,” and all sorts of bullshit that will make you feel important and valuable. Not that you’re not valuable—to such companies, a MySQL rock star is definitely valuable, so long as the technology is still in use by them. But what about you? What’s your plan after that company sinks and most jobs are listing NoSQL instead of SQL? What’s your plan when the only technology you feel comfortable with declines in popularity and market share? If you don’t believe technologies too are driven by market forces, that’s because you haven’t lived enough to see stuff like XHTML and ColdFusion.
The IT landscape is changing faster than ever and, while there are undeniable advantages in being a big fish in a small pond, you should still be prepared for the inevitable changes brought by the aforementioned market forces. So, by all means, be a big fish in a small pond, but more importantly, learn how to be a big fish in some other small pond as well. In the long run, it’s wiser to be able to pick up any new technology than stick to your favorite toolset, as passionate as you may be about it.
You may have heard about the unrealistic high salaries “HTML developers” used to be paid during the Internet boom in the mid and late ‘90s. A lot of them rode that wave without caring to learn anything else relevant, just to get fired as soon as the bubble busted. On the other hand, I’ve never seen a serious decrease in the demand for people who can solve difficult problems and intelligently adapt to any technology.
Career and moat
At this point you may also say that we, as developers, own our career paths and life choices and that companies shouldn’t bear that responsibility. And I’ll repeat that you should stay away from those jobs and companies. Employers should take some responsibility in their employees’ careers. Companies that don’t are not employing developers or engineers; they’re employing disposable cogs, and you don’t want to be one of them. It will eventually, if not immediately, hurt your career—and morale.
How do you avoid those jobs, then? It depends on the job market as much as on you. Sometimes the job market has temporarily dried out and all the listings are for not so great jobs; or maybe the city you live in is not strong in IT and you can’t be too choosy. If you have the patience, though, you’ll usually find something that may not be great, but still better than the previous one. This is how I kept moving up from a shitty job to a less shitty job until, after a few years, I finally got to a non shitty job and ultimately a great job. I’m not saying it will take you that long—my circumstances were very specific. For a few years, all I could do was patiently aim at non-shitty.
To this date, all that “fast climbing” is something I often have to explain to my résumé’s intrigued audience. It’s a no-brainer for most younger folks, but a lot of baby boomers still see it as a red flag:
- How come you worked for so many companies?
- For the most part, I worked as an independent consultant.
- What about the others? Why did you stay at them for such a short period of time?
- Because I found something better.
Don’t feel bad for moving to something better. Most companies won’t think twice before replacing you as soon as they find something better (another person, a robot, whatever it takes), so it’s only fair that we reciprocate. Some companies will even go as far as comparing themselves to a family and have their employees appear on footages where they sit and eat together, hug each other as if they were relatives, all that fluff. Bee ess. Companies are not families. Families don’t dispose of family members due to “underperformance”—the most worn out excuse ever used by HR departments—or lack of “cultural fit.” Mix corporate business and family and what you end up with is the mafia. I don’t think you want to work there either, do you?
Market forces, remember? For companies, their brand and moat come first—employees come after. That’s how it works, and you should not believe that at Company X employees come first, because they don’t. On that note, for developers, our careers come first; employers come after. Just like a balanced chemical equation, the relationship between a company and an employee should be beneficial to both sides. That’s the only possible non-shitty relationship.
You may not be able to avoid being the framework guy or gal for a specific period of time in your career or when working at a specific company. Don’t let that be the rule, though—technologies too have a half life and you shouldn’t rely too much on them. In the (hopefully rare) periods of time when you can’t aim too high, at least aim at non-shitty. Your later self will be forever grateful for that.