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.

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. See the help center for guidance on writing a good question.

Read more about locked posts here.

migrated from stackoverflow.com Feb 6 '11 at 3:55

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

  • 18
    Practice, practice, practice. And never be satisfied with the first thing that comes to mind. – Mark Ransom Sep 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! – Stimul8d Oct 21 '10 at 8:11
  • 5
    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
  • 3
    @Mark Trapp how is this not constructive? – rightfold Jan 22 '12 at 23:14
  • 1
    @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


Unit testing and TDD.

Once I started unit testing I was consistently producing virtually bug-free (yes, I know, there's no such thing) code. And once I started TDD I was able to reduce the time it took to write both the code and the tests.

  • 2
    Test-driven development (TDD) - incase someone is wondering. – VoodooChild Sep 13 '10 at 5:03
  • 1
    Now if you include documentation with TDD you will have a very refined and polished piece of software right from the start. – Chris Sep 13 '10 at 11:43
  • +1 for being very true. I'd also add "joining an open-source project and contributing", or starting a new one, both of which enable you to try and learn new things and get feedback. – dr Hannibal Lecter Oct 3 '10 at 22:26

I don't know about the single best thing, but:

  • trying to solve other people's problems

has been very helpful. Somehow it's very motivating to see an opportunity to fix someone else's problem. I end up looking up details not only in areas I'm familiar with, but even in areas I know nothing about, in order to answer people's questions.

This is true on SO, or on domain-specific mailing lists, or among my colleagues at work.

In the process, I

  • learn things I didn't know before,
  • refresh details I might otherwise forget,
  • gain skills in diagnosing problems,
  • gain understanding of what kinds of concepts are frequently unknown or misunderstood in my field

And sometimes it's just a good break from my own problems. :-)

  • Such a good comment, I wasn't 33% the way through it before I voted it up. – Hardryv Nov 6 '10 at 13:58

Be open minded and work with other people more experienced and smart than you.

I learned lot of things in college, reading books, magazines, blogs, attending conferences but nothing was even close to learn with peers who knows what I need to know.

Working with smart fellows teach real world solutions to you.

You can learn a lot reading their code, watching their practices and listening their opinions and stories.

Be careful with amateurs posing like professionals. Working with them will give you the opposite, your skills will down.

  • 4
    Always be the worst person in the band...it helps you become better. If you're the best it often helps you become worse. – HerbN Sep 13 '10 at 6:29
  • 1
    i'd like to add to the point of conferences. i didn't attend conferences but i watch them online. eg. Google Developers on YouTube, PDC, MIX. it keeps you up to date on the latest and sometimes teach you best practices or give new insights – Jiew Meng Sep 13 '10 at 11:19

Walk, Talk, Eat and Drink.

Walk away from the computer away from my comfort zone. Go talk to a real person about what we need to make happen. Eat lunch with the team. Drink after work.

Programming, I've found, is an extremely social communication-intensive activity. The coding occupation is dominated by people like myself who would much rather not be social. I'd rather figure things out myself rather than ask a question. I'd rather grumble about the inherent superiority of my design than collaborate. I'd rather be passive aggressive than confront someone.

The agile approaches recommend a lot of face time. I become acutely aware of my anti-social tactics. My effectiveness as a programmer went up by leaps and bounds. And believe it or not, my code got better too.

Better requirements from better questions. Improved designs from more input. Beer helped relax me.

  • Really like this answer. – Jimmy Sep 21 '08 at 19:32

Deciding NOT to be a 'Jack-of-all-Trades'

If you're serious about programming as a long term career, understand that you'll likely never be hired because of your versatility, but rather your expertise. To make an analogy, the least popular character in Everquest (at least when I played) was the Bard, who was good at nearly every skill but wasn't excellent at any of them. Pick a specialty and devote your time and energy at mastering fewer technologies rather than being so-so at many.

  • 7
    don't waste time playing MMO spent it learning instead could be a valuable advice to ;) – pmlarocque Oct 16 '08 at 20:25
  • 7
    Perhaps you can't imagine being hired for versatility, but it is actually rather common for me. Indeed, I am often specifically sought out as a consultant because I have an unusually broad set of skills, e.g., Oracle & SQL Server, Java & C#, Windows & Unix, etc. – Rob Williams Nov 18 '08 at 23:00
  • 2
    @Rob: I think tool diversity is a good thing. And general-purpose CS knowledge is a must. But I also think it's wise to choose a problem-domain specialization (machine learning, e-commerce, compilers, networking, 3D graphics, etc). I personally don't consider tool-fetishism as a "specialization". – benjismith Feb 13 '09 at 19:38
  • 2
    A DSP guy is going to want to use DSPs, an FPGA guy wants an FPGA. A C# guy wants to write C#, a Ruby programmer wants to use Ruby... etc, etc, etc, etc. Specialists won't know the best tool for the job. – darron Nov 24 '09 at 6:25
  • 1
    Of course they might hire a Ruby guy if they can find one that suits their needs. But if you have to choose, I think it's better to hire a good programmer than a programmer that has experience in your language and framework. Learning a new language or framework is easy. Learning to be a good programmer is hard. – mcv Jul 27 '10 at 15:26

Read. Code. Read code.

  • 2
    i like what you wrote. ;) – ShaChris23 Oct 21 '09 at 5:46

Honestly, I'm noticing that answering questions on SO is making me better. Of course, it's a slow process but I have noticed that in the effort to address other people's questions, I have learned intricacies that I wouldn't normally have explored while solving my own problems.

  • 1
    i'd like to add writing tutorials, it allows you to re-enforce what you have just learnt – Jiew Meng Sep 13 '10 at 11:20
  • SO has shown me things I didn't know existed. – Incognito Sep 13 '10 at 13:58
  • 1
    I think these can be summarized as communication, sharing knowledge, benefits not only the one who listen, but also the one who tell. – tactoth Sep 30 '10 at 6:24

Pair programming with other folk by far raised my quality, broadened my horizons, and helped me understand the practical issues of day to day development. Couple of big points:

  • it doesn't matter how elegant your code is - if someone else can't understand it you're already sunk.
  • be ready to divorce your code in a heartbeat. The romance is in the "doing" not the "outcome".

In response to Thorbjørn's question about pros/cons of pair programming. I feel I've been lucky enough to sit next to devs with quite different backgrounds (languages, experiences etc.)

  • Usually starting with a reasonable but often incomplete spec, we'd work through the problem and decompose it. While often there is complete consensus on approaching the problem - I learned most where our opinions deviated. (e.g. the sharing of negative experience of a particular approach)
  • Before coding we'd often spend much time at the whiteboard diagramming and walking how we thought the components would play out too. Having someone else validate your thoughts or poke holes in your supposedly watertight solution is quite humbling for the first time, but makes you better in the longterm.
  • Sometimes the hardest thing to do was compromise on the "right approach". Sometimes we'd step beyond pseudocode into class designer to role play what the code would look like. Often it became clear from doing this which approach was most natural. Much of it came down to a level of trust that we had in each other to do the right thing.
  • Worst aspect of pair programming was resisting the urge to grab the keyboard and just do it yourself because it was clear in your head how to do it. Giving space to let people's thoughts playout was sometimes where I learned the most.

In general though sometimes frustrating, it is also sometimes very rewarding. I feel I get as much out of pair programming as I give.

  • 2
    Pair programming has not worked for me. Could you add some comments on how it has worked for you, and what doesn't work well? – user1249 Nov 21 '09 at 9:21

Working with other great developers has taught me a lot over the years, that and actually doing stuff just for the hell of it from time to time.

For instance, I wanted to learn how to draw charts in GD so i wrote a simple biorhythm generator just for the fun of it. Not rocket science and I don't really believe in the pseudo-science behind it, but it was a good chance to learn what I wanted to do.


Going to a good university.

  • Glad this worked for you. I give lots of interviews and, while it's good to know someone has a solid background, it's not a truly predictive measure. Naturally it also depends on the degree. – Drew Noakes Oct 11 '08 at 9:20

Top thing: worked with other smart people and learned

Others, in no particular order:

  • active reading (books, blogs, nerd sites)
  • trying out new development concepts/methods
  • learned everything regex

Still want to try: contributing to an open source project.


stopped reading books and blogs and sat down and actually coded something


The most effective thing I did to improve my programming skills was to read the book Code Complete by Steve McConnell. I had been programming for many years without paying a lot of attention to the craft of programming. Reading Code Complete was a real eye-opener.

Here there were whole chapters discussing the naming of variables, the lay-out of if-statements, and how to write good commnets. It was really nice to see how much there is to learn about these seemingly simple things.

I got the first edition about ten years ago, before there were any blogs. But the book contained a good reading-list at the end. That got me reading classics like The Mythical Man-Month and Peopleware. These days of course, you need to read blogs as well as books.

I would also recommend working with testing and support for a while, even if your main thing is development. It really helps to broaden your view, and in the case of large systems (in my case telephone exchanges) gives you a good understanding of the important areas of the working system.

  • The books should be required reading before you can install a compiler – Even Mien Sep 25 '08 at 18:04
  • Writing comments is something I think I'll be quite obsessed with (seeing as I have not started coding yet) in the beginning, and hope to keep up. To improve code (even if it's uninentional) say, two years later would be much easier. "What? I was going to do that like this?!" – Jonta Nov 20 '08 at 15:32


Don't underestimate this!

Without a certain amount of sleep my programming skills vanish like a sandcastle in the waves. If your goal is a constant output of good code, do not work when you're tired, and don't try to fight sleepiness off using coffee, coke, candy or cocaine!

  • Some of my most imaginative work comes at 1:30 am. Then again, I also sometimes produce unimaginably unintelligible drivel around that time too. ;-) – Allbite Nov 6 '10 at 4:06

Tech support. If I was the Programmer King of the World, I would decree that no one could be a programmer without first putting in 2 years as front line, customer facing tech support. I dont mean "flip-book" & "read answers from a script" tech support like you'd get from a telco, but rather the kind where you have to actually research, test, and experiment to duplicate problems, report on them, interact with the customer, and if possible, find resolutions.

I find that when programmers go that route, they have a better feel for the 'ecosystem' of their products, and they develop a better feel for what the common weak points and problem areas are. In the end that lets them create more reliable products.

  • Not just more reliable, also more usable. Testers, developers, business analysts, offer managers, product managers, etc. rarely really understand where the user's job/workflow is hindered by the tool. – Malachi Jul 22 '11 at 15:43

I definitely agree that programmers and writers have the same mantra. For writers, it is simply to write, there is no way around it. For programmers it is to well.. program. With that said I think there are a few things that all programmers should do.

Most of these areas are really about stripping away the mystery and getting you to think about what is really happening below the level you are operating at.

In no particular order:

Learn several languages Learn LISP/Scheme, asm language of your choice, C/C++, SmallTalk

Get yourself exposed to different programming languages for the same reasons it is worth learning other spoken languages. These expose you to totally different modes of thought and will get you to look at problems in an entirely new light.

Write a language.
This will get you to think about languages at a deeper level. Just get something out and working before you try and create the next big language.

Write a multi-threaded OS Writing an OS will expose you directly to hardware, memory management, threading, protected memory, and get you to understand the machine. Be prepared for immense frustration, and deep satisfaction the first time you get a machine to boot to a prompt. :)

Write a game I'm a bit biased on this one. Games are immensely practical applications that force you to not only dig into numerous computer science and code construction problems, but they force you to be practical. For real fun, try writing to an older platform such as the PS1 or even the Atari 2600 (Stella manuals can be found online). These are "tricky" architectures that will force you to really understand them before creating anything interesting.

There are clearly many other areas to work on and things to do in order to improve yourself as a programmer. Some will be very craft related, and others are going to push your boundaries of knowledge. The above list is a great example of projects to set out to accomplish. You will be forced to grow as a programmer when working on them, and they will also set your resume apart for the future.

  • 2
    Write a language? Are you kidding me? Clearly you're unfamilar with the term 'opportunity cost'. – Jim G. Sep 2 '09 at 15:51
  • 1
    Wow, that wasn't very polite. – Jeff Thompson Sep 3 '09 at 17:14
  • 3
    I'll have to agree with writing a game, that was one of the things that taught me the most, there are so many aspects from maths to making best use of the processor, installation, security. – Jai Sep 24 '09 at 23:18

Wrote Smalltalk Best Practice Patterns and the Java version, Implementation Patterns. Thinking carefully about my habits lets me program more quickly and confidently and identify situations where the cookbook doesn't apply. I'm doing something similar with design right now and I find it really helps my effectiveness--productivity and quality.

  • 2
    If your current work on designs ever makes it into a book, I'll buy a copy. – Tim Stewart Feb 4 '09 at 23:01

What I did is this: I looked up how to improve my skills and found this answer on StackOverflow ;)

It came with a good value-for-money and information-per-square-pixel ratio.

  • Those square pixels are great. Linear pixels are so hard to see. :7 – LarsH Nov 3 '10 at 12:36
  • Well, they're not necessarily always square, so maybe I was wrong in assuming they were. – haylem Nov 3 '10 at 12:58
  • :-) I was just being facetious. My point was that pixels are already units more of area than of length, so that "per square pixel" is a redundant way of saying "per pixel". But you're right, they can be rectangular. – LarsH Nov 3 '10 at 15:09

After 30+ years of business programming it's hard to pick one event.

But I definitely have to go with one concept:

The most important target audience for code is the maintenance programmer.

Can I tell one story? (Tough. I'm going to anyway.)

Many years ago, back in the days when a minute of CPU time cost about as much as an hour of programmer time (nowadays the ratio is more like a MONTH of processor-core time per hour of programmer time), I was working in a batch-Cobol shop and was asked to help with a maintance problem outside the projects I usually worked on.

The program in question, right in the middle of its work, did a complex calculation about electrical power management.

My relevant background for the task:
* I speak fluent, native (American) English. Amy, the programmer attempting to do the maintenance, only sort of spoke English.
* In college, I had dropped an electrical-engineering course.
* I had more programming experience in more languages, and a bit of a reputation for solving code puzzles.

So I looked at this mass of Cobol code that Amy had identified as the area where the bug apparently existed. Yep, it was the power-management calculation. After ten years, after the people who created it were gone, the client had realized it was calculating incorrectly.

Most of the program was unusually clear and comprehensible for Cobol. Excellent style, reasonably good technique. Nice meaningful variable names, but not absurdly long ones.

Then there was this part - about eighty lines. Amy could not make heads or tails of it.

Neither could I, for a couple days. Even after I noticed that the first third of the block was just moving data from variables with names like (making them up twenty years after the fact) Killowatt-Hours-Per-Day to other variables with Fortran-compliant names like FFGFXKCD (not to be confused with FFGFKXCD), and the last third was moving the data back.

I suggest:
1) Don't do this sort of calculation in Cobol.
2) If you're going to do it in Cobol, have a Cobol programmer write it. Not a Fortran programmer who's never seen Cobol before.
3) A programmer who understands the subject matter and has tried to maintain a program before, would be a nice touch too. I think the Fortran programmer was missing at least one of those attributes, but couldn't determine which one - possibly because I didn't understand the subject matter.

But after about four days I figured out what the formula actually being calculated was, identified a part that looked wrong to me (and in fact was wrong), and had Amy send it off to the client for feedback. Got the correct formula back a few days later, and replaced those eighty lines of cross-species monstrosity with ten lines of pure Cobol that Amy understood.

(I have no doubt that in a Fortran program written by a competent Fortran programmer with a reasonable understanding of the subject matter - the situation that really should have been in place, at that time, for this project - it would have been one or two lines.)

  • I think the moment you realize your code will potentially live for ever (or at least longer than you) is one of the turning points in a programmers career. – user1249 Nov 21 '09 at 9:44

Ask lots of dumb questions on Stack Overflow. Seriously.

  • 3
    Asking dumb questions is a LOT easier than fixing dumb mistakes. – cometbill Jun 16 '10 at 8:33
  • There is no such thing as dumb people and dumb questions. – haylem Feb 29 '12 at 10:01

I decided to 'step in' instead of 'step over'. That made the difference. :)

  • 1
    you mean debugging? – Benny Jul 15 '10 at 2:09
  • @DeltaRogue can you elaborate on that – c0mrade Jul 15 '10 at 8:19
  • 3
    Yes Benny. :) @c0mrade As per my experience, debugging is one of the best ways. Many times, we just skip over code ( at least I did at some point) and never look into how things have been implemented (as long as they are working) but that's where many gems are hiding. TBH, I'm not at the level of writing code like in boost or roguewave but if I debug and dive-in in those or code of more experienced (better) programmers then I can see how all those intelligent people are using language and if I can incorporate that in my code, I have learnt the concept for life. Isn't that worth the effort ?:) – DeltaRogue Jul 15 '10 at 9:55
  • I second +1 pad – c0mrade Jul 15 '10 at 15:13

1) Teach

2) contribute to mass open-source products


Joining, posting and participating in stackoverflow was extremely significant in broadening my horizons, seeing what else was out there, how best to code things, getting advice. Also, by giving back to the community (by answering questions), it forces me to delve deeper into the questions I'm answering.


Try your hand at writing a compiler.

When you get right down to it it's not really all that difficult, but the exercise gives you tremendous insight into how a language turns fancy, pretty, structured code into processor instructions.

Then again, simply taking some time to pay attention to what your favorite compiler produces can be quite enlightening too.


Working in a small company

In big structures, you're (often) cornered in such a small angle of the big picture that it is quite difficult to improve on the whole.

If you work in a small structure, with a little team (but obviously a quality team), you can learn not only from others, but also just because you can set up things.

On the past 5 years, we've set up our scm (svn), our project management (scrum), our CI server (Cruise Control and PHPUnit) - in a big structure all of that would be already in place and you'd just learn of to use it - in a small structure you learn how to set it up, you learn why you need it (and what you gain from it), and you're free to improve. It needs more willing probably, but it's much more rewarding (imho) !

  • Indeed. Working in a small company teaches you a whole lot, if you're willing to learn. Even working for a "never again" type company is probably good for you. But it all depends on your own ability to recognize the problems and whether or not you actually try to improve the situation or just slack off/complain. – kosoant Jan 7 '10 at 15:18
  • At a small company you don't have the resources to become specialized to one area. You are literally thrown into the deep end and must be able to swim and learn any and every language, deployment environment (Linux, app server, etc) used by the team. Example, we changed how our whole team worked on projects in a matter of weeks, went to scrum for pm, added CI, switched from trac to Atlassian tools, and went from solo projects to the whole team moving together on a high profile project that had a hard 4 week deadline. You don't get that kind of learning experience at large companies. – Jared Knipp Feb 6 '11 at 3:47

So far the single most effective thing was probably the choice to learn Python (granted I'm just un petit enfant in the programming world with < 1 year professionally and ~10 years personally).

Most people will read this and "Say what??" but I think the choice to learn Python was the root cause of expanding my knowledge base about programming. When I first picked up Python, I was in my freshman year in college (I'm a Junior now...) and was learning C++. When I started learning Python on the side it required a shift in thinking to understand how to do it "the Python way". Because "There should be one-- and preferably only one --obvious way to do it.", I needed to develop the ability to think about things in a different way - wait what? everything is an object? We're really just storing references to those? Ohhhh, and when we add two string we're actually just referencing the object that is the sum of two strings. Ahhh, and that's why lists behave so "weird". That makes sense.

These mental acrobatics helped me to understand abstraction and object orientation a lot better. I think learning assembly may have been even easier because I had already spent so much time learning python (and pointers in C++). Python has also given me a reference to gauge other programming languages with.

So far, almost all other programming languages have a subset of features that Python provides. When I learned Java it was only the syntax - I already knew all the other "ideas" that Java presented. So far the only language I've come across that I went "Holy cow, you can do that???" or "Wait, you do what now???" has been Lisp. Attempting to learn Lisp has made my brain stretch and twist and do somersaults and do really crazy stuff. But if I didn't already know Python, I don't think I would have wanted to learn anything better. I think I would have still been programming C++ thinking it was cool to program, but not that great.

So yes, the decision to learn Python was probably one of, if not the most fundamental choice I made to improve my qualities as a programmer.

  • C++ was your Blub. :) – Paul Nathan Jul 26 '10 at 21:35

Decouple the money from the solution. As soon as you realise that the money you earn is not dependant on the code you write you realise that the people you work with and for depend on you being top of your game and trust you.

This whole process of trying to be the best that you can be for a client who depends on you for the best possible solution enforces you to become a better programmer.

Yes at the end of the day its all about the money, but there comes a time when you can demand more money for the skills you bring to the table. However you should always make a decision of whether your doing it for the money or are your earning money for something you love doing and get a kick out of it.

Never loose sight of the business need and what your there for. Customer is king.


Stop! Hammer time... Rather than adding a lot more code, improve your code and thus add less. :-)

Rather than to keep writing bad code you could stop and see how your code can be improved, some ideas:

  • Documentation
  • OOP, Functional programming, ...
  • Reuse.
  • Readability.
  • Small procedures by extracting methods.
  • Testing.

Engage on a open source project.


here is mine.. writing code of open-source projects over and over.. just get any source code and rewrite it on paper till you actually understand it.... it usually works

  • +1 Copy-n-paste is nice but we do miss learning opportunities. I remember typing in BASIC programs from 80 Micro magazine on my TRS-80 Model III... with anticipation... and learning a whole lot as I was forced to go through the code character by character! Kudos to you for using paper. Quite a marvelous invention. – LarsH Nov 3 '10 at 15:06

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