Ask HN: Deliberate practice to make for a better developer

I was wondering, how would one go about practicing deliberately to make oneself a better developer. The book attempt to break down the elements of deliberate practice, some of those are

- The practice itself - The book recommends finding a teacher or a mentor (if you are not already a star performer) to assess and give honest feedback on what your weak points are

- Highlighting highly granular areas for improvement, and then practicing till you get those right - This is one area I could use a few suggestions

- Quick feedback loop - I can see the compiler or your tests giving you a tight feedback look, but how would you know if you are doing something in the idiomatic way, or to tell you if there is a better way of doing it? I guess a mentor could help here.

Has anyone here tried to apply specific principles to improve their code, or their ability to see better solutions? Even when learning a new language or a new paradigm (OO, FP) I feel sometimes I hit the bounds of my comfort zone and never really step out of that.

Furthermore, how do you carve out areas for improvement?

I think this discussion might prove useful to most of here, be it improving your programming abilities or your elevator pitch.

[Update - Edit for formatting]

typically, to learn a new language, i solve a problem. the result of solving that problem is a chunk of code and it's usually a bit of a mess. you can use the mess to help identify what needs to be refactored. this then guides you towards learning more about the language, because often the mess is a direct result of not using the tool well.

note that what you're exploiting here is the fact that it's a lot easier to identify "a mess" than it is is to identify a gap in your understanding of the language; identifying the mess helps guide you to the gap.

at a higher level, the conclusion here is that you have not finished learning once you've written some code in a new language. in fact, you are just starting. it's only through repeated (obsessive?) polishing of the code that you achieve a deep understanding of the language.

(and i think this also applies to languages you know pretty well - i use python at work, and have used it for years, but i am currently working on the fourth major revision of my lepl parser library and am still learning as i rewrite particular aspects).

That's an interesting way to look at it. I guess I do struggle, because of the way I learn a new language or a technology. I spend a lot of time reading books, or other people's code, but I don't spend enough writing out a solution for I fear it will be not the right way to do it. Your suggestion turns this around on its head - try and write a solution, no matter how unpolished or un-idiomatic is, then step back and see what could be improved.

I like your take on this. Although, I will admit, I am still a little puzzled. Take, for example - I am currently spending time learning Clojure, and decided to attack the 99-Lisp-Problems to help me out. For a particular solution, I wrote a function that was about 8 lines long and I could not find a better way to solve the problem. A quick Google search revealed a solution that was a one-liner!

I guess that's my feedback loop - Other people's solutions to the same problems.

I typed my share of programs (a few tens or hundreds of pages, I would guess), and doing that helped me figure out stuff like

- which constructs are easier to memorise when you move your eyes back and forth from page to screen; - that shorter code is usually better - to keep only comments that would help me understand the code, NOT retype all the idiotic/historical comments originally in the program - you actually get intimately familiar with lots of code styles, good and bad