Really interesting. I wonder how you could use a similar technique to improve your code? Things like code reviews would give you the necessary feedback, but I can't think of a rigorous way to make sure you'd always be on the limit of what you're capable of, pushing a little further with each project.
Most of the challenge in writing code is in understanding the problem you're trying to solve. Not the act of entering statements into editors.
Yes it's important to know the capabilites of your language and deployment stack -- but that just requires study, which in my mind is different from practice. I've never found that coding well required the sort of intense dedication that learning to play an instrument well, or play a sport well, requires.
> Yes it's important to know the capabilites of your language and deployment stack -- but that just requires study, which in my mind is different from practice.
I agree. Which is maybe why Stackoverflow solves so many problems for a developer. You know what you want to do, you know how you want to do it. But you're stuck because you can't make sense of an API or don't know where to look for the functions you need.
I wondered the same thing.
I was a classically trained musician and learned to implement some of these techniques in practice sessions. They're really effective.
But how could we use "deliberate practice" to improve coding? If we assume coding to stand for solving problems with code, then it seems we'd need to deliberately practice problem solving.
It's possible to measure problem solving skills, and push those skills outside of a comfort zone. But it's not as straightforward as measurement, "I'll play this passage without mistakes 3 times in a row", or "I'll place this golf ball on the fairway 5 times" and adjusting performance based on feedback.
It depends on what you're trying to learn with coding. I've recently had good success with this technique when applying it specifically to OpenGL. I've used a few specific parts of OpenGL extensively, and not used the rest of it very much at all. So I took some time to go through the Red Book examples very carefully and made sure I truly understood what they were doing. Then I wrote my own simple project using the techniques to make sure I understood them outside of the book. Then I started applying parts of them in my work at my job. Then I extended what we were doing in my work at my job by going a little further. And then I did it again going a little further still. It's been pretty effective.
You can certainly practice improving your mechanics, by which I mean your IDE/development environment whether it's keyboard shortcuts or workflow imrpovements.
You can also do katas whether it's practicing TDD or setting up a new instance of a project in whatever framework you're using. I also find katas useful for keeping familiar with syntax of languages that I don't use a lot, which is useful if you do a lot of language switching.
>You can certainly practice improving your mechanics, by which I mean your IDE/development environment whether it's keyboard shortcuts or workflow improvements.
Maybe practicing this allows you to get into the zone more easily since you won't be thinking about the mechanics. Getting into the zone more easily can lead to getting better and deeper understanding of the material.
A guitar player practices repetitive drills that aren't creative to help improve.
A good lead developer should help you grow, partially by selecting problems and partly by providing more/less structure. E.g. I might tell a junior developer to implement the design on the whiteboard and provide multiple rounds of code review, because just getting a complex implementation right is plenty challenging; for a more-senior colleague, I'm much more likely to throw him/her at a complex problem and I'll provide a few "you could have improved <X> by <Y>", possibly afterwards.
Force yourself to use patterns you dont like or dont suite the task at hand. Such as: today write everything using lambda callbacks, everything mvc, no classes allowed, no malloc allowed, etc.
That doesn't seem to me to be a directed, deliberate approach as the article implies is necessary. There's no way to know what patterns would be on the boundary of my skillset, so I might spend time using something that's unfamiliar but actually very basic which wouldn't challenge me, or something that's unfamiliar and incredibly difficult which would frustrate me because I couldn't make any progress. Isn't the reason that the system outlined in the article worked because the next level was always within reach but also something that provided a challenge? How do we get that in an arbitrary subject?
Essentially I wonder if the problem is that in some things we learn (eg coding) there isn't really a defined "ladder" that allows someone to practise harder and harder things in a deliberate way.
Yes, especially if you don't have a senior colleague where you work and there are no other developers who could review your code like in my case (sole Frontend-Dev amongst Java-EE-Devs).
