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.
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.
Don't let not knowing "simple solutions to simple problems" stop you from completing your next action (fixing the bug, finishing the sprint, launching the MVP, etc.).
Don't let not knowing the fundamentals better stop you from "leveling up", as it were, as a developer.
I've done this a couple times out of necessity (internet goes down, etc). It made me realize how useful a good IDE can be. Googling the API references is essentially a poor man's IntelliSense. Or, maybe, IntelliSense is a poor man's Google, depending on how you look at it.
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.
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.
No, he did not make mistakes by digressing into learning things that are related but might not be directly addressing his problems at hand.
Learning is complicated, as things that you learn help you in ways that you might not be even aware of.
> The key to being a good developer is to be able to find your answer as quickly as possible without learning anything else.
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)".
The advice is in fact the exact opposite of what you should do if you want to learn faster.
Certainly, having to search for an answer is inevitable. But it is also orders of magnitude more slow than recalling something from memory, at least for me. I think the key here is having the wisdom to know what is important enough to recall immediately versus referencing as needed.
As an analogy, and acknowledging the differences, being proficient with an editor isn't about the speed with which you look up how to do something: it's about what you can do without having to stop and think.
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.
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.
You have to make the judgement of where this tipping point is yourself, I am sure it is different for many developers.
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.
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.
The key to being a good developer is to be able to find your answer as quickly as possible without learning anything else.
-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.
-If I read a tip on an article and apply it regularly, I'll remember it, because it gets reinforced.
-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.
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 100% agree. That's why I often spend some extra time to sharpen my 'good solution for my problem' detection skills.
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.
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.
Do not fall into the error of the artisan who boasts of twenty years experience in his craft while in fact he has had only one year of experience — twenty times.