I’ve heard a bewildering number of career advice claims since I started working in tech. There is always some secret knowledge which you can use to take your career to the next level. It’s not enough to be a coding ninja rockstar or whatever buzzword bingo you see in a job ad, you have to focus on the “metagame” of your career. All of this advice started out with the best of intentions, but each myth became superstitious folklore when taken out of context.
What advice have you heard from people who have succeeded in their career and just how applicable is it? Almost all of it is going to be great advice if you’re in the same spot, but where are you now? There needs to be context or else you’re just blindly following a correlation without considering the causation.
This advice seems to permeate everything technical from help desk to software engineering. I am yet to be in a technical position where I haven’t heard at least one of these myths. The advice is founded on the best of intentions, but there needs to be an understanding of what the goal is.
1. Change Jobs Every Year
If you want to make it in tech, you need to jump ship as soon as you’ve been there a year [or whatever amount of time isn’t a black mark in your industry].
I’ve heard this in almost every technical field I’ve been in from help desk, to programming, to GIS. You also hear it as: The only way up is out. There are countless variations, but the general theme breaks down to: if you want career progress, you need to keep moving.
This isn’t horrible advice to be honest, but it is built on the assumption that all jobs are equal. Most positions are mind-numbing and a lot of your career can feel like jumping from one existential hell into the next. You’re a code monkey, a QA lackey, a ticket serf, or any combination of the above.
Some jobs shine though. They provide growth and excitement; they provide a way forward. Many of the jobs I’ve worked have just been jobs, but a few gave me the tools and the time to really grow and succeed in tech as a career. It all depends on the culture and the composition of the company.
Most likely, you’re best off jumping ship whenever something better comes along, but you have to know what makes a job better. Will you learn more and improve more, or is it just a jump for money? It’s fine to jump for the money, but sometimes it pays to stay and learn. The other side to this is that some jobs take time to really warm up. There’s a procedure you need to learn first, then you start to grow. If you jump every chance you get, you lose out on time which could be invested in skills just learning the local procedure.
2. Focus on Certifications
An employee isn’t worthwhile if they can’t show it, get as many certifications as you can.
We’ve all worked with the paper tiger who can’t back up anything they claim. They may have the piece of paper to prove they’ve learned something, but they don’t have the knowledge to show it. Their certifications show the weaknesses in the testing system or even in the vendor’s ideal workflow versus the real life workflow.
Certifications are a way to get your foot in the door, but how far you get in the room depends on how much you can learn or how much you know. I have a few certifications, but they’ve done absolutely nothing on their own. Most of the certifications I’ve worked towards have been started after I got into the applicable field.
A cert is just a piece of paper unless you can apply it. While every industry has this sort of shortcoming, tech gets hit hardest. You can’t just waltz in and get your Lean Six Sigma, you have to at least sip the Kool Aid. Basically anyone with a pulse and a weekend or two can get their A+ though (though the exam goes from being more worthwhile to less worthwhile and back).
The cert is easy compared to the knowledge to actually use it. A certification is completely useless on its own; it’s just a way towards proving you’ve started learning a new technology or methodology. Never forget that. Don’t focus on the certification, focus on the knowledge and process which gets you the certificate.
3. Certifications Don’t Matter
Certifications are useless on their own, just focus on knowledge and skills.
This is great advice if you plan to stay in highly qualified technical companies, but it falls short fast outside. Google will grill you and try to dig deeper, the local insurance office job will just find someone with a cert because it’s safer. The truth is, most hiring managers have no idea what to look for in technicians (even at technical companies).
I’ve dealt with paper tigers who can talk the talk, but can’t perform, and I’ve dealt with savants who can write a config from memory and not be able to explain a line. Both are going to seem equally useless or impressive without the right technical aptitude to judge them. Knowledge needs to be applied to be useful, but we don’t call engineering “science” either.
Certifications on their own are useless, but they provide a benchmark to back you up. If you plan to stay with a technical firm, you probably don’t need to get some Agile certification if they have a project manager. The problem is, the second you shop outside of tech proper, they don’t know how to measure your aptitude or what to even measure at most shops. To make this even more complicated, some tech shops use certifications to determine progress and growth.
A certificate gets your foot in the door, but you need to be able to sell them on your knowledge. I have been turned down for jobs due to my lack of certs in the most random things. I may have the knowledge, but the hiring manager at some places is smart enough to know that they don’t know how to tell for sure. A cert gives them a safety net of an absolute bare minimum which may be above what they need.
4. Experience Makes Up for Knowledge
Someone with 20 years in the field is a better tech than someone fresh out of college with a year under their belt.
The numbers may change, but the sentiment doesn’t. Not all experience is created equally, but barring knowledge of a better way, it’s easy to come to that conclusion. Many jobs become routine after a while if you don’t push to make them grow.
I didn’t get hired to be a programmer at any of the main jobs I’ve coded for. I started as a map maker hobbling together GIS or a ticket monkey dancing in the Windows world. My decade in Linux amounted to nothing in the world of Windows as far as most interviews went. They didn’t know how to compare my ability to hack out a unit file or delve through kernel source to track a BIOS bug to knowing how to move a mouse on Windows. All that knowledge got me a low tier 1 position.
I lacked the domain knowledge in Windows to move to it easily. I had the equivalent experience, but not the knowledge to talk about it in familiar enough terms in the Windows world. On the other side of this are the old gray-beards who think their 20 years in the field beat a year in the right shop. They could beat you at stripping a laptop down or loading an image, but that didn’t mean they could troubleshoot anything else.
They had the wisdom and experience of working with systems in a specific context, but not the knowledge to back it. It’s the same issue you get when comparing a coder to a programmer. Someone might have 20 years of experience hacking together scripts, but that doesn’t mean they’re as good of a coder as someone with a formal background and a little real life immersion. Experience can make up for certain knowledge, but there needs to be a baseline to build on.
Conclusion
These are just a small group of the most prevalent tech career myths I’ve heard and continue to hear. Again, none of them are strictly wrong, but they require context and a conditional understanding. There is no one size fits all approach to career growth. Rules of thumb can be great, but most career advice is like a spelling rule in English, it only works until it doesn’t.
What sorts of technical career growth “hacks” have you heard in the industry? Where do they go wrong or what do they take into consideration that others don’t? Are there any which have worked out as great in general? I’d love to know what’s worked or hasn’t for you.
Featured image by Maja Kochanowska from Pixabay