10 ms·

I think one word would shed light on such anecdotes: deliberate practice. Countless literature and researches have pointed out that simply doing more would not

I think one word would shed light on such anecdotes: deliberate practice. Countless literature and researches have pointed out that simply doing more would not bring much improvement but find out what is missing and practice it to perfection then move to another weaknesses is the best way to achieve top performance, be it in sport, in music or other fields. Like someone who want to learn chess; simply plays a lot each and every day will improve his ELO slowly but it will stall after a while (say at the level of a club player) and he can almost certainly never attain the mastery. In opposite, someone who seeks guidance, study and practice to fix his weaknesses and perfect his technique will improve vastly more in the same amount of time. Effective practice and coaching is also the only difference between merely very good players and grand masters. I can’t imagine why it should be different in the field of programming and software engineering. Someone who writes thousands sloppy games might have learned how to do them faster (and maybe better) but he still learned nothing more about complex systems or secure systems. Only with intense study and practice he can master such stuffs effectively. The Talent Code of Coyle is a good book to start reading about deliberate practice.

tekkk 8y ago
Yes, exactly this. If you never really think about your coding seriously, and ponder where you should get better at and then do it - you'll never improve! Simply by acknowledging your own mistakes and how you could fix them in the future, let's you build up skill much better than just churning out code day in day out without giving it a second thought. I've seen the both extremes, the programmers who are so serious about the style of the code that nothing really satisfies them (and consequently progress happens at snail's pace). Then I've seen those, who'll write the ugliest of hacks just to get the thing working and move on. I think there's a deliberate balance between the two, where you feel you're not wasting time on useless things but actually get something done, which you can then comfortably show to your peers without beginning to blush. And only way of getting there is practise and being mindful of what you are doing. Similar to sports, music - whatever. To know where and how you did wrong is key, often you'll need a very good teacher to show you that. Criticizing yourself works too, but often you either become too strict to yourself or too lenient. Just starting to code without worrying if this is the "best practise" or not will allow you get into a flow which is much better than over-thinking your approach. Because once you start to do it, like a good warm-up it allows you to see the problem much clearer as you become aware of the problems as you encounter them. Then if you have time, you might want to refactor your solution or just move on the next most important thing. Sometimes it's better to just write awful code to get to that MVP or other important milestone, only after which you start to review your code. Experience will tell you, when is the right time to move fast and when it's good to slow down and enforce a particular paradigm to your codebase. From purely
tekkk 8y ago
Yes, exactly this. If you never really think about your coding seriously, and ponder where you should get better at and then do it - you'll never improve! Simply by acknowledging your own mistakes and how you could fix them in the future, let's you build up skill much better than just churning out code day in day out without giving it a second thought. I've seen the both extremes, the programmers who are so serious about the style of the code that nothing really satisfies them (and consequently progress happens at snail's pace). Then I've seen those, who'll write the ugliest of hacks just to get the thing working and move on. I think there's a deliberate balance between the two, where you feel you're not wasting time on useless things but actually get something done, which you can then comfortably show to your peers without beginning to blush. And only way of getting there is practise and being mindful of what you are doing. Similar to sports, music - whatever. To know where and how you did wrong is key, often you'll need a very good teacher to show you that. Criticizing yourself works too, but often you either become too strict to yourself or too lenient. Just starting to code without worrying if this is the "best practise" or not will allow you get into a flow which is much better than over-thinking your approach. Because once you start to do it, like a good warm-up it allows you to see the problem much clearer as you become aware of the problems as you encounter them. Then if you have time, you might want to refactor your solution or just move on the next most important thing. Sometimes it's better to just write awful code to get to that MVP or other important milestone, only after which you start to review your code. Experience will tell you, when is the right time to move fast and when it's good to slow down and enforce a particular paradigm to your codebase.
otras 8y ago
On that note, what do you think deliberate practice looks like for programming and software engineering?

tekkk 8y ago

Yes, exactly this. If you never really think about your coding seriously, and ponder where you should get better at and then do it - you'll never improve! Simply by acknowledging your own mistakes and how you could fix them in the future, let's you build up skill much better than just churning out code day in day out without giving it a second thought. I've seen the both extremes, the programmers who are so serious about the style of the code that nothing really satisfies them (and consequently progress happens at snail's pace). Then I've seen those, who'll write the ugliest of hacks just to get the thing working and move on. I think there's a deliberate balance between the two, where you feel you're not wasting time on useless things but actually get something done, which you can then comfortably show to your peers without beginning to blush. And only way of getting there is practise and being mindful of what you are doing. Similar to sports, music - whatever. To know where and how you did wrong is key, often you'll need a very good teacher to show you that. Criticizing yourself works too, but often you either become too strict to yourself or too lenient. Just starting to code without worrying if this is the "best practise" or not will allow you get into a flow which is much better than over-thinking your approach. Because once you start to do it, like a good warm-up it allows you to see the problem much clearer as you become aware of the problems as you encounter them. Then if you have time, you might want to refactor your solution or just move on the next most important thing. Sometimes it's better to just write awful code to get to that MVP or other important milestone, only after which you start to review your code. Experience will tell you, when is the right time to move fast and when it's good to slow down and enforce a particular paradigm to your codebase. From purely

tekkk 8y ago

otras 8y ago

On that note, what do you think deliberate practice looks like for programming and software engineering?