51–60 of 102 posts
Your time would be better served learning more programming paradigms than languages; the languages are the easy part, knowing how to best solve a problem with that language is the hard part.
I treat languages and frameworks as tools. Oftentimes disposable. My real value is being able to solve a problem in a timely manner. Or even recognize it. With internet so wide and vast there will be people that are better than me at anything.
This is the key. In one way or another, we are all "problem solvers". Hell, that should be my official title at work. Whether it's a network issue, a workstation not booting, a security camera outage, one of our websites down, or even a busted pipe in the break room, I'm the one they call because I can figure out what's wrong and fix it.
Granted, it's a small company so I have no choice but to diversify. They initially hired me part-time for "internet and social media marketing" only, and four years later I'm the full time company problem solver and sole IT staff.
Sometimes it does pay off to step outside your box.
They said that for the mainframe and mini people at the end of the 90s and yet all the people who I know who worked in those areas are still employed, still making good money, and will still be doing so for the foreseeable future. Technology lasts a surprisingly long time and not everybody needs to keep jumping on the new hotness.
Now I assume the folks that made it through that either through persaverance, luck or skill have a pretty good niche gig. But lots and lots of people had trouble.
For example, I entered the tech world in the early 1990s, and shortly found myself specializing as a 'Unix Systems Administrator'[1], meaning one who was well versed in Unix OSs, related things such as shell scripting, Perl, and core infrastructure stuff like DNS, SMTP, NNTP, etc. Back then this was enough to be considered a full job spec and career.
Now it's simply the expected the price of admission for a variety of roles, and trying to find a pure old-school Systems Admin position is practically impossible; the skill set in isolation is no longer marketable.
However, this skill set is the basis of a lot of types of work, including the modern DevOps ideology. In DevOps you add a few tools, learn about real big data, configuration management, and maybe adopt a few more powerful languages to take you beyond good ol' shell. It's not the tools that separate DevOps from Systems Admin work, it's the philosophy and approach.
Those original SysAdmin foundations are at the core of any DevOps engineer. The tools are not radically different, it's the crucial paradigm difference that actually matters.
I'd agree with the basic premise of the author, but I'd add that it's as much about keeping up with evolved methodologies that's as important.
[1] Grandiose title deliberately icky!
jack of all trades, master of none. no thanks, i'll stick to being an expert (and getting paid accordingly) in one field, and adjust when needed. you don't get brick layers randomly learning carpet fitting and welding "just incase"
Actually, to extend your brick layer analogy, what if that's all you do and we devise drones that can lay bricks really fast? Then what? You're going to have to compete with the other 50,000 unemployed brick layers now looking for welding jobs.
A "one trick pony" literally has only worked in one environment/technology but it doesn't imply expertise. An "expert" is someone that the rest of world looks to for guidance in a particular area.
Being the latter is quite valuable, but don't kid yourself, unless you are in the top 0.001% or at least "internet famous" for a given topic, you are not an expert. You are a "one trick pony".
As a for instance, I've spent quite a few years doing low latency JVM work. I can reasonably assume that when I meet a new JVM developer that I am more competent in this topic than they are. But that said, I'm not even the best person at this that I personally know and have worked with. I am no where near an "expert" in this. If I wanted this to be my value add, I would need to spend a lot of time and energy going from competent to expert.
Instead, it is one of many skills I have in my toolkit that helps me acquire new skills and add value to new domains.
Why bother learning another language that is almost the same, like PHP and Ruby? In both you need to keep up with lots of dependencies and practices that keep popping up, and it's a waste of time doing it for both in parallel. I'd say it's better to focus on one language, and if it becomes obsolete I don't see why you couldn't just dedicate a week to master the other one. And anyway I don't see how one of those langu…
I don't think that it is possible to master a language in a week. You can learn the basic concepts for sure but there is usually a lot more like idiomatic problem solving, libraries, frameworks, best practices etc. In my experience you acquire those by working with the language every day for a year or so... and then you are still far away from "master".
In my experience those concepts are not language-specific. More like platform (eg: web) or paradigm (OOP) specific.
"Lifetime careers no longer exist. I knew a bunch of people that were charging $200 per hour to do HTML in the early 90’s. Frontpage ate their lunch." Still sounds like a lifetime career to me. The "one trick pony" will always evolve with the requirements of the time. Though your observations are limited to tech, if a programmer succeeded in something like farming or health science that would make a great career chan…