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.
I visited a workshop a few weeks ago, and also attending was a COBOL programmer (in his 50s) who still was active on that platform. I wonder whether it could be lucrative to learn COBOL (and CICS!) and work on those legacy systems that are still out there. "While CICS has its highest profile among financial institutions such as banks and insurance companies, over 90 percent of Fortune 500 companies are reported to ru…
Please Do Not Be a One Trick Pony
21–30 of 102 posts
Re: Please Do Not Be a One Trick Pony
#22I was actually speaking with a a friend and tech recruiter about this yesterday. He mentioned that actually, being a "One Trick Pony" is pretty good for people looking to contract. Obviously he didn't mean simply knowing one language or framework and no others whatsoever but rather that for contract work companies are looking for people that are highly specialized to come in for a very short period of time. A Full-St…
"I feel like getting a mysql dba job so my resume will portray me as a mysql DBA one tricky pony because I'm sick of writing Perl backends and Scala CRUD at this instant and don't feel comfortable enough with Clojure for paying work"
vs
"OMG I really am a one trick pony who only knows one thing that being mysql"
Re: Please Do Not Be a One Trick Pony
#23Why 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".
Re: Please Do Not Be a One Trick Pony
#24But, being an expert is where its at. Companies will pay a premium for an expert over an enthusiastic amateur, because its less risky.
Re: Please Do Not Be a One Trick Pony
#25I was actually speaking with a a friend and tech recruiter about this yesterday. He mentioned that actually, being a "One Trick Pony" is pretty good for people looking to contract. Obviously he didn't mean simply knowing one language or framework and no others whatsoever but rather that for contract work companies are looking for people that are highly specialized to come in for a very short period of time. A Full-St…
It's great when companies find someone who solves their exact problem, it sucks when you're the guy who can only solve one problem though. Especially when someone finds a way to automate a solution. I think Valve described the 'T' employee: know one area very deeply and a broad range of others reasonably well. Seems to be a good approach :) Maybe another way of looking at what your friend said is to just be specific…
But in our industry, what is been automated away? The only things I can think of are that if you were an expert, you'd be very well placed to leverage that automation.
Re: Please Do Not Be a One Trick Pony
#26I was actually speaking with a a friend and tech recruiter about this yesterday. He mentioned that actually, being a "One Trick Pony" is pretty good for people looking to contract. Obviously he didn't mean simply knowing one language or framework and no others whatsoever but rather that for contract work companies are looking for people that are highly specialized to come in for a very short period of time. A Full-St…
It's great when companies find someone who solves their exact problem, it sucks when you're the guy who can only solve one problem though. Especially when someone finds a way to automate a solution. I think Valve described the 'T' employee: know one area very deeply and a broad range of others reasonably well. Seems to be a good approach :) Maybe another way of looking at what your friend said is to just be specific…
Re: Please Do Not Be a One Trick Pony
#27jack 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.
The point is that you spend the time to truly become an expert in an area, most of the skills will be easily transferrable to an orthogonal position. Dabbling in a bunch of crap on the side doesn't really get you anything except for a false sense of confidence that gets blown away when an interviewer asks you any reasonably hard question about it.
Re: Please Do Not Be a One Trick Pony
#28They 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.
You won't be able to work with Web/Embedded/Mobile. Your developments will probably be "new report at bank" or "fixing new bugs"
So, unless you learn other stuff, it might get you the money but it's probably something veery boring (even more boring than your corporate CRUD app)
Re: Please Do Not Be a One Trick Pony
#29My trick: satisfying my customer's requirements, whatever they are, with whatever tools I need. Some of the tools I used in the past year are less that 5 years old, some more than 30 years old, and some much older than that (pencil & paper on a clipboard on a loading dock).
Figuring out what your customer needs, then what you need, and coming up to speed on that is much more important that any keyword on your resume.