3 ms·
It takes about two years to become deeply proficient in any language/framework. Up until then you'll get faster, look stuff up less, and churn out code faster.
by ojbyrne 18y ago
It takes about two years to become deeply proficient in any language/framework. Up until then you'll get faster, look stuff up less, and churn out code faster.
Unrelated to that is the domain-specific knowledge, which has a different effect - you don't get faster, you learn what code to write, and more importantly, what code not to write. In the long run, it probably has more effect on productivity than being comfortable with a language. How long this takes really depends on the domain.
My experience with 10x programmers (I don't count myself in that group) is that it's the second area where the big productivity gains lie.
- nostrademons 18y agoSomething that Google's first employee said recently stuck with me: "I would say the single most important thing an engineer can do to be effective is to pick the right problem to work on." Alas, he had no idea how to do that (or rather, he obviously had a very good idea how to do it, but was unable to put it into words), but the quote resonates a lot with my experience. I've wasted so much time on projects that in retrospect weren't really all that important - I coded them quickly, and learned quite a bit that came in handy later, but the problems themselves were basically non-problems.
- ojbyrne 18y agoMy stats prof used to take about "Type 3 errors." Type 1 and 2 errors are part of a basic stats course. Type 3 = "solving the wrong problem."
- SapphireSun 18y agoMy understanding of type III was that it was "Right for the wrong reasons." I suppose it might not be a standard term ;-)
- spc476 18y agoWhat ojbyrne said. Also, something that takes quite a bit of time to learn is when to give up on a library/framework and just reinvent the wheel (which I recently did---nftw() did everything I needed, except I couldn't get it to not follow symlinks; I found it easier to roll my own version).