Ask HN: Deliberate practice to make for a better developer | Hacker News Reader

Ask HN: Deliberate practice to make for a better developer

8 pointsraju9 comments

I am currently reading "Talent Is Overrated". The book attempts to elaborate on a paper by Ericsson (I posted a link on HN yesterday http://news.ycombinator.com/item?id=1109919).

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]

Do not ever cut and paste while writing code; type it again. When I learned programming in the ZX Spectrum / C64 era, magazines and books were also used as a software distribution media - and you'd have to type in the program to get the latest and greatest.

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

This may not be 100% relevant to your question, but am posting this FWIW.

My last paid job (C++ and Java developer at an investment bank) required a 2:1 split between debugging and development work. I identified the following areas that could use improvement.

1. Knowledge of our code-base. I spent downtime at work reading code and documenting the system architecture. This also called for an improvement in my code-reading and debugging skills.

2. Development work flow and knowledge of tools/technolgoies (GDB, Linux kernel architecture, Perl and Bash scripting for handy scripts).

3. Domain knowledge (finance).

4. Knowledge of other technologies involved (Sybase, etc.)

I found that most situations didn't really call for expert knowledge of C++ and Java or of algorithms (as I was led to believe in the interview), but actual understanding of the code-base, the existing system architecture, and how our portions interacted with the back-end systems.

IMO, with any technology, you will hit a point beyond which there's diminishing margin of returns on gaining deeper expertise. But you should read the technology reference manual (e.g., the Sybase Reference Manual or the Bash Manual) thoroughly at least once so that you build a mental map of options available that can be used when you need them.

maybe you can, to some extent, exploit the nature of software? i'm thinking about how i have learnt, and how that ties in to the points you list above, and one obvious connection is that you are automatically guided to "highly granular areas for improvement" if you continuously refactor and revise (polish) you code.

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).

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.

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.

yeah, i think there has to be sufficient "surface area" for you to "find a way in". the simplest way would be to write a larger app, but in your case you could increase your chances for learning by working on other problems and then going back over earlier work - it's possible that you learn something on a later problem that helps you see the one liner in the earlier problem.

I think one of the best things you can do is start trying to solve something in a very public way. The faceless mob on internet will correct you, and you can quickly learn from your own mistakes.

However, this method has its drawbacks. You need to be able to simultaneously take the criticism with a (large) grain of salt, and be able to keep on trying after the eventual hash comments.

You will grow fast this way.

I was thinking of publishing some of my attempts at solving problems with Clojure on my blog to see what kind of criticism/feedback I would get.

Well, I can speak about the Clojure community. The ratio of constructive criticism/harsh tone is very good. Go for it.

Intresting

Reply on news.ycombinator.com