Ask HN: Strategy to become the best programmer possible?

2 points by wishpishh 11 years ago | 3 comments

What would be the best plan for becoming the best programmer you can possibly be? Most blog posts or articles I find when I google this question basically say that you have to be passionate, and you have to write a lot of code, but that's basically it.

But all of us are not fortunate enough to find some interest that's completely all-consuming. Don't get me wrong, I'm passionate about progress, about improving the world. And I like programming. I'm just not naturally completely absorbed by it.

So let's hypothetically assume that motivation or dedication is not a concern, that it is fixed. If we assume that you would find a way to put in X amount of hours per week, how should we distribute that time?

It's debatable what a "good programmer" is, but let's say that you want to be as diverse as possible, while at the same time having as much technical depth as possible. A different approach might be to outline two plans - one for becoming the best generalist and another plan for becoming the best specialist.

Some constraints to bring it somewhat closer to reality:

- Some fairly advanced educational background, say a university degree in software development or matching competence

- Having little or no previous experience of open source collaboration and not knowing where one would start

- Keeping a day time job (40 hours per week) that is moderately challenging and doesn't bring that many external incentives to become a lot better (say, an average web developer position or similar) at the same time

- Not spending more than 12 hours per day on work and personal training combined

- Having one day off on weekends

- (This leaves us at 72 hours per week, of which 40 hours are at the day job)

What would your optimal plan be, if we can assume that those 72 hours will be spent optimally, for 10 years?

dkersten 11 years ago |

IMHO there are two aspects.

Technical:

Read a lot of new material: articles, books, source code. The more it is different from what you already know the better. Get as diverse a coverage as possible. Same goes for programming languages. A good starting point is the book "Seven languages in seven weeks" because it covers a broad spectrum of language types.

But much more important than reading is doing: write a lot of code. Do the exercises in books you read, try out what you see in examples/articles/source code. Change things just to see what happens etc. Also lots of projects (from the tiny to the large) to put what you're learning to the test (and then make changes to your understanding based on trying things out). Contributing to open source projects isn't necessary, but definitely helps because you will learn a lot about how other people work and also get to take part in a much larger project than you would do on your own. There is unfortunately no shortcut or cheat to get out of actually doing stuff. No matter how much you read, you can't become great without writing a lot of code too.

The second aspect is do things that help you be an stay as sharp as possible:

Get a lot of sleep. Get plenty of exercise. Get fresh air. Make sure you have a decent diet. I'd recommend specifically dedicating some of that 72 hour budget to getting more sleep and exercise. Also, when trying to solve tough problems, go outside to mull them over. Or sleep on it. Lots of downtime helps your brain make sense of things (I'm a big fan of "Hammock Driven Development"). Find ways to deal with stress too. Short term stress might help focus, but long term I find it kills concentration and problem solving ability.

Seriously though, the technical aspect is important, but don't neglect the health aspect as it really does make a huge difference in my opinion.

DanTheColoradan 11 years ago | |

Great post. I really need to exercise. I do take walks though and I find that really helps. I think a lot of this boils down to knowing yourself, and that takes time!

For example, I've found that I skip around a lot, and I that's ok with me because I learn a LOT by doing that. I've found that if I stick to one thing longer than I'm able to stay interested, it is counterproductive. So I try to mix it. I read, I code, I explore, etc. As long as I feel internally that I'm making progress, I'm happy and I continue to love my work and love programming.

If anything by doing this I've found that I'm impatient and I want to learn more. I feel like my brain expands when I learn more about programming and I love that feeling.

Right now I'm working on C++ and sometimes I feel discouraged, but then I'll switch pace and - for example - write some code rather than read about how incompetent I am, and then I feel empowered and really want to read more.

So for me, a lot of it comes down to knowing yourself and working that to your advantage. And right now, I know that my health suffers due to my love for programming + all my other responsibilities. And so I'll work on that next.

Once again, nice post :)

wishpishh 11 years ago | |

Thanks for your feedback.

Regarding reading, I find there's simply too much to read to just leave it to chance what to read. I want to strike a balance between reading the best stuff on the fundamentals while at the same time keeping up with recent trends. Whenever I start following too many blogs or check in too frequently to link aggregators such as HN, I find that my reading becomes too shallow and my attention span just gets ruined. What I want to do is find the best fundamental stuff that is still relevant, and keep reading stuff that is slightly above my current skill level. At the same time I want to read the most recent trends that are more than just indulgance in buzzwords or every single new framework or whatever.

I also need to find a way to strike a balance between reading and coding. Maybe doing the exercises in the books is a good thing. But I also want to try it in side projects like you said. I just don't want to get stuck in side projects with needless detail that doesn't really move me forward as a programmer.