Please Do Not Be a One Trick Pony | Hacker News Reader

Please Do Not Be a One Trick Pony

jacquesmattheij.com

113 pointsjanvdberg98 comments

I think one thing to keep in mind is the difference between "one trick pony" and "expert".

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.

> 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.

That still isn't enough. Until you invest in the branding/marketing aspect, it doesn't matter how good you are, you will never be considered an expert by those who aren't experts themselves. That's the people who hire and pay experts.

Don't worry about being better than everyone you know. You're the expert, obviously you know people who are better. But potential clients don't. They probably don't even need someone who's better than you. You can solve their problem while a "better expert" is busy doing something else.

Most niches will gladly handle more than a single person serving that niche.

I'm not sure what this has to do with the Jacques's piece. Being an expert is orthogonal to people paying you to be an expert is orthogonal to being a "one trick pony".

You don't need to be "in the top 0.001%" to be seen as an expert, and I think you underestimate how easy/valuable it is to become known on the internet ("internet famous"?) as an expert on a narrow topic. Let alone how easy/valuable it is to become known in specific real life professional circles.

At one point I completely accidentally and without any deliberate effort became known as an "expert" in a certain technology in a certain mid-size city, which led to a lot of work. I probably wasn't even in the 50%. I wasn't a "one trick pony" in the sense Jacques means either, I was just doing what people were paying for - I didn't even like it.

The way to prevent your skills from becoming obsolete is to learn related skills rather than very different ones.

The people making money writing pure html in the early 90's who are still employed mostly didn't move on to writing systems code in C or business logic in Java, they learned css, javascript, and/or Flash and kept making web sites for clients. The ones who managed to keep charging high rates did that by always being just in front of the curve on 'hot' technologies.

Indeed. Taking a language- rather than a domain-centric view is a hallmark of inexperience.

This applies in more fields than just programming. I've won a number of clients over the years based on the fact that most of my competitors (business strategy coaching / consulting) are 'one trick ponies'.

"How are you different to X?"

"My company has IP that addresses all 20 areas of business, and I work as part of a team so I can ship in a specialist if need be.

"X is great at following the bouncing ball to give you a marketing plan - if you have revenue issues, they will sell you a marketing plan; if you have culture issues, they will sell you a marketing plan; if you want to exit your business for the highest valuation in 2 years, they will sell you a marketing plan.

"When you only have a hammer, every problem looks like a nail. They only have a hammer, so you'll never be able to trust them when they diagnose your problem as a nail. A nail which needs a marketing plan."

-----------------------------------

s/marketing plan/ruby on rails

s/ruby on rails/julia

s/julia/.NET

That's a great line.

When I became a marketing consultant, I made a decision to never sell marketing plans. When I worked at an agency, I would cringe when we delivered 100-page (and more) marketing plans because I knew not a single word of it would be read, let alone implemented.

Still, people are out there selling these plans, and whatever are the generic equivalents in programming. Which is why your line is probably very effective.

s/marketing plan/engineer/g

Always be yourself. Unless you can be a unicorn. Then always be a unicorn.

So hard to code with 4 hooves and one corn. Been there, done that. Mexico, never again.

Charlie? Charlie Root? Charlie??!?!... is that you?

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.

Yeap. The highest earning programmer I know is still writing COBOL for the same employer, as he has for the last thirty years.

Staying still can be fine, if you know what do bet on. A fast moving target like HTML is just not a good bet. Get on board of a tech entrenched in the enterprise world and you can probably make a good living for many years to come.

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 run CICS along with many government entities." - Wikipedia

There are COBOL devs who actually realize what they are worth and billing (banks) 200-300k accordingly.

I have a friend who's fairly young (early 30's) who heard about an opening in COBOL that a company couldn't fill, taught himself COBOL just to fill that position and ended up running his department and getting headhunted from others. Sometimes learning obsolete technologies can be a great career builder. Just make sure there's a shortage in your area.

The COBOL classes at my university were basically sponsored by a large local bank, and they would give a job offer to anyone the professor recommended.

It might pay the bills, but you'll work on exactly ZERO new developments.

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)

Most jobs in Web and Mobile are fairly boring. People program Wordpress Templates for a living. Fix bugs on rails installations. Run 400 Servers that run a shop. The next app that displays data from an API. Actually, very few jobs are "exciting" as in "really new development or research that was never done before".

Boring is where the money is, because no one will do the boring work for free.

I'd pick fairly boring work with a nice team over interesting work with assholes every single time. Some people also prefer boring as in "uneventful" since they have kids, family, other obligations and value having a 9-5 job over interesting. There's a lot of reasons to pick boring. I can have exciting hobbies after work.

Agreed. I think we tend to underestimate how highly people value interesting work. If you want to do work that most people would rate as interesting, you're going to pay a very high "passion tax" for the privilege. People will put up with more competition for fewer openings, drastically lower salaries, longer hours, worse work environments, and meaner coworkers, in order to do work they feel "passionate" about.

I have interesting hobbies and am happy to do boring work in exchange for the better pay and working conditions and more free time to spend on my hobbies and family.

> If you want to do work that most people would rate as interesting, you're going to pay a very high "passion tax" for the privilege.

True. See game companies

Of course there's a whole spectrum between "boring" and "cool", and even games have some very boring parts

I will do boring if the pay is high enough. Learning a new JS framework every 6 months can get kind of tiresome as well I imagine.

What is so bad about boring? Boring means low stress, and easy work. As long as your life outside of work is fulfilling, there is nothing wrong with doing a boring job for good money.

Boredom is a major cause of stress. Maybe this discussion would go somewhere if the terms were actually defined?

I work with web/mobile. My job is still very boring at least 75% of the time. E-mails, admin, client contact, delegation of jobs to staff I'm responsible for - and that's before we get to the boring parts of the job itself. We can't all be working on brilliantly exciting stuff all the time.

This is not necessarily true. I work at a mainframe shop and we have a lot of very interesting projects to work on.

Though, my experience may be unique since we're an ISV, not a business apps shop.

I think maybe you are experiencing survivor bias? Because I know tons of mainframe and mini guys who either a) retired b) left technology or c) retrained. The 2002-2004 years were bad for lots of people, but the mainframe guys were brutalized (at least in the industries/companies I was working in). Devs who a few years earlier were commanding 400-600 an hour with all the work they wanted, could not find operator jobs.

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.

My mother is a mainframe person. She was back in the 80's, she was in the 90's, she was in the 00's and she is in the 10's. The difference is as the supply of mainframe people goes down, her pay goes up.

I 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-Stack Super Ninja Developer is still a good thing to have on payroll but you're going to need some temporary guys that know one part of your stack inside out, especially at scale.

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 about your skills/experience when job seeking?

http://en.wikipedia.org/wiki/T-shaped_skills

How about diversifying then? Not in the sense of knowing everything shallowly. But in the sense of knowing like 5 things very deeply.

Icebraining's wiki link below hits it on the head, but my view is that knowing too much stuff deeply might make it hard to collaborate in teams as it makes roles really hard to define.

Happens in soccer a lot - teams with really versatile players will usually get whipped by teams who have specialists in each position. Top teams aim for squads with 2 players for every position, not 2 positions for every player.

Hope that makes sense, it's getting late here :)

> Especially when someone finds a way to automate a solution.

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.

I've been a contractor for roughly a decade now and I can say that it's much better to be a generalist than a specialist. My personal skillset ranges from hard real-time embedded/bare metal work through desktop systems, GUIs and server side stuff with higher level languages. Even been learning some Clojure... I've never been without work in ten years and have always gone from one job to the next. In comparison, I know people who know only one area and they are a quite regularly 'between contracts'...

Another important aspect of talking to a recruiter is there is a huge difference between

"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"

"OMG I really am a one trick pony who only knows one thing that being mysql"

I personally appreciate the knowledge and experience I've had from using different languages, libraries, and implementing different projects (personal and professional). I also think this is pretty sound career advice.

That said, being a professional Clojure developer, I was surprised by Rich Hickey's advice on mastery [0], and think he likely has a point. The happy point is probably the classic 'T' advice - lots of broad experience with different languages, paradigms, etc., with enough deep, deep experience in one or two to be incredible at reasoning and execution.

[0] Could only find this gist - https://gist.github.com/stijlist/bb932fb93e22fe6260b2

I find it somewhat hard professionally to get a role doing other stuff - I have brought up to multiple companies I have been at that I would like to do server-side work and work with other domains. Almost none of them initially take my wishes seriously, simply because they would likely have to hire 5+ developers to replace my expertise & productivity with Angular when I am on a roll (or maybe 2+ normal senior engineers).

Other companies aren't comfortable enough to allow me to do backend work when I apply, even if I have had non-professional experience working with [insert tech], or they would likely come with a drastic pay cut - I believe it is because I have become uncannily good at what I do on the frontend. Instead, I have focused more on moving up the ladder with other skills since I recognize that being a one trick pony sucks - I have leveraged my expertise to become a senior/lead engineer, that way I am shielded from that problem somewhat. A part of me does wish that I would be able to get more experience using other languages, technology, and domains within web development, because I like writing code & solving problems. This is a hard problem to me, and I have been taking the time to think about how to approach this in the back of my head.

If you are as valuable to your employer as you seem to imply, it should be easy to negotiate this with a simple "I'm burnt out doing X. Unless you let me start doing Y, I will have to join another company to fulfill my goals." Unless you work for people who consider their employees short-term expendable resources, this should be a no-brainer for them.

That has been the only way I have been able to get other experience in my full-time jobs. I am unhappy that it has been the only way I have been able to get the employer to actually move to allow me to work in other domains.

Subtlety will only get you so far in negotiations, especially when you're already a 'captive' employee.

Another possible vector to this discussion is that everyone here are OTP's, as to the vast majority of the population, we make computers work and build stuff that other people can't or don't want to build.

Now I think we should all keep our eyes out for new tools that make our OTP lives easier and more productive, but learning new stuff just for the sake of learning...sure, maybe, IF you don't have any other interests outside of your technical life.

For example, I play guitar and compose electronic music...there are simply no where near enough hours in a day to not only work a paying job to finance my lifestyle, but to practice and produce music.

Something has to give.

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 languages could become obsolete without the other one also becoming obsolete, unless their development stopped for some reason.

Why bother learning another language that is almost the same, like PHP and Ruby?

Well, OP did say you should learn a "technology as far removed as the one that you are currently using as you can stomach." Some people can only stomach so much.

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".

And then the job req might demand a "master" or "expert" or a "rockstar", but the responsibilities read like a remedial first semester intro to programming class, and you'll ace the interview if you're not nervous about fizzbuzz. And lacking skilled lower level technical management, your personal success metric will be LOC, so rework makes you look more productive not less. A noob will do just fine on the job.

Sure but I think I'd rather have a developer with 10 years of experience working on a new language with me, rather than someone with a couple of years experience in that language and nothing else.

It didn't take me long to go from Perl to Python (though they are very similar languages aside from Syntax). I knew how to do something in Perl, I would just google for the Python equivalent.

As someone who has mastered Symfony2, learning Ruby on Rails was a walk in the park. There weren't any new concepts to learn, just syntax.

In my experience those concepts are not language-specific. More like platform (eg: web) or paradigm (OOP) specific.

...if you think that PHP and Ruby are "almost the same", you are probably one of the one-trick ponies.

Am I? See my other reply. And now I think you are the one trick pony, who thinks switching languages from the same paradigm is a challenge.

"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 change. So yes lifetime careers do exist. Its only the requirements/tools that evolve overtime.

It's a good thing I mastered Frontpage. Please pm me with your 200/hr gigs.

> In the world of programming being a one-trick-pony is not an option

> 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.

Ha! I know plenty of SAP people who are making $200+/hr because they are one-trick ponies. So the real question is - who's anecdote is stronger, mine or jacques's?

And plenty of people still make a nice living with Fortran.

The "one" trick is apparently finding the right pony...

I had the opportunity to take a field trip to a water treatment plant that was just outside my town. I think I was in 6th grade. While there, we saw these giant tanks, inside them was this disgusting water filled with literal shit, and on occasion, condoms. The problem with the condoms was that the system they used to filter the water wasn't capable of dealing with them. So they had a guy setup, in a small fishing boat, and a net. His job was to float around fishing them out. For this he was paid $100/hr (according to the guide I believe). It wasn't a particularly difficult job. But it was literally a shit job.

In the world of business, SAP consultants are the equivalent.

I believe there is something missing from this article. To me it's not only about specific skills which the author ties directly to particular tools and languages, but at least as much about ideology and methodology.

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!

This also depends on where you are in your career. I would not call myself a One Trick Pony, but I am specialized enough in legacy systems that I face the same danger.

However, I can play this to my advantage -- as more and more of my colleagues have moved on to greener pastures, I have specialized in modernizing these old system to Web-based UIs, as well as doing consulting projects to migrate the applications to new platforms or simply shut down the old systems. As time goes on, the rates for these projects are increasing. I am also old enough to have a nest egg built up, while leading a simple life with a smaller monthly "burn rate" in my personal life than most other people I know.

For me, I can ride this tech until it dies. It will be the end of my tech career. But then comes a semi-retirement where I can get by with the residual income I get from a couple of my side projects and my little hobby farm.

So the real lesson is that being a one trick pony can be a terrible thing... or you can be aware of your situation, and be prepared for it. If I had no nest egg, no residual income, and no plan to change my lifestyle when the meteor hits, I'd be in trouble. Instead, I'm actually kind of looking forward to it.

I have to disagree.

As a unemployed person, that see lots of job openings for one trick ponies, I wish I was a one trick pony, I am not, and I am already without my lunch (in the literal sense, I've been eating mostly potatoes for the last weeks, my parents don't have money to buy even chicken daily).

I am mainly a Lua, C and C++ coder.

Most job openings I see are for Java EE specialists, or people that know the entire database stack (ie: Oracle + some server side coding tech)

Or it is for .NET specialists, and so on.

I am willing to work with that stuff, but people want to hire only extremely experienced people in those fields, my years of coding C# for fun to makes games with XNA and RunUO does not count, I don't have a huge stack of Java certifications, and so on.

But the people I know that are coding Java since its existance, and don't know anything else (example, cannot grasp pointers or some other basic concepts that are not used directly in Java) have a job.

I wish I went with that boring route instead... (I know lots of random languages, Lua, C and C++ are my favourite, but I know C#, J2ME, BASIC, MushCODE, Linoleum, PHP, and some others, all because I am curious and learn for the sake of learning).

Seriously are there no job openings for C/C++ programmers ?

Things like games(or game engines), trading, embedded systems, operating systems should still be running mostly on that...

I make games personally, but I am in Brazil, the jobs available for C and C++ programmers are all NOT on Brazil, and those that I am actually experienced in (games) rarely get relocation help, I DO apply to those jobs, but I always get reply that it is for people that live already near them.

As for trading, there are few brazillian traders, and I don't found a opening in them yet, there are lots of traders in US, but I have zero experience, they won't pay relocation.

The same is also true for operating systems, embedded, etc...

Everyone likes C and C++ coders, but only when those are secondary skills (ie: I see lots of openings where Java + Oracle are mandatory skills, and C++ is a "plus", I apply to those anyway, but never got an interview)

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.

Then don't look for a welding job. If you are in the top of the brick-laying field, there will be plenty of consultancy for these new brick-laying machine jobs or with the company that programs the brick-laying strategies.

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.

Someone has to teach the drone developers optimal brick laying techniques so they can program the drones. Every building site will no doubt need a handful of people to oversee the drones and verify their work. Also there will probably be several intricate nuances to complicated brick laying problems that will still require manual intervention. I wouldn't be surprised if at the end of the day a master bricklayer won't be able to use those drones far more efficiently and creatively than even the best drone programmer who has never actually held a trowel.

So, basically, always be looking for emerging opportunities and don't be quick to "throw in the trowel" ;-) Sorry... just couldn't resist!

The actual phrase is:

   A jack of all trades
   Master of none
   Is still better
   Than a master of one

Worth keeping in mind when looking for a metaphor.

I think people ignore the second part, because it is a lie. (see my post here commenting about my situation)

That latter two parts seem to have been added later. The original uses only included the first, and then the second parts.

http://www.phrases.org.uk/meanings/jack-of-all-trades.html

This can be an issue if you aren't able to pick up new skill sets quickly. As another poster said languages and frameworks are tools. While you can't be a master at a new language in a week you can certainly become functional in it. I always look to hire people with general aptitude for technology not just in one language even if they only work in that one language. There are always going to be people who learned one language or framework and they cannot apply that to any new endeavor, like wise there are folks who pick up new things easily. Conceptually everything we do falls into a few categories and as long as you know whats possible then determining the way you do X with that tool is the only challenge.

It seems a lot of the commenters are looking at this like a black-and-white issue... Either you're a generalist or a specialist who does nothing else.

I think the best place to be in is right in the middle: the "T" engineer (or "T" marketer, "T" designer, etc). It means you have deep knowledge of one vertical, and a shallow knowledge of many related verticles. (Get it? It's a T shape.)

This type of person is damn good at solving anything within their vertical (and gets paid accordingly), but knows enough about related fields that they're not blinded by their own expertise.

As a technical marketer who also knows some code, some design, some B2B sales, etc, I've found those "shallow" skills to be tremendously valuable. Not because I can promise clients to debug their app (I don't), but because I can communicate with the development team, the design team, the inbound marketing team, ... without hitting a language barrier.

So don't be a one-trick pony and don't be a jack-of-all-trades. Be a T.

I don't think C++ would become obsolete any time soon, right?

Please do not taunt the Rust fans.

I can tell you that Rust fans have a healthy respect for C++. There's nothing like trying to compete with C++ that makes you appreciate just how good it is at its domain (even if it does basically punt on safety (turns out it's a Hard Problem))!

Trust me, if Mozilla were merely trying to exploit the depressing SV hype cycle, they'd have built a pretty-looking dynamic language rather than anything with semicolons. :P

Not a chance. It's possible that the rate of new projects written in C++ could decline as other languages attempt to eat its lunch (disclaimer: I'm a big Rust fan, and this is exactly what we're trying to do), but C++ is a titanic industry juggernaut. Code doesn't just go away, and even bad code only needs to work "well enough" in order to make it virtually impossible to muster the political will to mount a rewrite.

People who grok C++ will be able to manage whatever would ever replace it.

Exactly. The Rust team is trying to give C/C++ devs a better, safer, and at least equally performant tool to use. They're not trying to replace one group of people (C/C++ devs) with a different group of people (Rust devs).

The fact that it's also attracting the interests of Ruby and Python devs (who may have found C/C++ scary) is a bonus.

The huge C++ codebases won't vanish even if Rust becomes the most popular programming language.

Good C and C++ programmers understand how computers work. We will always need programmers who understand how computers work.

I believe a cleaner language will replace C and C++ for new projects some day, but it will still present the same fundamental environment to the programmer: manual memory management, raw OS threading, ability to bit bash and do unsafe stuff if you need to. This language will not radically change the C/C++ programming model. Rather, it will add semantic power to reason about safeness, purity, concurrency, memory layout, etc. as part of the language. (I think Rust might be this language.)

IMO, active C/C++ programmers should be learning more about stuff like OOO and superscalar CPU architectures, caches, NUMA, hardware atomic operations, drivers, etc. I think "C/C++ programmer" really means "close to the metal programmer working on a mainstream project," and that category will remain strong through language changes. On the other hand, if you have never found the need to learn anything from that list of topics, you are probably using C/C++ in a domain where it is ripe for replacement.

I believe a cleaner language will replace C and C++ for new projects some day

That language is C++14.

People always say C will replace C

I would liked to take a moment and laugh at the advice to leave a 10+ year old language in favor of... Another few 10 year old languages.

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.

Certain languages require you to learn more paradigms; it's hard to write a object-oriented program in pure Prolog.

And I don't see what the age has to do with it; most paradigms are hardly new.

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.

I agree, but it's hard to solve the "drive a screw" problem if you've never seen a screw driver or even know they exist.

> My real value is being able to solve a problem in a timely manner.

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.

I think its right not to be a one-trick pony, who isn't continuously learning.

But, being an expert is where its at. Companies will pay a premium for an expert over an enthusiastic amateur, because its less risky.

The most important thing is that learning other languages and frameworks really helps expand your perspective. It's fascinating and fun to learn how another framework in a different language solves common problems like security, routing, or UI abstractions.

Any time you see a problem approached from a new angle, it deepens your understanding of that domain. You learn what patterns are common and what tradeoffs are made.

I gueninely believe learning Python or Erlang makes you a better Ruby programmer. You don't have to cross over to reap the benefits.

I'm not so sure. I think the biggest mistake programmers make is learning the same thing over and over again. It's much easier to find someone that can implement a basic server in ten different languages than someone who now the many different aspects of a desktop application. It's like everyone is a mediocre butcher that also does fish and vegetables, but you can't find any chefs. Probably myself included.

Watch - in a near future there'll pop up an article explaining how you can't afford to study a little of this and a little of that. It will tell you need to focus on one thing only to be real good at it so that you can sell that one skill.

I think this also applies to people in general and not just programmers - the playing field is leveled and all the information is available. Ppl should improve their knowledge sideways and not just in one vertical.

This is off topic, but why is everyone using that same blog theme? It's taken me weeks to notice that all those articles were not,in fact, written by the same person.

I still get payed 100$/h to do HTML ;)

anyone who agrees with this article - what has zuckerberg ever done other than facebook?

My "One Trick" is reasoning. I think I'm safe.

Disclaimer: One Trick Pony.

My 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.

Delivering results like they are going out of style. Crush'a challenge.

Not to disagree with your points, and I don't know if my upvote helps, but you got a bunch of lucky breaks that a significant slice of HN didn't get, which could explain the downvotes.

Consider that some are incapable of sensing the customer, much less their requirements, whatever they are.

And consider that some are trapped mooning certain tools over others.

I'm reminded of Cory Booker's "Conspiracy of Love". Cory's dad

was born to a single mother who could not take care of him. He then was raised by his grandparents, like many children in my community, but then his grandma could not take care of him.

And then he was out in the community but it was that conspiracy of love –people whose names I do not know in a small, segregated, North Carolina town – that rallied around this boy, would not let him fail, got him to school, put a roof over his head, put food on the table, taught him discipline and respect, and he made his way.

HN is that conspiracy of love for many lurkers.

Reply on news.ycombinator.com