Looking back at my career and life as a programmer, there were plenty of different ways I improved my programming skills - reading code, writing code, reading books, listening to podcasts, watching screencasts and more.

My question is: What is the most effective thing you have done that improved your programming skills? What would you recommend to others that want to improve?

I do expect varied answers here and no single "one size fits all" answer - I would like to know what worked for different people.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

18

Practice, practice, practice. And never be satisfied with the first thing that comes to mind.
–
Mark RansomSep 3 '10 at 5:28

2

+1 for Mark Ransom...The difficulty comes when you're still not satisfied with the 100th thing that came to mind!
–
Stimul8dOct 21 '10 at 8:11

One of the most effective things I've ever done is positioned myself with those who knew more than I did and listened. Get on a project where you know the senior developer is working and pay attention to his/her code and way of doing things. When you don't understand, ask (when time allows). When you become a senior developer yourself things change a little and you enter constant discourse with your fellow developers on the best way to do things or fresh new ideas. But once again, you do a lot of listening.

Styrofoam Head Theory:

Often while explaining a problem to someone else, you explain yourself right into a solution. This happens frequently and is a fantastic exercise. The reason is because in order to communicate an issue to someone else you're forced to break it down to its simplest parts to make it easier to understand. So try writing an email to a jr. co-worker to explain the problem.

The singular thing that I did to improve my general programming ability was to read and apply the principles, guidelines, and suggestions in Steve McConnell's book "Code Complete". The improvement that it fostered in areas such as readability and maintainability has helped me immeasurably over the years.

Always remember two things.
1. Bits is bits.
2. Nothing is impossible - we just haven't figured out how to do it yet.

(1) must of course be credited to William Verts of the University of Massachusetts - Amherst. His lectures instilled the realization that although we may be working with different languages, techniques, technologies all we are really doing is moving bits from one location to another.

(1) feeds directly into (2). If all we are doing is moving bits around then we can move those bits around in any way to accomplish any goal. The second part of (2) really says it all - having not yet figured something out has absolutely no baring on our ability to figure it out.

In order to become a better programmer, you need to step away from the computer and work on your communication skills. You need to develop and hone these communication skills to ensure that you are programming the right thing. If you don't understand what it is your customer is trying to accomplish you will not be a very good programmer, no matter what your technical skills are.

Learning to read other peoples' code. You'd be surprised how many programmers cannot or will not do this. They'll spend hours and hours polishing arguments on why it would be more efficient to throw out the old code and rewrite from scratch simply because they do not want to go through the pain of reading and understanding someone else's code.

Number one technique for finding problems in the code I've written is run the debugger and step through it.

Number two technique for finding stubborn problems in code I've written is explain the code to someone else. Another programmer is best. Almost anyone will do. Probably not my wife or mother.

Since 2003, I've learned that ALMOST nothing is new under the sun. Always look for an example on the web before setting out into new territory.

Debugging other people's code. I work in the video game industry and we have hard deadlines to ship for the Christmas Holidays. In order to get out on time, at the end of the project we are forced to deal with squashing lots of bugs in short order while trying not to introduce new ones.

The ability to read through another person's code, understand what they did (and possibly what they did wrong) as well as fixing it in a way that won't introduce new bugs gives you insight into both other people's programming methods as well as how to extend your own.

I would say always try to come up with a model that solves a programming problem in its entirety and consistently. Once you nail the model then you can start to sketch out what this will look like code-wise. This applies to most disciplines.

I think the question is not well phrased. the "one" thing, sounds to me like
"silver-bullet" and we should know it does not exist. However a few things were mentioned here. One of the most important things is that you really like programmming.
If you see what you do "just" as job you never will get far IMHO. The next really important thing is practicing. You must read and write a lot of programs. I for my part suggest programs in different "programming models". Programming has a lot in common with hand crafting. Everyone successfull in that area has "learned" and practiced. There usually some sort of "master" around, it's difficult to tell who'll be a programming master, the area is that bride. You just can find out while reading code, bad code, good code, exceptionel good good, extremly poor code.

Ask yourself what was good done and what seems bad. Try to improve it. Ask yourself, can one understand the code or was the programmer just lazy to spend time on it.

1) Wrote a business aplication on Ruby on Rails. This forced me to think really hard on what's the best way to do things like organizing code, naming methods, etc. This lead me to properly understand MVC and adopt a proper "professional" attitude towards software engineering.
2) Progressed to programming business applications (web) with Java ande applied my knowledge from RoR development to Java web development.

These were probably the single most effective things that helperd improve my skills as a software engineer.

And these days also listen to podcasts, listen to presentations, wathc screencasts etc. RoR programming screencasts were probably the most impressive learning experience to me: somebody actually coded this just before my eyes and properly explained what he's doing and why.

My programming style improved immensely once I started to use unit testing. There's nothing like trying to instantiate an instance of one of your classes in order to run a unit test to truly see its dependencies on the rest of your code. Unit testing also gives you the confidence to refactor without breaking things too badly (unit tests are never perfect) which is a great way of taking advantage of some of those ah-if-only-i'd-done-it-that-way moments.

It is not something I did, rather, it is something I am doing constantly. I have a my.yahoo page that has, at this point, over 50 feeds that I read every day. I subscribe to 12 periodicals. I try to buy at least 2 programming books a year and read them from cover-to-cover.

All of these fail to hit the big one. No one is a good programmer until they learn how to debug. Especially other peoples code. Learn it/live it. Instead of reading the code from a good "Open Source" project, pick an existing bug on that same project and solve it. Try to solve another bug without your favorite debugger ... some errors do not manifest themselves in debug mode and a good developer has this skill. If you really want to know how not to design a system, or the intricacies of smart pointers versus garbage collection, or most other system complications, this is the single best way to go.