So how exactly is anyone supposed to gain new experience?

I don't mean to be combative, but so many job recs and interviews expect X years of Y. How do you get that time it? You learn it, right? I didn't used to know Python, but it was obviously useful for my job. So, I installed it and learned it. I was producing useful results for my company very rapidly. Sure, a few years later my skills are more well rounded and 'pythonic', but really, so what? This is how every. single. one. of. us. learns.

My job is only interesting to the extent I am learning new things. You are only going to hire drudges if you require the applicant already know everything needed for the job. How boring. Obviously I'm not arguing for hiring a janitor to rewrite Google's deep learning from scratch; some ability is required. But picking up basic skills in a new language? Easy peasy. Nothing to it. That's our job.

> So how exactly is anyone supposed to gain new experience?

By having commits on Github numbering in the middle five digits, of course! The only downside is eventually employers will move on to some other arbitrary bullshit metric, and you'll have to start over.

If you're good at picking things up in a hurry, the best way to gain experience in new skills is to get hired for your existing skill set, either at a very small company or (better yet) a large one with incompetent management.

In a small company, everyone wears a bunch of different hats and you will often be asked to do new things outside your official role.

In a large company with bad management, staff turnover will ensure that they regularly find themselves short on skills, at which point you can stick your hand up to pick up the slack.

Either way, if you consistently deliver the goods then they'll keep coming to you with new challenges.

>> "...(better yet) a large one with incompetent management."

Luckily this is >75% of large companies, IMHE.

> but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

Careful. You probably need to define your terms more clearly.

A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java.

Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience.

Yeah, I watched this play out in real time when I paired them. It was actually really enlightening and entertaining.

I also found out I didn't know as much about either Java or Erlang as I thought I did.

"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience."

Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.

Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.

> I've met many veterans that couldn't think outside the small specialty they had become locked into.

It's the difference between 10 years of experience, and 1 year of experience repeated 10 times

I too have found this assumption to not always be the case. At my company there are certainly some people who qualify as vets yet insist on writing purely procedural C style code and have yet to adopt modern paradigms like OO design simply because they are so far removed from their education.

To be fair, they might be on to something. I've programmed my whole life in OO and recently started looking into FP. I can see the veterans thinking that OO is a fad after seeing things like BeanFactoryFactoryFactory (I personally do not program in Java and have never encountered the use case for a "Factory", and as such do not know what the use case is). After that, what value do you get to adding the functions to structs? I personally see the value, but I also see the value in not doing that. I would recommend teaching them OO while yourself should study FP and criticisms of OO. After them, it may be easier to evaluate which is better for your use case. It sounds like the vets have already cornered you out of OO, but you also definitely don't want to force the wrong tool onto a project just because it's the tool you understand best.

This makes me think of that study[1] about doctors being away on conferences. I think it likely comes down to recognizing that experience rarely, if ever, trumps solid analytical thinking.

[1]http://archinte.jamanetwork.com/article.aspx?articleid=20389...

> A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java.

Perhaps. But I would take contention with a CS student claiming 4+ years "experience" with Java unless they were referring to something outside of class work.

When filling a position though, you're usually not comparing "was handed my degree yesterday" candidates with 20 year veterans. . . they're demanding much different compensation and degrees of responsibility.

A more apt comparison of my point would be a 20 year veteran of of Erlang who says "oh, yeah, I can pick Java up. Never seen it, but it'll just take me a couple of weeks." is not, in any way, going to produce the same quality code as a 20 year veteran of Java of relatively comparable experience and general skill.

Why didn't you just write this:

> A CS student is going to turn out very different programs from a 20 year veteran.

Because its so obvious no one cares.

Exactly my point. Adding additional information can't possibly make it less obvious.

That's far less true than you might assume.

I have seen a company pay someone 100$/hour to learn a new language as part of a 6 month contract. They were producing better code than the company's staff within 3 weeks and finished the project ahead of time.

Granted, he was an EE not a software developer. But, deep knowledge of a platform is often more dangerous than helpful. The surface layer tends to be the least buggy parts of most systems.

PS: I wish more people heard "Let's use reflection!" as "Let's use regular expressions!" for similar reasons. Yes, it can help, but you can also dig a ditch using grenades...

I hear "Let's use reflection!" as "It's time to find something else to work on!" Outside of writing developer tools or unit test frameworks, I can't think of a worse code smell. It's a klaxons blaring, we're doomed kinda thing.

Everytime I've seen it used, it turned into a quagmire of subtle regressions, strange effects at a distance and extremely brittle code.

I think the best pattern there are:

1. Thou shalt never write code that uses reflection on its own code base.

2. Thou shalt never use reflection unless all other options have been proven worse.

Which leaves mostly unit test frameworks for some reason...

I hear "Let's use reflection!" as "My language's tools for code reuse are hard to use and ineffective in practice, so I'm going to put annotations everywhere and use reflection instead! It'll be ten times harder to understand the code than it would have been with a little metaprogramming!"

But then, my opinion may be unduly influenced by Java vs Ruby.

Unfortunately you practically have to use reflection for certain things if you work in Go, although the language authors have tried to discourage it by making the APIs absolutely awful.

I don't disagree with the idea that becoming truly skilled in a language is more than a couple of weeks of work even for a great programmer, but more often than not you don't quite need that caliber of work from them right away.

Most job fills aren't going to be putting the new employee in charge of "greenfielding" the architecture of a brand new app, they'll be doing maintenance or build-out of an existing codebase, giving them plenty of time to ramp up on the fine details of a language while still being productive working with the existing code.

There's more to being a productive programmer than knowing the semantics of a language.

Someone who has been programming for a while but is learning a new language will have a ramp-up period when their code is ugly or unidiomatic, and they will take longer to write it, but it will capture the correct algorithms and abstractions. Compare that to someone who is inexperienced and writes a pile of exponential-time spaghetti that is slow and unmaintainable in any language.

Yes, and code reviews and other mature practices will get the person over that hump very quickly. Anyone can point you to the 'PEP8' of your language of choice.

> They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

From the opposite side of things, someone who's only been using the same tools for 5 years is probably going to struggle picking up new tools. For the projects I work on, it's rare to use the same languages and tools for every project. I'd rather have someone that understands how to write good code in general and knows multiple programming paradigms instead of someone claiming to be a guru in a single language.

If someone knows Java and JavaScript well for example, is it really going to take them more than a few weeks to be productive in Python (especially if you have someone on the team helping with picking the appropriate libraries to use)?

I think his point is more that someone who's been exposed to a language for years but isn't interested is going to pay off much less in the long run than someone who's using it for the first time but enjoys learning. The reason he mentioned a few weeks of training for the language meant that they would be able to start making changes within a few weeks and be making major contributions by a few months. The fact that their first month or so may be relatively unproductive is less of a concern if they're constantly getting better and better. That said, a few weeks of training plus exposure to a large codebase in a language should be enough for even the short term unless they're trying to learn a whole new paradigm or some huge frameworks/libraries.