This advice is good only for people who naturally dive deep into the details and get lost.<p>What he suggests is what I do as naturally as a fish in water. Skimming the details, finding my answer, and racing off is my greatest skill. But, lately, I have realized _my_ 10x gains come when I bite the bullet and deeply learn a technology. It is against my nature, and takes real effort, but that is where my biggest gains are.<p>If you read this article, snort, and say, "duh", try getting a book on a tech you use and reading it cover to cover a few times. Try programming without internet for a few hours. I've been doing this lately, and my normal cycle of hitting Google every ten seconds to remember (is it length, count, or size...) has slowed significantly, which keeps me in flow longer. I get pulled out of flow less and I have learned some really useful features of my stack that I previously would have never learned.
If you want to become a stupid code-hammering monkey then this is EXACTLY how you should proceed.<p>Procrastination, the good one, is actually the key to broaden your horizon and gain knowledge. It may slow down your work, but i would always prefer such colleagues over the kind described in the article.
Ummmmmm...ASBOLUTELY NO! Terrible advice that will stagnate your development as a developer. You need to learn faster and better ways of doing things ALL THE TIME. That is how you become a faster developer. But being a faster developer shouldn't be your concern, being a better developer should.<p>Based on this guys advice, why learn a framework. That will take time to learn. I can just hammer out the code on my own. Very short-term thinking.
This is not a tip. The author simply reported his natural learning curve. Naturally, you learn a lot at the beginning and later on you don't learn as much. The author went through this process and thought that because he didn't learn much "other things" at the end, he was doing the right thing, and he had made mistakes early on by not focusing only "the thing" he was supposed to learn.<p>No, he did not make mistakes by digressing into learning things that are related but might not be directly addressing his problems at hand.<p>Learning is complicated, as things that you learn help you in ways that you might not be even aware of.
The money quote:<p>> The key to being a good developer is to be able to find your answer as quickly as possible without learning anything else.<p>I originally parsed the title as "the one tip that will help you (learn to code) 10x faster", while this is obviously "the one tip that will help you learn to (code 10x faster)".<p>The advice is in fact the exact opposite of what you should do if you want to learn faster.
I find the "advice" in the post a bit confusing. Finding an answer on SO or a forum or a book will help you solve a specific problem (thus making you a "productive" coder). But I seriously doubt it will make you code faster in general if this "code snippet copy & paste coding" is not expanded into understanding so next time the search part is removed from the process.<p>In the early days, it always took me a lot more time to get from finding an answer to using that answer in my code. The main reason is that I didn't want to just copy paste something without understanding it. On the other hand, a more experienced colleague of mine was sifting through books and forums and pushing code a lot faster. I talked to him trying to understand what I'm doing wrong. As I've learned (actually both of us learned), the only difference was the existing knowledge each of us had about the environment and the app. Over time I got to be a lot faster at finding an answer and moving along, but that came only with becoming more familiar with the tools/lang/etc and being able to understand things faster.
Most common answer to any CS question in school is... "It depends".. And I think that applies here.<p>There are some situations where its better to have a good enough solution today rather than a perfect solution next week. And when you are in the earliest stages of product development, I apply this tip often (JFDI). But eventually there comes a time where your prototype has actually become a product, and too much hack & slash code begins to work against you rather than for you.<p>You have to make the judgement of where this tipping point is yourself, I am sure it is different for many developers.<p>Side note: I am currently refactoring a massive amount of my product's code because I am about to introduce some new and repetitive functionality. I don't mind hacky code, but to copy and paste it is down right sinful to me. So I guess I have reached my tipping point.
Hacking stuff together from stackoverflow might be faster initially, but later on the product will encounter severe quality issues. Learning the fundamentals and foundations of a technology, combined with experience and architecture knowledge will make a programmer 10x faster while still maintaining quality.
I think the real secret for coding better, is to know when to apply this advice (just looking for the answer you need without exploring anything else) and at other times maybe when you have more times, make some in-depth learning of broader technologies / API / languages / maths... areas that you've previously identified and tagged as potentially worth investigating. From my experience I can tell you this is the second component which make you a better developer in the long term. But the first component is also essential, it is the one that makes you start things and complete things without falling into endless procastrination and second guessing. So both short-term and long-term strategies are importants.
Another side of this is time estimates. If you have done the exact thing you are estimating, or something close to it, your estimate is only off by a factor of 2. If you are estimating something you've never done, the estimate is off by a factor of 10.<p>While I really hate the title of the article, I agree with the point wholeheartedly. It is much faster to deliver something where you know all the issues and have experience, than to try and research a new subject, making mistakes along the way.
<p><pre><code> The key to being a good developer is to be able to find your answer as quickly as possible without learning anything else.
</code></pre>
That might be the key to short-term productivity, but I think "good" is more complicated. I'd rather take a small hit to my average output than churn out lots of hacky code because I didn't bother to explore the options. Sometimes taking time to really learn something, even if it has dependencies, is an investment rather than a cost.
I actually find this tip really useful. This is why:<p>-If I read a programming book, I'm likely to remember a significant portion of what I read. That's because it fits into an overall structure. Even if I can't remember the exact name of a function that does exactly what I want, I know it exists and can find it easily.<p>-If I read a tip on an article and apply it regularly, I'll remember it, because it gets reinforced.<p>-If I read something in a blog post or article and don't apply it, I'll forget it almost immediately. Without the structure or repetition it just doesn't stick into my head.<p>The problem is that it's really easy to get caught in the last category. It feels like I'm learning a lot when I skip from link to link, but the reality is that most of it doesn't stick and ends up being wasted time. Separating out my learning and doing time works much better for me.
<i>"The key to being a good developer is to be able to find your answer as quickly as possible without learning anything else."</i><p>I 100% agree. That's why I often spend some extra time to sharpen my 'good solution for my problem' detection skills.<p>Even reputable sites such as Stack Overflow have plenty of bad answers, and that is even ignoring the fact that an answer may be good in general, but not for my situation.<p>Site quality also decays because software is changing/improving all the time. That answer to your question may have 700 upvotes, but if its solution has made meanwhile it into the standard library, it really helps if you know that.
Lots of good points. For me I know that I can get lost in the weeds. But I also should have stated that I believe you need to take the time to learn technologies and skills properly - and there's a time and a place for that. But if I'm trying to build a project I'm focusing on getting that project done. If I run into something that might be productive to spend more time on it later then I'll set aside time later. But otherwise there's just too much to learn and my project won't get built.
It depends the most on what kind of 'anything else' you avoid: ephemera or human capital. Getting better at telling them apart is one 'anything else' worth learning.
I try to factor in a decent amount of yak shaving time when I make estimates. Hitting deadlines is all well and good, but there's nothing like a good yak shave.
The article has a pretty good point. I might add that a potentially better way to improve your speed/effectiveness is to deliberately take time to regularly sharpen the saw. <a href="http://www.codinghorror.com/blog/2009/03/sharpening-the-saw.html" rel="nofollow">http://www.codinghorror.com/blog/2009/03/sharpening-the-saw....</a>
You don't become full stack by being shitty at lots of things quickly. You become full stack by going deep in many places, preferably quickly. This guy possesses some very short term thinking.
Sad but true. I learnt early and forget daily that you should seek to understand the problem by working back from any solution you can find. There's so much to not understand!