Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.


migrated from Feb 6 '11 at 3:55

This question came from our site for professional and enthusiast programmers.

locked by Yannis Mar 13 '12 at 20:38

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.

Practice, practice, practice. And never be satisfied with the first thing that comes to mind. – Mark Ransom Sep 3 '10 at 5:28
+1 for Mark Ransom...The difficulty comes when you're still not satisfied with the 100th thing that came to mind! – Stimul8d Oct 21 '10 at 8:11
Not wasting any of my time on Programmers Stack Exchange site helped me improve my coding skills immensely. – Job Feb 2 '11 at 17:53
@Mark Trapp how is this not constructive? – rightfold Jan 22 '12 at 23:14
@WTP - Read the description. "This question is not a good fit to our Q&A format." - as someone who asked this question, I agree. It was asked in more relaxed times. – Oded Jan 23 '12 at 16:52

360 Answers 360

Worked with other more experienced programmers. Helped other less experienced programmers.


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.

Hint: You've also just written some documentation.


Learning to learn from the mistakes of others.


If I had to pick a single thing, it would be code reviews. You need to be disciplined about it. Have your code reviewed and review other people's code as well.


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.


in order of effectiveness, the ways I've found to learn something are:

  • learn by reading
  • have someone teach you
  • learn by doing
  • teach someone
  • present to a group

There is no substitute for having to teach someone or present on a subject to get on top of something. I guess the list is in order of passive vs active involvement.

So for programming, presenting what I did is definitely a level above actually doing it.

  • Join a community (Stackoverflow is a great example)
  • Have an opinion. Don't just take what others say as gospel, question them.

When you look at a new or different piece of code, you may be faced with a lot of unfamiliar stuff.

It's tempting to make changes to existing code without understanding what all those moving parts are doing, and how. But I think that making the effort is important and ultimately pays off.

It can be difficult to do this when you're under pressure to produce results fast. But it gives you the experience to say, "I've seen this pattern before."


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.


Writing and knowing exactly what each command you typed do


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.

And read Code Complete twice.

  1. Complete a small project from A to Z, starting with documenting requirements and ending with UAT, production and support
  2. Let a person with grater experience (an architect) analyze your work and give you feedback
  3. Learn from your mistakes and apply the best of what you learned into the new projects
  4. Concentrate on the INITIAL QUALITY of your code. Create metrics to measure it and assess it regularly.

Programming is not only about coding skills, but also about processes, communications, time management, etc.

Live by the goal that you want to become best-of-the-best in your position at your organization.


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.


Worked in non-programming but related jobs, such as technical writing, producer, management, etc. The perspective you get is invaluable.

Became busy. Having lots to do forces you to adapt efficient methodologies.

Stuck with programming over the long-term. There is nothing as humbling as looking back on code you wrote ten years ago.


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.

Regards Friedrich

I think 10+ pages of comments have refined the question such that people will (and have) adapted their answers to it. Notice the laundry lists of things that have gotten uprated for proof that the "one" requirement has been worked around effectively. – John Dunagan Oct 23 '08 at 20:12

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.

But amongst these the key thing has always been: learn from others! Read books, read articles, read blogs. Reading sites like c2 Wiki, Coding Horror and The Daily WTF have really helped me gather knwoledge and undestanding.

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.


Learning vim


Podcasts such as DotNetRocks and Hanselminutes really opened my eyes to new concepts and ideas in development. This has lead me to many more resources, blogs and magazines that I was not aware of.

I was also lucky enough to have had a couple of jobs where I was able to incorporate development without it being in my job role, I could learn at my own pace and do things my own way.


Buying beginner books, it's like a kata keep rehearsing the basic so that your foundation is strong.


Spend at least one day a month researching new technologies and upcoming features of my chosen specialities.


Getting onto projects that I really enjoyed - gave me motivation to learn, innovate and develop new ways of doing things.

I have also found that working alongside other, more experienced people (having a mentor) is very useful as they pass on valuable bits of knowledge as well as different ways of doing things.


Reading about new ways of making things right
Make other people look at my code
read other people code


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

As a wise man once said:

When you're green you're growing, when you're ripe you rot! -Ray Kroc

This is something I live by.


As per my moto: "Never stop learning" :)


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.


The most effective single thing I've found?

Adopting the white-hat hacker ideal (essentially, curiosity about absolutly everything). If I don't know about something, I'll go and find out about it.

Admittedly this has lead me down the track to attempting to learn physics at the moment, but I'm sure it'll lead to some advance in my programming knowledge eventually.


There isn't one single thing that improves your programming skills. It's a never-ending process of refinement using many, many inputs.

Reading books, magazine articles, blogs, other code, lots and lots of other code both good and bad, doing peer code reviews, having your peers review your code, getting fired occasionally, changing jobs to improve your skills, thinking, trying new tasks, experimenting, absorbing new languages, accepting challenges, challenging yourself, accepting that you aren't the best, working to get better, acknowledging your failures and working to improve them.

Programmer, refine thyself.


Not the answer you're looking for? Browse other questions tagged or ask your own question.