During family gatherings, friend meetups, and generally any time I have to get to catch people up on the goings-on of my life, at least some variation of this conversation comes into play.
Them: So, how’s your work life going, you still working at <X>?
Me: Oh, no, I moved on to another job at <Z>.
Them: Ah, so you’ve been working at <Z> for <Y> years then?
Me: Um, no, I’ve been there for <V> years. I worked a few other jobs in between.
Them: …
Me: So… you still work at <company they’ve been working at since I last saw them>
Them: Err… yeah…
IT can be a double-edged sword of an industry because it demands constant evolution. Sure you can spend decades honing your skills at, say, a programming language and become a certificate-wielding recognized expert, but unless you find someone who wants exclusively C#/Javascript/PHP/etc and nothing else, you’re going to have a hard time finding someone to pay you for said expertise. Ask anyone who did coding in the 80s and 90s and you won’t have to look far to find someone who was drowning in jobs for COBAL or mainframe maintenance. Do those jobs still exist now? Some do, but there aren’t many.
Which is why whenever I’m asked by new guys to the industry for advice, I consistently give this: develop your toolbelt width first. You could be a fantastic C# programmer (your metaphorical “hammer” in the toolbelt”), but unless you also know how to use an ETL tool (wrench), or some basic database functions (screwdriver), you’re going to try to use the tool you know best, but not the best tool for this job. Time has a funny way of upgrading our skillsets on their own. After all, if you’ve been doing C# programming, SSIS building, and MySQL maintaining since you got out of school, in 10 years you have 30 years of experience in three combined fields! Granted, your hammer is now a titanium-alloy masterpiece and your wrench/screwdriver is more an aluminum knockoff, but the mere fact you can look at a database, make a few educated guesses on which tables you’re being asked to work with, then pipe that data out to your development environment to code with means that:
1) You don’t have to ask the DBA, Business Intelligence, or ETL team for help (Not because they wouldn’t do it, but your new request has to be balanced against their existing workloads).
2) If you run into an issue with your work, because you are familiar with the different disciplines you know EXACTLY who to talk to when there’s a database access error VS a transformation error, greatly cutting down the number of coworkers (or your tech support group online) to pepper with questions.
3) BECAUSE your questions are pointed, articulate, and succinct, when you reach out for help the answers you get back are quicker, more informative, and usually the correct answer (ie: “hey John, I’m getting a sql error 1064, can you take a look at this query to see what’s causing it” vs “My code isn’t working.”)
In summary, yes, it’s a little scary trying a new skillset. You’ve been a veteran in your field for years if not decades, so it’s potentially humbling to ask basic beginner questions and make basic beginner errors. But that’s the difference between a good tech and a GREAT tech: evolving with your field. Now if you’d excuse me, there’s a Python course that’s calling my name and I’ll be damned if I’m not at least passable at it by this time next year!