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

Leaving university.

Spent 1 year there, before realizing that this is not the place where I will learn programming, and started applying for job postings. I was lucky to get one, and it was all down hill from there.

  • Working with experienced people? check.
  • Getting a shitload amount of experience from them? check.
  • Seeing different languages? check.
  • Seeing what tools other people use? check.
  • Learning that the client is always right? check.
  • Standing up in office politics? check.
  • Experiencing the first "oh shit the deadline is tomorrow and we have almost nothing" moment? check.

And I could just go on about how much more useful it was. I'm never going back. Maybe it's not the same everywhere, but here, they really really suck at teaching programming.

Exactly where, is "here"? – Geoff Jun 2 '10 at 17:29
College isn't the place to get programming's a place that teaches you how to think logically,analytically & critically to solve the problems you'll face in your future. I didn't do all those Differential Equation problems & write thesis's so I can use them in my programming...but all those years of problem solving in school program your brain, so you can use it more effectively. Plus, the degree helps your chances of moving up and on. – Ed B Jun 15 '10 at 15:19

The single most effective thing I learned about good programming was to be disciplined about refactoring. I have decent design skills, but good designs can go astray either during initial implementation or ongoing maintenance. This is especially true when new features are added later on as they tend to increase code complexity and brittleness.

Discipline matters precisely when refactoring becomes harder. We should usually be doing the easy, trivial refactoring on an ongoing basis as part of normal coding. It is when refactoring becomes hard that it can be of the greatest value in maintaining code quality and keeping design/implementation flexible and reusable. One has to keep return-on-investment in mind about when and where to do major refactoring, but it is a necessary part of good programming.

Lastly, taking on the harder refactoring scenarios helps to reinforce and ingrain the importance of refactoring as a standard part of one's coding practices in more trivial situations. The earlier and more frequent, the easier it usually is to keep code quality high and extend the usefulness of the existing software designs.

+1: Great points. And some would argue that the importance of refactoring goes hand in hand with the benefits of automated unit tests. The automated unit tests can, in theory, give you more confidence to perform important refactoring. – Jim G. Jun 5 '10 at 15:29
@Jim -- I agree with you about the value of automated unit tests; they do make it easier to do refactoring overall and be confident about releasing builds. Ideally, unit tests and regression tests should be used in conjunction with automated builds; we used this quite effectively in one place I worked. – Joel Hoff Jun 6 '10 at 23:13

Here's mine:

  1. Strictest possible use of design patterns

  2. Implementation only by using best practices, in the strictest possible way

  3. Unit testing, as strict as possible

  4. Strict commenting in the code, every single line gets a content in grammatically correct English, with correct spelling

  5. Learning the tools, the language and the infrastructure I use thoroughly, coding everything in a strictly Microsoft - compliant way

  6. Avoiding workarounds, hacks and P/Invoke where possible

  7. Learning functional programming

  8. Considering only code that is not written good code

  9. Forget everything I learned during the years I wasted with lowlevel timesinks like "C++"

  10. Forget everything I learned during the years I was forced to use RAD - and then learned to use RAD - tools CORRECTLY

I would say strict adherence to rules (see:Legalism) may lead to burnout very early. I would suggest learning the reasons behind the rules, and what other 'good' programmers think about them. – JoePasq Jun 4 '10 at 11:06
It is a good list to aspire to. I disagree with #4.. comments are just a repetition of what the code is trying to do and should only be used when the code is difficult to understand - which is something I aim to reduce as much as possible! – Mongus Pong Jun 4 '10 at 13:53
I totally disagree! The code should be suficient to document the application context. If you have code such as "if string.length > 8 ", and you must put a comment like "check string length long enough to be a bank account number", then it implies the code needs rewriting. Create a constant MIN_BANK_ACCOUNT_NO_LENGTH = 8. and rewrite the code "if string.length > MIN_BANK_ACCOUNT_NO_LENGTH". The comment then becomes redundant as any one can (and should) read the code to understand. Remember in a fast changing world, comments can quickly become out of sync with the code. – Mongus Pong Jun 4 '10 at 14:10
Having to amend the comments with the code is an error prone process. Think about it, how often do you find yourself actually reading the comments to work out what is going on? ;-) – Mongus Pong Jun 4 '10 at 14:12
I'd like you to expound about '7. Learning functional programming'; not because I don't believe you, just because I'd like some perspective. – Jim G. Jun 4 '10 at 19:05

Trying to build a game engine from scratch, just for fun. It touches on so many different aspects of programming that I had to learn all sorts of new things in order to get various parts of it to work.


I got an internship in IT.

Still in HS here. :)

It's great to see young people doing tech. I hate stereotyping older people as more qualified. That's wholly untrue in the tech world. ;) – Moshe Sep 12 '10 at 20:03
What? No "5-10 years experience in java/javascript" on the application? :p – Incognito Sep 13 '10 at 13:58
Those without 10 yrs experience with Visual Studio 2010, need not apply. – JeffO Sep 13 '10 at 15:00

Participating in programming contests

I didn't specifically do this to improve programming skills. I just realized that it seriously affected them.

Contests made me learn about—and actually implement—a lot of standard algorithms and operations with common data structures. They taught me to find "corner cases", and to write programs in such a way that these cases do not make my code look like a mess. They taught me to find an effective algorithm for many problems, and, most importantly, not to be afraid of difficulties when I'm to write something non-standard.

By programming contests I mean contests where you're to write small programs that solve simplified problems. A participant (or a team) is given limited amount of time and a small problem set. The goal is to implement the problems in such a way that they pass all the sets prepared by jury. Usually requirements (time and memory limit) force you to implement effective algorithms.

Aw man, you beat me to it :(. Programming contests made me really study and appreciate computer science and math, and understand programming is not just hammering out code that just sorta works. It makes you think about a problem before starting to type. And it just like working out at a gym, it trains your mind to do some serious weight-lifting whenever faced with a tough problem in the wild. – MAK Sep 12 '10 at 22:19
+1. These taught me how to use an IDE really, really quickly. – Phil Cohen Sep 13 '10 at 4:44

Two things:
1. Code complete 2
2. Reading a lot of open-source code


Over the duration of my career I learn one important thing that if its a difficult task programmers tends to do everything together. take small breath ,forget about the deadline ,break it in small bits and don't think about what you have to do after that (the next bit).

I forget to implement it sometimes. but when i do it do wonders for me.

+1 I do the same thing myself, especially at the start of a project when it looks like there's a mountain of stuff to do I tend to get analysis paralysis. That's why I'm experimenting with Wiki's now to keep my notes and tasks organized so I can focus on the task at hand and know what are the steps following that. – spade78 Nov 27 '10 at 17:16

From a programmer I met on a flash conference and I totally agree with him.

  1. Never think you know everything you should.
  2. As soon as you reached the state of "Woow I am the greatest programmer in the world in [fill in area]" bang your head on the wall untill you don't remember it.
+1 for #2... now where is that wall? – Oded Jan 25 '11 at 22:01

In the last year of my Computer Science undergrad degree, I took a compiler writing course. It was a full year course and in that course we created a pascal compiler from scratch. I wrote everything in C and I did not use lex or yacc.

That project advanced my programming abilities more than anything else that I have ever done.

Beyond that, the most important thing I've found that improved my coding abilities is to improve my analysis and design abilities. If your analysis and design skills are poor, you will be a bad programmer.


I spent the first several years of my career maintaining other people's code.

(The second most effective thing would be spending a few weeks grokking Common Lisp.)


1 - Read about a specific, narrow topic in a book like Code Craft, or Code Complete

2 - Apply just that one lesson to a project I'm working on

3 - repeat


1) Writing code. Lots of code. Most of it were only fun little dinky programs to solve a special problem, but since I've been on the workforce, I've written some production code. Every time I've seen something that I have done wrong, so next time I did it in a different way. In one word: experience.

2) Reading code. Before I only wrote code, but recently this is changing. I've been doing some code reviews, reading and evaluating open source stuff, sometimes even modifying some of it. This gave me a lot of tips, know-hows. Also, I can handle open source stuff with bad documentation somewhat better.

3) Show your code to someone. Other points of views can show you stuff you never tought about. A programmer on embedded systems may recognise something that can be done with less resources, a security programmer can point out failures, etc.

4) Tutor someone. Despite what some people say, programmers have to maintain human contact. Also, it gives something back to the community. I've met some of my friends during tutoring sessions. It makes you a better programmer because you'll be able to communicate better (which is realy important if you want to write good documentation).

5) Learn a wide range of languages at least to some degree. The difference between them is not just syntax. ASM needs different thinking than Java. Lisp programmers program different than PHP developers. Knowing a lot of languages at least to some degree gives a perspective.

6) Work on something for a while. If you have a cool idea, work it out. Try getting your peers involved. It's realy fun to work in a small group, solving your own problems. The company I work for started this way. But before you begin your career, it will help you understand teamwork. Also, you'll get to see how an application is designed, implemented and maintained.

There are more reasons, but these helped me a lot.


Probably digging into GoF design patterns, which certainly opened my mind in terms of source code reusabity and maintainability. Also, Martin Fowler's book and articles on refactoring made me a better programmer.


All the advice here is nice, but you asked for a single thing:

Reading The Pragmatic Programmer. After 9 years, still no other book is as relevant. Religously live the advice given.



I have a personality quirk that leads me to re-invent just about everything. I want to know how everything works, and that tends mean writing a huge amount of code. I've become very good at it.

Programming is a lot like playing the piano. The more you ACTUALLY WRITE CODE, the more skilled you will get at that. The more you debug code, the more skilled at debugging you will become.

I had a step-father who was a really amazing pianist. He told me that he estimated you needed to play about 10,000 songs on the piano and then you'd be excellent. He didn't think it mattered much what kind of learning styles you used... you just had to get the practice in. The goal is to retrain pathways in your brain and get yourself all tuned up.

Obviously playing chopsticks 10,000 times isn't going to make you a concert pianist, so don't be stupid. However, anything halfway reasonable should work.

If you think code reuse means spending 8 hours on the internet searching for someone else's solution to a problem and then copy and pasting that in... sorry... you aren't going to improve very much.

I've met a great number of people who want to believe that with the right tools, you don't need to program very much. You must absolutely, totally purge any inkling of this concept from your head and stomp on it until it's about 2 nm thick. It's horribly destructive from a self improvement point of view.

"New software for concert pianists from Rational Software! Convert your Symphony Modeling Language diagrams directly into sheet music! Export to all current platforms using MIDI, perforated scrolls, or music box cylinders! No more hours and hours slaving over the keyboard!"

"If you think code reuse means spending 8 hours on the internet searching for someone else's solution to a problem and then copy and pasting that in... sorry... you aren't going to improve very much." LOL – aartist Nov 23 '09 at 23:15

Learning Haskell gave me a fresh perspective on my programming approach. This has improved the way I approach programming problems considerably. I cannot recommend enough trying out different programming paradigms in order to improve your problem solving skills. It doesn't mean you have to abandon your favorite environment. Just look at how things can be done differently and learn from that.


Fixing/enhancing other peoples code.


Never think you have all the answers...there is always something to learn.


Read "Code complete" by Steve McConnell...


Subscribing to Coding Horror lol. Actually I found that getting a new job on a project that interested me helped the most. Mind numbing web programming for the great state of NY was kinda depressing and was holding back my coding potential.


For myself, being open to new ideas and trying to see the bigger picture which gets to be a bit of a paradox at a point. Some examples:

  • Design Patterns - Reading about them, using them in new projects, seeing where they may already be used but I don't know that that is a pattern. These can also be work patterns or patterns in how projects are done though these are usually viewed as practices...
  • Practices - In my case this is learning refactoring, Agile, Scrum, estimating work using a modified Fibonacci values, TDD, as well as new tools like Resharper, SVN, etc. Also in here can be concepts like technical debt and broken windows that can be really neat ways to convey ideas in some cases.
  • Architecture - See how some big systems are tied together and how different components come together to build say a CMS or CRM system.
  • Evolving technology - I can look at how I use VS 2008 and try to remember back to using VS 6.0 many years ago and some parts of how I build web applications has definitely chaned over time which can be beneficial to see new ways to put things together.

The paradox comes from that at some point, I'm looking at things from such a high level that nothing is really in focus and so the challenge them becomes trying to get back down enough to know how to put together the smaller parts while still understanding a big picture for where I'm trying to improve something.

Finding better work environments is another big thing can affect my skills. If I'm working with people that produce code of a high quality, polished code with tests, that can act as a way to influence me to be better about what I add to the codebase. Similarly, if I work with a bunch of cowboy developers, this may make me be more of a cowboy coder myself.

  • By cowboy I mean that kind of developer that regularly has spaghetti code that as it was all done by 1 or 2 people they know what ideas where behind various parts of it and there can be many times where one has to go, "Crap, now I go fix that," or "Whoa... how did I miss that?" or, "What do you mean someone tried to put in X as a number? That's not cool."

Stop being so cocky and listening openly to other alternative opinions.


abstract one mile long, code one inch deep

-1: Huh?? Can you please explain? – Jim G. Jun 5 '10 at 15:42
  • Get used to the fact that longer, more verbose code (boring code) code is often better readable and understandable than shorter (clever) code.
  • Get used to the fact that you sometimes have to delete what you have been working on for the past week, just to write it all again, in 50% of the time and much cleaner.
  • Keep learning other programming languages and frameworks.
  • Talk to more experienced programmers.
  • Never "be happy" with your skills - keep improving all the time.
  • Look at older code you wrote in the past from time to time - you'll see how much you improved and how much more clearer your picture of the programming language and frameworks has become.
  • Write documentation. Document every single function - even if it's just one sentence. Use a tool like Doxygen, which will teach you to love writing documentation.

Learning different classes of programming languages...

C, Java, Python, LISP...


Working on a personal project...something you enjoy. For me it was game development, learnt more about programming in a month than what i had learnt in the previous year.


working with Nemerle


Reading/applying 4 books:

Elements of Programming Style by Kernighan + Plauger
Software Tools by Kernighan + Plauger
Mythical Man-Month by Brooks
Psychology of Computer Programming by Weinberg

Is Elements of Programming Style still worth reading (seems a little outdated)? – Oliver Weiler Nov 7 '10 at 12:27

I've not been programming for long - roughly a year, unless you count HTML/CSS work and very basic PHP stuff for querying databases.

I started programming in Pascal at college, and found I had a natural 'knack' for programming. Most of the tasks given to me were easy (it was only an introductory course). Since I started the college course (I'm about to start university in a couple of weeks), the following things have helped me:

Note that these are very much from a student's perspective.

  • Make programs more complicated than required in the tasks given. I made all my programs go 'the extra mile' - more functionality, a better UI, more suitable for a real-life application. This gave me the opportunity to learn new things that weren't necessarily included in the course.
  • Do a lot of reading. I read a lot of material, admittedly mostly online, on Pascal and how to do what I wanted. Since then, I have also done a lot of reading about other languages - C, C++, PHP. And also other paradigms, especially OOP. Reading what other people have to say, from a variety of sources, has given me a pretty decent idea of how to program well.
  • Program, program, program. The more I actually program and put into practice the things I have learned from college or reading, the better understanding I have of what I'm doing and how the theory really works.
  • Review your code. I find that going back to programs that I have previously written and taking a critical view of them really helps. I can see how to better write the code with the knowledge I've gained since then.
  • Rewrite your code. After reviewing old code, I find that rewriting it using new methods I've learnt really helps me to appreciate what I've read. If I can successfully rewrite, for example, a holiday quote system that I wrote while at college, I can see the benefits from start to finish of using new methods.
  • Ask questions. Sometimes tutorials and articles can be a little too technical and a lot seem to assume prior knowledge, even so-called 'beginners' guide to...' articles. Asking someone you know, or using place like SO means you will often receive a much more useful answer in terms you can better understand. Especially if you are a beginner.
  • Design code first. We only did basic top-down design in my college course and at the start I had a habit of writing the code first and then 'cheating' the design process. Once I got onto larger programs, I really began to appreciate the benefits of designing my programs first - made the actual programming part so much easier and quicker.
  • Program, program, program. This is definitely the thing that has helped me improve my programming skills the most. It's worth two mentions, I think. Having theoretical knowledge is fine, but if you can't put it into practice, what's the point?

I'd recommend all the above things to people who want to learn how to program, and probably one other thing: Don't be afraid of jumping in with both feet.

"Make programs more complicated than required in the tasks given." I wouldn't say "more complicated", because that's actually not desireable in many cases. What do you think about "more elegant"? – Johann Philipp Strathausen Sep 6 '10 at 8:58
@filip Perhaps I made a bad choice of words there - rather than more complicated in terms of the code, I meant that the programs would have more functionality integrated into them. For a beginner programmer, I found that this complicated the process of writing the programs. But yeah, perhaps "more elegant" would be a better phrasing. – Saladin Akara Sep 6 '10 at 9:30
How about "more full-featured"? – LarsH Nov 3 '10 at 15:11

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