

Ask HN: Deliberate practice to make for a better developer - raju

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).<p>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<p>- 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<p>- Highlighting highly granular areas for improvement, and then practicing till you get those right - This is one area I could use a few suggestions<p>- 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.<p>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.<p>Furthermore, how do you carve out areas for improvement?<p>I think this discussion might prove useful to most of here, be it improving your programming abilities or your elevator pitch.<p>[Update - Edit for formatting]
======
beagle3
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

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

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

~~~
raju
_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.

~~~
andrewcooke
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.

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

~~~
raju
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.

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

------
techsansar
Intresting

