This is best way to become a better developer. Even if you don't exactly know what to do to complete the project you must take it so long as it is possible for you to learn how. The acquisition of new knowledge to solve increasingly difficult problems is the essence of development.
The flip side of this is that a problem can haunt you such that you aren't willing to let it go. This is great when the problem aligns with your goals, but can be destructive in other cases.
"Don’t ask for help from others on how to solve a problem. Solve it yourself first then ask for opinions on your solution."
If this means don't constantly pester the programmer in the next cubicle, I agree.
If this means re-invent the wheel instead of searching for how the problem may have been solved in the past, I strongly disagree.
In my experience, the "best" programmers are the ones most adept at searching for an existing solution. This appears to help them solve typical problems faster, and all the approaches they're exposed to while searching make them personally able to more quickly solve a broader array of problems than those who beat their heads against the wall till the wall bleeds a solution.
Nice article, but it is possible to explain this as forming a habit. The 10,000 hour concept was popularized by Malcolm Gladwell who based it on a research on students learning violin. http://www.google.com/search?aq=0&oq=malcolm+gladwell+10...
Someone who is trying to learn how to play a violin is really trying to form a habit. Once playing a violin becomes a strong habit, as strong as walking, so that it is done without thinking, it is said that the student has become a virtuoso.
But becoming a virtuoso does not guarantee a career as a concert violonist because there are a limit number of slots available in the world for concert violinists.
At some point one must consider quitting for strategic reasons. There is nothing wrong about quitting in this sense. In other words, once you realize that you were not chosen for the top spot you must quit or accept the consequences.
6 comments
[ 6.8 ms ] story [ 28.4 ms ] threadOn the other hand: knowing that giving up in mid-flight has it own set of consequences will often lead to not starting at all
aka 'Go Directly To Jail, Do Not Pass Go' ;-)
This is best way to become a better developer. Even if you don't exactly know what to do to complete the project you must take it so long as it is possible for you to learn how. The acquisition of new knowledge to solve increasingly difficult problems is the essence of development.
If this means don't constantly pester the programmer in the next cubicle, I agree.
If this means re-invent the wheel instead of searching for how the problem may have been solved in the past, I strongly disagree.
In my experience, the "best" programmers are the ones most adept at searching for an existing solution. This appears to help them solve typical problems faster, and all the approaches they're exposed to while searching make them personally able to more quickly solve a broader array of problems than those who beat their heads against the wall till the wall bleeds a solution.
Someone who is trying to learn how to play a violin is really trying to form a habit. Once playing a violin becomes a strong habit, as strong as walking, so that it is done without thinking, it is said that the student has become a virtuoso.
But becoming a virtuoso does not guarantee a career as a concert violonist because there are a limit number of slots available in the world for concert violinists.
At some point one must consider quitting for strategic reasons. There is nothing wrong about quitting in this sense. In other words, once you realize that you were not chosen for the top spot you must quit or accept the consequences.