Hacker News Reader

Comment by falcolas | Hacker News Reader

You're perfectly capable of being a mediocre (or terrible) developer while writing code from the time you wake up to the time to go to bed.

The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter.

Ask a professional musician how they got better, and you won't hear them say "by playing the piano for 16 hours a day, every day". They'll say by doing focused practicing. And that can be done in anywhere between 2 and 6 hours a day.

Even at your day job...

You want to be a truly useful software developer? Expand your knowledge beyond software development by doing more than developing software.

View on HN

> The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter.

> Ask a professional musician how they got better, and [...] they'll say by doing focused practicing.

How does focused practicing look for programmer?

Google brings up this:

http://artists.pixelovely.com/focused-practice-an-exercise-f...

Step 1: Identify what you’d like to be better at, and be specific.

Step 2: Try to break this goal down into smaller goals. List them. Notice if one might interfere with the other goals if it isn’t tamed first. Choose the most foundational goal.

Step 3: Commit to practicing that aspect of drawing 100 times. Each practice should take a minimum of 5 minutes.

This is for drawing but it looks like it could be adopted for programming.

EDIT: googling some more brings up this article https://sites.google.com/site/steveyegge2/practicing-program...

EDIT2: even more googling finds more concrete focused practicing http://web.archive.org/web/20060316094755/http://blogs.pragp...

Don't you think the emphasis on repetitive practice makes more sense for skills that are based on bodily coordination?

I think getting better at programming has more to do with learning patterns, thinking carefully, and hard-won experience.

You're missing feedback. If you don't get regular feedback, all the thinking and patterns in the world aren't going to help you learn.

Feedback does not need to be external; it can be driven by the requirements you set forth for yourself. "I want to learn to build in low memory environments," leads to "This backend must never use more than 1MB of memory." "I want to figure out how to optimize programs," leads to "This backend must respond to every request in under 50ms." "I want to know everything about my current programming language," leads to "Obfuscate Hello World!"

Create a feedback loop and write simple programs, each time with different criteria. "I can only use functions," or "This must be as fast as possible," or "this must be as slow as possible (without using sleeps)"... the possibilities are many, and the time required is small for each exercise.

They make for great 20^H^H1% projects or "I need to step away from my current program" tasks.

Well, I thought of feedback as part of "hard-won experience", but yeah.

You invert a binary tree for fun

yup. I worked at a place where they would constantly write code. lots and lots of shitty code that never should have been written. issues scaling postgres -> rewrite active record to use the latest nosql db. issues with that -> rewrite the app again.

there's a difference between just writing lots of code and understanding what your doing. I like the approach of writing katas every day until you've really internalized the technique you're working on.

Reply on news.ycombinator.com