> In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.

A couple of things:

- A good programmer won't just write C++ in the style of Basic.

- A good programmer wouldn't just use C++ to accomplish a task, there must be a legitimate reason, performance, etc.

I myself have done exactly this, I just wrote a Ruby C-extension to make my program faster and I definitely didn't write it in the style of Ruby.

If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination.

In two ten year sprints you will be due for retirement.

Where I am sitting, you absolutely have 10 years (or more) to give toward a specific cause, and the path of the software developer is one of lifelong improvement.

Stuff like "the rate at which tools are changing" doesn't matter too much, because that stuff is just surface-level knowledge, not deep knowledge.

I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.

All of the Web dev I've been involved in is pretty straight forward stuff to manage records in a database or make it easier to interact with the records on a browser.

The only thing remotely complex was 3d rendering. Perhaps I have a narrow view of what is considered web dev now.

I didn't mean to say that. Everybody has individual choices, and I respect yours.

And not all of us would like to code when we are 50+. Personally I would like to retire early to take time off for other things. This is entirely a personal perspective, and might change from person to person.

if so, cheers to you! keep up the good work. if not, same sentiment regardless.

No, no thanks. I work in the medical device industry, but this applied everywhere. If you don't understood your tools at a deep level please, study. Go off and write some trivial stuff before you infect important systems with your ignorance.

If that's indeed a trend, then this industry is moving towards a pretty bad place.

Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.

Young people are ready to work lower salaries, will do work on weekends, late nights and in general a lot more agile in a lot of issues.

In fact the 10000 hour/10 year rule itself is subject to a lot of assumptions like access to information being expensive in terms of time and effort, so having someone on the team with that information would help. These days you have stack overflow and a dozen places on the internet who can much of that at a far more lesser price.

Its getting easier over time to build systems and solve problems.

Unless you're doing the literal bottom-barrel of engineering work where you don't involve algorithmic know-how, there's no escaping having deep engineering.

Perhaps what offends me most is the notion that "you can just google/stackoverflow it". No you can't. If you don't know your tools, every problem will be a nail and your only tool a hammer. You're not being fast, you're being hasty and creating a lot of waste by moving very slow on the aggregate. It's this attitude that introduces massive bugs in the system because an engineer copy/pasted code without knowing it's implications.

Development is knowledge working; you need to invest in your knowledge tools else you're just moving really slow and you don't even know it.

Having a lot of unstructured information in your brain has no value.

If you learn a lot, and then start putting patterns together and build more complex rules out of that - that has value. And by the way, the result of that process is the kind of thing that could be easily transferred to other particular areas.

Looking things up won't do you any good if you don't understand what you find, and you're going to waste time flailing around if you're unable to recognize the class of problem you have (which is what algorithms are for -- they're solutions for classes of problems).

Also, people without understanding of CS fundamentals often unwittingly write dog-slow code.

If you think of it as inert info, the accessing of which in the brain is equivalent to reading it on a web site...

But it isn't. Brains, especially in respect to deeply understood domain knowledge, change in response to how they're used.

Experts' minds create shortcuts to information in their area of expertise.

Having more information means having the ability to synthesize it, gain epiphanies that would otherwise be overlooked--and reading someone's blog post about their epiphany isn't the same as having it yourself.

However, by being willing to train senior folks (and I'm talking my book here, as I am a senior developer), you gain two things: access to a larger pool of applicants, and the value of cross pollination. (I've seen a lot of ORMs in my time, and concepts translate between them.)

How to choose whether to train or not? It depends on the length of your runway (longer means you'll have more time, obviously), how many other current folks have knowledge of the solution (and can offer code review or other guidance), how committed the applicant is (tough to judge, but desiring employment vs wanting a contract is a proxy), how far you are pushing what you are building (if it is a normal use case--crud app for rails--a book and a few days may be enough training time. If it is not--high traffic erlang application--you may have a harder time training someone up without extensive partnering), and how hard it is to find someone who has experience with your current technology (there is an opportunity cost to training someone, but there is an opportunity cost to having an empty seat as well).

Certainly any senior developer worthy of the name is going to be able to pick up a language and be productive with it in a few weeks. However, they'll make mistakes, just like anyone will, that may require rewriting later.

Junior folks are a whole different ballgame.

Most of the concepts of application development will always apply, and context is everything.

On the flip side, I've met plenty of developers who have absolutely no desire to look at different languages, tools or ideas. To me, that's what is really scary. I can't imagine having that mindset and where I will be in a decade if I did. I just turned 40 a few months back, and feel like I am learning about as much as I did in my 20's. The difference being the objectivity on what to dive deeper into with regards to learning more.

The best developers I've ever met all have one thing in common. They've all written stuff outside of school and the workplace. Not that everyone keeps doing so, but they all have at least when starting out.

More here: http://henrikwarne.com/2014/12/15/programmer-knowledge/

Where this doesn't work as well is when you take a 'good developer' who's worked mostly in C++ writing game engines and throw them into web development using Clojure. It's hard to figure out the proper way to do something when your not even sure what your trying to do, or what terminology to use to efficiently google the question.

I think the author is primarily referencing the former situation, not the later.

Better to hire experts than polyglots if you want to make a concerto. Actually, it is better to design great software with the advice of great players then let them rock out while you stay out of their way.

This is more likely than you may think...

"I want to learn Ember.js, so even though I'm proficient at using Angular.js let's write everything in Ember.js instead. Then we can spend months chasing our tail learning all of the 'Gotchas' of Ember.js. Also, just to make things interesting, let's use a bleeding-edge version of Ember.js. Also let's do this at a time when articles on Ember.js that are just 4 months old are already out-dated and no longer apply to the current codebase."

Though I doubt that a warning on HN will deter such people.

But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about.

That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.

There are plenty of developers who chose to do just that, eg:

PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET).

WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang).

Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).

..why did you choose Erlang?

Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.

I'd say "You can pick up 90% of any language or planform in a few weeks." That last 10% though is some edge-case/deep understanding that you won't even know about until you really need it (and it's probably shown up in production).

All other things equal, for a startup, I'd rather hire a smart freshman over a middling candidate who had five years' experience with the language/framework I wrote my app in.

Plus, there are a number of startups where the speed at which you can "build stuff" is not the limiting reagent towards success. Even if you were the fastest builder in the world, if you don't build the right product, no one will pay you money, and you'll run out of runway. (Dozens of student "startups" out of the University of Waterloo run into this exact problem during every four month term.)

I think that's probably more useful in a start up. But I go more for the 'get shit working and see what happens' approach to developing. I mean, making it look pretty is what iterations are for.

maybe. or whatever.

Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>

If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...

Ruby/Python/PHP web CRUD, that kind of thing.

I think it's believable, as long as you have at least a few weeks to play around first. As long as designs are similar, it shouldn't be too hard to port.

Also, any number of "from X language to Y language" pages exist, and they should give you the most obvious caveats.

near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.

For example, I've been supporting old ASP.Net Web Forms projects for about a decade and I'm still getting stunned by that damned monstrosity.