3 ms·

I think it depends on how much time they spend programming and what they program. 1. There's a difference between 3 years of experience 4 hours a day 5 days a

I think it depends on how much time they spend programming and what they program. 1. There's a difference between 3 years of experience 4 hours a day 5 days a week and 9 hours a day 7 days a week. That's 20 hours vs 63 hours per week. Furthermore, the 63-hours-per-week person has all of that experience in the last 3 year context. A 20 hours-per-week person would take 9 years to get the same amount of experience in terms of time. Technology changes much more in 9 years than 3. Now, 9 hours of actual programming per day is very unrealistic. It's also the case that the 9 year person has much more varied experience due to technology changing, so they end up with different skills. 2. If you work on one project/system then after a while what you often deal with is specific to that system. It might not translate well to general programming or other tasks. I've done programming for at least 9 years, but most of it has been on and off. I would certainly consider somebody with 5 years experience to be better than me in most circumstances.

photonios 8y ago
I agree with this. I know quite a few people who not only write code for work, but they spend massive amounts of their spare time building things or contributing to open source projects. Although it's not guaranteed, it's likely these kind of people are significantly better than their peers.
jodrellblank 8y ago
This is about swimmers: https://fermatslibrary.com/s/the-mundanity-of-excellence-an-ethnographic-report-on-stratification-and-olympic-swimmers https://fermatslibrary.com/s/the-mundanity-of-excellence-an-... but it's a counter to the popular idea that "more work" is what it takes to become better at something. Two people in the same group will find that the one who tries more will get better results, but training for more time won't get them to a better group. Instead, qualitative changes are needed - probably many of them - people to work with, ways to think about work, habits of work, adopting the styles of those who are better, etc. What if it applies to programming also?
- Mirioron 8y ago
  I think it does apply to programming, but quantitative increases in programming also come from the adoption of new tools, programming paradigms, programming languages etc.
  - jodrellblank 8y ago
    I think you're using "quantitative increase" to mean "measurable improvement in output", but in the article sense it means simply "more quantity of practise" without changing the kind of practice. Quantitative would be "I write more lines of code", "I solve more challenge problems", "I write and release more programs", "I code for more minutes each day, more days each week, more weeks in a year", "I suffer and endure more". This might get you further up in your friend group or class ranking, but won't take you to a new level (so claimed). Quantitative changes would be things you suggest, like "I use different tools", "I approach problem solving in a new way", "I lean towards hard problems instead of retrying easy things", "I work with different people to learn new ideas", "I use languages which let me do more with less code", etc. (so claimed) those can take you to better output, even if your quantity of practice overall decreases. We always say "practice makes perfect", but "do what winning people do" seems better advice than "do more of what you are doing, when you aren't winning". Phrased like that it's almost tautological - training longer with bad form, won't give you good form.

photonios 8y ago

I agree with this. I know quite a few people who not only write code for work, but they spend massive amounts of their spare time building things or contributing to open source projects. Although it's not guaranteed, it's likely these kind of people are significantly better than their peers.

jodrellblank 8y ago

This is about swimmers: https://fermatslibrary.com/s/the-mundanity-of-excellence-an-ethnographic-report-on-stratification-and-olympic-swimmers https://fermatslibrary.com/s/the-mundanity-of-excellence-an-... but it's a counter to the popular idea that "more work" is what it takes to become better at something. Two people in the same group will find that the one who tries more will get better results, but training for more time won't get them to a better group. Instead, qualitative changes are needed - probably many of them - people to work with, ways to think about work, habits of work, adopting the styles of those who are better, etc. What if it applies to programming also?

Mirioron 8y ago
I think it does apply to programming, but quantitative increases in programming also come from the adoption of new tools, programming paradigms, programming languages etc.
- jodrellblank 8y ago
  I think you're using "quantitative increase" to mean "measurable improvement in output", but in the article sense it means simply "more quantity of practise" without changing the kind of practice. Quantitative would be "I write more lines of code", "I solve more challenge problems", "I write and release more programs", "I code for more minutes each day, more days each week, more weeks in a year", "I suffer and endure more". This might get you further up in your friend group or class ranking, but won't take you to a new level (so claimed). Quantitative changes would be things you suggest, like "I use different tools", "I approach problem solving in a new way", "I lean towards hard problems instead of retrying easy things", "I work with different people to learn new ideas", "I use languages which let me do more with less code", etc. (so claimed) those can take you to better output, even if your quantity of practice overall decreases. We always say "practice makes perfect", but "do what winning people do" seems better advice than "do more of what you are doing, when you aren't winning". Phrased like that it's almost tautological - training longer with bad form, won't give you good form.