I read somewhere that it takes 4 years of full time work for a person to become competent in his field. I was chatting with Ian a bit ago, and he echoed this - that he's at a stage where he's learned so much at Twitter that he feels like giving some of that back.

After two years of coding, although I feel like I've come a long way, I still don't feel like I'm near any sort of threshold of competency ("Ahh, I still have so much to learn!!").

Have you guys experienced crossing this threshold? And when does it happen/what causes it?

4 years? Paul Graham and DHH both say 6 months to a year:

37signals.com
paulgraham.com

"I would guess a smart person can learn to hack sufficiently well in 6 months to a year."

There's a difference between "sufficiently well" and the level of proficiency I'm referring to. I mean well enough where you don't have the "I have so much to learn" feeling and, instead, feel like giving back to the community. Or is it a gradual evolution?

I think the saying is that it takes 10,000 hours to become "proficient" at something. This comes from Gladwells book "Outliers." To defend my quote though, I think you are mixing up a couple of things. When working at a place like Twitter basically every 6 months is an entirely new world. You are dealing with way more users on way more machines often with a completely different/improved technology stack. In my 3 years we went through 3 entirely different offices (and countless floors of those offices). This can get tiring after 3 years.

Regardless I think programming in at least 2 different types of languages is a worthwhile exercise. And I probably didn't stop seeing syntax until at least 2 years in.

Man, you guys have a really high standard for "competency".

Isn't this "threshold" really in the eye of the beholder? Our buddy Steve has been doing Javascript for what, a year? And now he's got one of the more popular Javascript libraries on Github? github.com

I think that the kind of skills you need to create useful software is not necessarily the same that you need to write awesome fast and well tuned code.

If you are talking about writing books on programming that make recommendations on how you should code, that's one thing. If you are just writing a library or covering a simple subject in a blog post, that's something different and I would say the threshold for the latter is much much lower.

There's also the question of domain knowledge: If you spend 6 months ont he same narrow subject, you might know more than the veteran coder who only has a small bit of knowledge on the subject.

I say: Blog everything you find yourself googling, you'll be surprised at which posts get attention.

My skill level seems to correlate with the amount of practice I've had with a particular implementation of some code. At a certain threshold of experience, I become a know-it-all.

But there's always something else to learn- and I'm starting to get the sense that there's always a bigger scale in which specific experience must be re-evaluated to fit a different mold.

I slightly derailed DHH on a semi-private mailing list and got him to give his opinion on this more specifically. Quoted text is me:

> "As an anecdote, I might consider myself a "beginner" (1.5 years programming) hired to rewrite code written by "experts" (4-5 people with maybe 5x the experience). It's a startup, and our feature velocity is perhaps 4-5 times faster than it was with the "expert" team of travelling consultants."

Beginner vs expert is not a matter of time. I've met many beginners with 10 years of experience under their belt. On the other hand, I released the first version of Rails less than one year after I started learning Ruby.

Some people can learn in six months what it takes others ten years to never get.

Thanks for sharing! (...Interesting!)

So perhaps time or hours is not a foolproof measurement of how proficiency. When saying 10,000 hours, I think Gladwell was assuming you aren't spinning your wheels most of the time. No doubt if you aren't taking initiative and pushing yourself outside your comfort zone, you aren't going to grow.

I'd love to probe DHH further on this. I don't think it takes extensive ruby (or language) experience to build something like Rails, it takes experience building web applications - seeing enough problems and fixing them.

"I think Gladwell was assuming you aren't spinning your wheels most of the time. No doubt if you aren't taking initiative and pushing yourself outside your comfort zone."

I think it's deeper than this. It's difficult to get feedback when learning how to build a web application - there's not an objective standard that says "you did this right". So, you get people who lived in some corporate basement writing procedural Java for 10 years calling themselves "experts" because no one understood what they were doing and could tell them "hey, this is bad.". Entire organizations can fall prey to this. Alternatively, too hard a focus on "best practices" leads to architecture astronauts that take 3 weeks to ship a feature because it isnt "clean".

Building software is entirely unlike, say, training for the 100 yard dash. When you're practicing for the 100 yard dash, you have a single, concrete metric for measuring your improvement. Imagine if a sprinter measured their progress like we do in software development, and the gold medal in the 100 yard dash was measured by which sprinter followed "best practices of sprinting" the most ;) (or, if he's a startup sprinter, how big his last round of funding was)

What I'm saying is that the lack of a feedback mechanism or yardstick (because, as we've discussed, *time* beyond 6-12 months is meaningless) means that crossing the proficiency threshold (much less measuring it!) is immensely more difficult.

At my previous (big) company, we had a 6 mo training rotation before you were given major pieces of functionality to implement yourself. This was effectively the average time we saw before (generally smart) new hires could build stuff.

After that, depending on how 'good' you were at the projects you completed, you were given more and more, or less and less complicated pieces to build.

An important aspect of learning to program to consider as well is catering to an engineers 'style' of learning; either self-taught or needing more direct structure. This affects time to competency immensely.

Also, in collegiate sailing we used to have a saying (mapping to your 4 years of undergrad). "Imitate, Imitate, Imitate, Innovate." This sort of applies here; when you are starting to innovate, that is the mark (for me anyway) that you are competent and should start teaching new hires.

This can happen super quickly or slowly depending on the person.

I'd like to highlight what @geoff said: "I think that the kind of skills you need to create useful software is not necessarily the same that you need to write awesome fast and well tuned code."

If you look at Steve and numbers.js, he may have only been writing javascript for a couple years, but he's a math major who has been doing math for >10,000 hours. He had other people help him with the js part (github.com).

I think that "people who lived in some corporate basement writing procedural Java for 10 years" are experts. They're just not experts at #shipping #mvps.

Being an expert at building web products is not the same as being able to ship a rails app. IMHO its about sensing the impacts of your decisions on the product.

"'Imitate, Imitate, Imitate, Innovate.' This sort of applies here; when you are starting to innovate, that is the mark (for me anyway) that you are competent and should start teaching new hires."

*Yes*! This is what I'm referring to.

dig that as well. I *definitely* remember feeling that switch turn on where I realized I was starting to "think for myself". Innovate might be a strong word...I think it's as subtle as reading some blog post and thinking "Actually, I don't agree with that for X, Y and Z reasons from my experience."

Since this post is about Stages of a Developer, do you think people ever get too experienced. To the point where they believe they know what is "best" and ignore potentially useful technologies because they are new (david.heinemeierhansson.com).

If so, how do you avoid that stage?

dat dhh link

02.images.fireden.net

Thank god someone else noticed