An important part of my deliberate practice is using spaced repetition to memorize things. Whenever I encounter something new that I might need to know later, I add it to my deck of flashcards in Anki. This has been especially useful for learning less-used methods in a language or library, or for learning arcane bash commands. I find the more things I've memorized in this way, the faster I can code in generally because I'm not interrupting my flow with as may trips to Google for information. I don't think you can learn to code just by studying flashcards, but it has helped me a lot.
I think this quote might benefit from a little bit of context:
"Often, they're looking things basic things up and referencing them as often as newbies are, because they never took the time to really master their work."
In my experience, looking up basic things is not really a sign of lack of mastery, it seems to me, the the thing you gain with years of programming experience is a sense of "what to do" and not necessarily "what is the exact command in this language to do it".
There might also be something to be said around general mastery vs. specific mastery.
All this said, I am in complete agreement with the idea of "directed or correct practice". Practicing bad habits does not "make perfect" in any sense but being really good at doing the thing you were practicing badly.
Please know that I write this not to be critical of your article, rather I wanted to add some of my perspective.
Thanks for your thoughts!
I agree. But on interviews I get asked questions like what's the difference between let and var? And I'm like really? Or what does a for each loop do. As opposed to presenting me with a problem where using said loop is the best or most efficient way to do it. Programming of about problem solving, not knowing every language or framework. Because after you've used a few, you realize they all do the same things. Just some better than others. And no matter the framework or library, the underlying technology and protocols and the same.
So many incredible sentiments here. The quality vs quantity practice really resonates with us here.
A big reason for this is that we've noticed, particularly among Instagram #100daystocode crowd, that people feel bad if they've missed a day or two out of their journey.
And people are trying to pick up multiple frameworks at once because there's just so many tutorials to try your hand in. Some people can do this but for most it's a dirt path to burnout!
Thanks for this awesome post. We love what you're doing!
Thanks! I just gave y'all a shout out in the today's edition of my Life in Code newsletter, check it out! You can subscribe here, too.
At the same time, sometimes it's really nice just to do things for fun. Hack something together quickly in assembly for a microcontroller, decide to perform a task in a random language I know nothing about, abuse functional programming method chains, etc. I have honestly learned the most off some of those projects. One summer, I tried to reverse engineer a pager protocol off of patent applications. I knew nothing about DSP going into it, but it was a lot of fun learning it and realizing that sometimes the documentation is total BS!
Totally. Breaking things for fun is a blast. I work with folks who are on their path to their first dev jobs though, and meandering isn't really conducive to their goals, so I'm sharing all the hacks I had to create/learn (esp having a non-verbal learning disability... learning, let alone learning to code, was a real bitch) to help them avoid the pitfalls!
I can definitely see how discipline would be crucial! I have ADD and I really struggle to learn anything that doesn't immediately seem fun/interesting to me. Sometimes I can use it to my advantage and specialize in things most people don't care too much for, and sometimes I get to be very grateful that I have generally dealt with kind and patient supervisors when my time management skills fly right out the window.
Wow! This is one of the best articles I've read in a while. You're absolutely right. I suffered from non-deliberate studying for a long time. I understood the concepts and if I was asked to write a function or s for loop etc, I could. My issue was when I got my ide up and running, I'd go completely blank. If just stare at my screen until I gave up. I think my issue was also the fact that some of the languages it frameworks I was learning, I was learning because that's what the job market reflected at the time. Over time I've learned to think through what I'm trying to do. I know the best data structures to use for a given set of data. But all that can't with trail and error. I spent most of my early coding days just trying to remember what I'd learned because I would read books and code for a few weeks to a month then stop for three months. I also totally underestimated the value in reading documentation!! So I thank sites like FCC for making me read the docs. Because that was something I didn't like to do.
Thank you! :) I'm glad you found it helpful.
"Over time I've learned to think through what I'm trying to do"—this is a powerful statement. For literally the first 6 months I was learning, I never really truly stopped to map out my approach and determine what skills were in line with what I wanted to do with my career. Once I learned how to not only identify but then hone in and deliberately practice the appropriate skills, I was off to the races!
Great post! It's really important that we practice doing the right things the right way or else we are just strengthening bad habits!
Thanks Joe! :) And I totally agree.
how does a self--learner get feedback from a human?
Places like stack overflow, slack, gitter etc. Also I'm sure there are some nice ppl here that wouldn't mind taking s look at your code.
Slack channels and Gitter are definitely my top recs, besides just posting on the Twitters and asking politely if someone wouldn't mind taking a look at your code. Sometimes you need to sweeten the deal and offer something in exchange (like taking a look at theirs, or helping them find someone, if you're lower-level), since everyone's time is valuable—not just professionals or industry leaders.
But there are a TON of helpful people in this industry. Don't be afraid to ask, I promise you won't invite ridicule! And if you do get ridiculed, they suck and you're great because you have humility and willingness to learn. 😊
Thank you 😊😊
exercismio is good for this as well. You can complete exercises and get feedback from mentors on your solution I started it a few weeks ago.
Even Malcolm himself said that the whole fame of Outlier's "10,000 hours" rule comes from a misunderstanding.
I originally disliked that guy, but after listening to this episode of Freakonomics, I came to pity him a bit.
Yes! It's not about how much we try to learn, but making what we do learn - count!
I would add my personal book recommendation: "Pragmatic Thinking and Learning: Refactor your Wetware" by Andy Hunt.
Seconding this book! It's an excellent resource. :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.