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.

  • 18
    Practice, practice, practice. And never be satisfied with the first thing that comes to mind. Sep 3, 2010 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! Oct 21, 2010 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, 2011 at 17:53
  • 3
    @Mark Trapp how is this not constructive?
    – user4595
    Jan 22, 2012 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, 2012 at 16:52

360 Answers 360

2 3 4 5

In no specific order...

  • Working with people far smarter than myself

  • Always listening to what others have to say, regardless if they're junior, intermediate, senior or guru. job title doesn't mean anything.

  • Learning other frameworks/languages, and seeing how they do things, and compare that to stuff that I already know

  • Reading about patterns, best practices, and then examining my old stuff and applying those patterns where necessary

  • Pair programming

  • Disagreeing with everything Joel says. ;)

  • 41
    I know it seems really gratuitous and potentially reputation whoring, but if you separated those items out to one per answer people could vote up which ones they agreed with, allowing for a more specific end vote "solution" of this question.
    – davebug
    Sep 16, 2008 at 23:10
  • 117
    Watch how smarter people handle mistakes - that's when I learn the most from them
    – Mike Robinson
    Feb 2, 2009 at 21:38
  • 82
    if this is a list in no particular order, shouldn't it be an unordered list rather than an ordered one? :P
    – Jon W
    Aug 31, 2009 at 19:03
  • 3
    I agree with mmyers - just because you disagree with someone doesn't mean you're ignoring them. Actually, it's the opposite - in order to disagree with them you're actually paying attention to them. Oct 10, 2009 at 21:46
  • 15
    I don't cart-blanche disagree with everything Joel says, I think much of the time he has some interesting things to say. My comment was tongue in cheek. There's a lot of stuff that I agree with when it comes to Joel, but about once a month he makes me shake my head and ask "What? Are you serious?!". Which I love, as I find those the most challenging things that force me to really check my position and what I believe.
    – cranley
    Oct 19, 2009 at 17:14

Deciding TO be a 'Jack-of-all-Trades'

Fairly early in my career, I was an expert with a particular database and programming language. Unfortunately, that particular database lost the 'database wars', and I discovered that my career options were ... limited. After that I consciously decided that I would never let myself become boxed in like that again. So I studied everything I could get my hands on: Windows, Unix, C, C++, Java, C#, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL, etc. Whatever tools and technologies are new or unusual, I became the 'go-to-guy' -- "Ask Craig, if he doesn't know it, he'll learn it." As a result I've worked on all sorts of projects, from embedded systems for environmental telemetry to command and control systems for missile defense.

The only problem I've ever had is with companies that insist on pidgeon-holing me into a specialty, when my specialty is being a generalist. [EDIT: Also known as a Polymath or Renaissance Man or multi-specialist.]

Something to keep in mind ... what's the half-life of knowledge in high tech? It tracks with Moore's Law: half of everything you know will be obsolete in 18-24 months. An expert who chooses the wrong discipline can easily be undermined by the press of technology; a generalist only has to add some more skills and remember the lessons of the past in applying those skills.

  • 224
    "Jack of all trades, master of none, though often better than a master of one." -Adam Savage
    – jms
    Sep 19, 2008 at 6:08
  • 9
    Excellent advice, up voted. The "orphan tech" in my past was my 8-bit Atari, which lost out to the C64. I reached the same conclusion though - to quote Heinlein, "specialization is for insects."
    – Sherm Pendley
    Oct 23, 2008 at 20:48
  • 17
    There are always tradeoffs, and there's only 86,400 seconds in a day -- you'll have to decide how you want to spend them. In my case, I've chosen to spend extra hours (above and beyond my 'work' hours) to learn things that I thought were interesting or were going to be in demand in the future; you'll need to make your own choices. Jun 16, 2009 at 16:23
  • 74
    "Specialization is for insects." - Heinlein Jul 15, 2009 at 22:25
  • 31
    Where is your "Generalist" badge? ^^ Sep 2, 2009 at 15:31

I always thought of my self as a pretty hot-shot programmer. Then a new guy, call him Aaron, was hired into our team. Aaron was obviously much better than me in most areas. He was younger than me, too. He made me realize I hadn't really improved much in the past years. I was an ad-hoc hacker, and a mediocre one at that.

This alerted me to consciously try to improve myself and especially the quality of code I write.

Aaron lead me to learn a lot of things. He taught me how most of the code I write will have to be maintained and extended for at least several years, so I should write the code with that in mind. I should write automatic tests for my code. Aaron was always talking about how I should never stop at the first working version, but refactor and refine until the code is elegant. I've discovered that the languages and tools I was using had a lot of room for improvement.

The most important thing I learned from Aaron was to never stop learning.

After a couple of years, Aaron left the company. I felt empty. The past years with him had lifted me to whole new levels of skill, and I realized I was now much better than the rest of the team. They were still writing bad code, and doing the same mistakes as before. I tried to teach them, but they had no interest to learn. In fact, they were annoyed that someone would be so arrogant to tell them what mistakes they were doing.

So, a few months later, I left the company as well. I moved to a smaller company with a very talented team. Everyone there wanted to learn more, and I loved it.

I'm glad I met Aaron. Without him, I'd probably still be working at the old company with the old gang, going nowhere, and thinking too much of myself.

  • 54
    That typically works both ways. I've come into a few companies now as an 'Aaron' and found that once I get the other coders energized that they start to give me a run for my money and encourage me to redouble my own efforts. Great post!
    – Echostorm
    Oct 24, 2008 at 11:46
  • 28
    +1 for "Aaron was always talking about how I should never stop at the first working version, but refactor and refine until the code is elegant"
    – iceangel89
    Jun 16, 2009 at 11:17
  • 17
    "never stop at the first working version"??? - when are you supposed to get the rest of your work done? :)
    – Ronnie Overby
    Oct 2, 2009 at 3:10
  • 4
    I've attempted to be Aaron, sometimes it works, but sometimes I'm wrong. "Those who cannot learn from history are doomed to repeat it." It's good to keep our minds open to new ideas, but it's bad to listen a n00b over those who've already made the mistakes for you. Everyone needs some skepticism, as we learn from asking questions of ourselves and others.
    – Dan Beam
    Dec 21, 2009 at 3:58
  • 27
    The problem is too many people think they are "Aaron"
    – cinqoTimo
    Aug 21, 2010 at 17:46

Two things:

  1. Read code written by different people.
  2. Write documentation for code written by other people.

Writing code is extremely easy; every other person I know can do that. But reading someone else's code and figuring out what it does was a whole new world to me.

  • 42
    AND one of the best ways to learn what NOT to do :)
    – AviD
    Sep 21, 2008 at 10:46
  • 9
    You can see how they do something. Maybe they do it in a better way than you?
    – Jonta
    Nov 19, 2008 at 14:52
  • 4
    I had to dig into a really old and completely undocumented project, document it, fix some bugs in it, and port it to a new system. I learned a lot, and not all of it was what not to do. Though I did learn the value of comments.
    – Sydius
    Dec 9, 2008 at 6:56
  • And while you're writing the documentation, maybe write some unit test cases for it (if they don't exist). Then you'll also know how to use the code.
    – dhable
    Jul 23, 2009 at 16:22
  • So true, that was the hardest part of my job for a long time.
    – Evernoob
    Sep 16, 2009 at 13:34

Hit the gym regularly.

Seriously, my brain works a whole lot better when I'm in shape. Problems become easier and less overwhelming, goofing off is much less of a temptation, and working through things step-by-step doesn't seem like such an arduous task.

  • 30
    The sad fact that a majority of people don't exercise or even stretch at all on any sort of regular basis is a huge problem in today's world.
    – Sneakyness
    Dec 3, 2009 at 7:29
  • 5
    I'll extend this, if I may, to any amount of physical excursion. Sometimes, when I've not done much manual work for a while, I start to crave physical tiredness. It's kinda novel when you're so used to being mentally drained and it helps you break out when you're just thinking yourself round in circles. Oct 21, 2010 at 8:20
  • 1
    yes that's the big problem today. we don't have the time especially in pakistan where the working hours are lot more
    – maz3tt
    Nov 27, 2010 at 7:45
  • 2
    +1 as a reminder to myself to get more exercise. Feb 6, 2011 at 4:01
  • I find that a sport is a great motivator - for me, it is basketball. Sep 7, 2011 at 18:56

Programming. Working on interesting projects. There is NOTHING like getting in and working on stuff. Especially under pressure. I always tell anyone who asks me how to program - just find a cool project (even if you have to make it up) and work on it.

  • 4
    I agree. Getting my hands dirty in a project has been probably the biggest contributor to my improvement. ; )
    – Mike Grace
    Jul 18, 2009 at 23:14
  • 1
    Exactly. The single best way to become a better coder is to code. You can learn all you want from books, podcasts and co-workers, but you have to apply it before you really understand it. Code more, and code more different stuff. Because you don't learn much from repeating the same old trick.
    – mcv
    Jan 12, 2010 at 16:30
  • Choosing challenging and intriguing projects to do. I think the struggle to overcome outside of your comfort zone really speeds up your skills. They didn't go to the moon because it was easy. Nov 16, 2011 at 2:08

Took a part-time job tutoring CS students at my university. It really forces you to understand something at a completely different level when you have to explain it to someone else.

  • 1
    I can vouch for that.
    – John Calsbeek
    Sep 17, 2008 at 4:10
  • 1
    An instructor at the university told me about the opening when I was still a student. I stayed for nearly a year (part time) after I graduated. Oct 1, 2008 at 20:05
  • 29
    As Douglas Adams writes in "Dirk Gentley's Holistic Detective Agency": "the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas."
    – Jonta
    Nov 19, 2008 at 14:58
  • 2
    Too True. Teaching photography made me a better photographer. Not much of a coder tho :(
    – CAD bloke
    Nov 20, 2008 at 6:41
  • 9
    mutuo ista fiunt, et homines dum docent discunt - Seneca
    – pageman
    Aug 12, 2009 at 20:45
  1. I'm a big fan of the "learn one programming language every year" system. One year gives you enough time to get past the "okay, I know the syntax, so now I know the language" bias, and forces you to go a little farther and understand what's beneficial in that language, and program in a style native to that language (By which I mean, you don't end up writing java applications using Ruby syntax). Each language will change the way you think about programming- I knew how to use recursion, but thinking in recursion didn't happen until I took a class on prolog (I imagine a functional language like ML would have the same effect).

  2. Start a Pet project. My personal equation for a good pet project is, something you have experience with + something you don't = app you would find useful. For instance, Migratr (my own caffeinated-weekend-turned-ongoing project) started out as "I know c#, but I've never coded against a web API. And I want to move all my photos to Zooomr". It could just as easily have been "I've coded against web API's before, but I don't know C#"

Publishing your pet project is an amazing educational experience in itself. Suddenly all the things practically nobody teaches but everybody's supposed to know (for me it was setting up your own testing system, getting the most out of version control systems, how to pace yourself when nobody else is setting your deadlines, how to interact with your users and how to know when to say "no" to feature requests), all that stuff bubbles to the surface and forces you to self-educate on a level you weren't before- at least not by idly reading flamewars on dzone about the pros/cons of the "foo" vs "bar" way of doing things.

Doing these two things covers both ends of the spectrum. Learning a new language will make you a better coder. The pet project will make you a better developer:P

  • I can only agree; "pet project in a previously unknown language" is good, I can confirm
    – Manrico Corazzi
    Sep 17, 2008 at 7:26
  • Very good suggestion to learn something halfway familiar.
    – Blub
    Jul 27, 2010 at 9:58
  • Great suggestion "something you have experience with + something you don't "! Thanks
    – sica07
    Jun 8, 2011 at 11:06
  • I need a pet now. Sep 7, 2011 at 18:58

Taught myself assembly. Did it on an old 6502 chip when I was 13? 14? Too long ago. But I can't think of anything that will improve your development more than getting down to the bit level.

Learning assembly gives you insight into the way computers 'think' on a fundamentally lower level, and the elegance at this level is surprising... there are no wasted motions, no 'disposing' of data. Developing at this level will teach you efficiency and hone your critical thinking and logic skills. It will also cure you of any sloppy habits you have fairly quickly!

The 65xx chip had three registers (the accumulator, X, and Y) and no machine level instructions for multiply or divide. I remember coding a routine to calculate battle damage, looking through the book, and suddenly realizing that I would have to write my own math library. Spent a couple of weeks scribbling 1's and 0's all over my notebook, trying to figure out what 'divide' and 'decimal places' really meant.

I've studied C++, pascal, .NET, many others since then... but none of them have taught me as much, intrigued me as much, or left me with the sense of 'wow' that assembly on my old commodore did.

  • 16
    I gotta vote you up just for bringing back wonderful memories! Maybe I even teared up a little :) May 5, 2009 at 20:16
  • 3
    I still mentally translate C/C++ into 68K assembly language. It's amazing how that helps you write efficient code for any platform.
    – Bob Murphy
    Oct 10, 2009 at 20:19
  • 1
    Ah, the 6502, brings back great memories. I learned so much with assembler on this chip.
    – Mike Nelson
    Jan 12, 2010 at 16:52
  • 5
    EVERY student of programming should have in-depth exposure to assembler early in their education!
    – mickeyf
    Jun 15, 2010 at 15:32
  • 2
    I did the same thing as a youngster. It really taught how computers work, moreso than a high-level language ever can.
    – CAD bloke
    Sep 6, 2010 at 5:42

Looking back at old things I wrote and realizing just how bad they were.

  • I second that... I can hardly even read some of my old stuff.
    – Unkwntech
    Sep 16, 2008 at 20:10
  • 28
    When I go over old stuff of mine I get nearly-irresistible urges to delete the whole file. Sometimes the whole directory. Sep 16, 2008 at 21:03
  • +1 for objectivity. Looking over your old code won't tell you how to improve, only if you've improved and how -- or conversely, if you haven't.
    – Aaron
    Sep 17, 2008 at 5:47
  • I have done this--I wrote this whole script interpreter in VB6, I wrote it over two years; it could make windows, handle their events, etc. It grew so large and out of control that I could no longer add to it without breaking everything. That was the last thing I wrote before I gave up programming for books about programming. Now I am much better phew. Reading back on that monster project makes me realize just how far I've come Aug 20, 2009 at 18:37
  • 3
    @Christopher Mahan: And on really bad occasions, the entire volume.
    – Thanatos
    Sep 3, 2010 at 5:35


  • books, not just websites
  • for self-improvement, not just for the latest project
  • about improving your trade, not just about the latest technology
  • read code, not just you are working on.

Just develop the appetite for reading.

  • 2
    Plus, frickin', 1. I was starting to wonder where this choice was.
    – Thanatos
    Jan 11, 2010 at 9:24


Seriously, there are books, there are coding katas, there are sites like this, but I believe that the best way to improve as a developer is to work on real project, with real fickle customers with real, ever-changing requirements with real engineering problems. There's no substitute for experience.

  • 8
    If you want to get better at something, there is nothing better than doing it.
    – Jeff Siver
    Sep 12, 2010 at 21:03
  • 4
    +1 -- This reminds me of Finding Forrester: "The first key to writing is... to write"
    – Wizard79
    Sep 12, 2010 at 21:45
  • 2
    There's no other answer. You can't really say you know what you're doing until you've written a non-trivial pile of code and stuck with it through a few product iterations with the business guys + the customers. You don't /really/ know how good your code is until it's time to make it change to meet new requirements.
    – blucz
    Sep 12, 2010 at 22:27
  • 1
    Definitely the best thing I did to improve my programming was getting a job.
    – Matt Ellen
    Sep 13, 2010 at 15:25
  • 1
    My guess is that the question implied "besides programming"...
    – UncleZeiv
    Sep 13, 2010 at 15:57

I think the most important thing you can do is make a conscious effort to improve. There's no single silver bullet, you have to keep looking for new sources of information, new experiences, and more practice.

And the second most important thing, think about what you're doing, why you're doing it, and how you can do it better. Same thing with previous projects. Look back at what you've done, and how you might do it differently now. Think about what could have been done better, or where you could still improve on it.

I see two great examples of this at work every day. I have one coworker who loves to learn, and wants to be the best developer he can. He's uses any downtime to read blogs, read books, discuss programming techniques, and ask tons of questions. He's also very noticeably improved in just the past year. Another coworker does his job, and does it fairly well. But that's all he does. He sticks with what he knows, doesn't make much effort to improve, doesn't work on any projects outside of his existing ones, and after 4 years, he has the exact same skill set and programming ability that he had when I met him.

  • 7
    And he probably has less skill because some of his knowledge became obsolete..
    – Jonta
    Nov 20, 2008 at 14:14

Many people have suggested writing code. I'd have to say that reading other people's code is much more beneficial.

  • 11
    a mix of the two is actually what works best for me; reading other people's code and refactoring it to make it more readable is a great exercise
    – Manrico Corazzi
    Sep 17, 2008 at 7:23
  • Reading good code of course... and understanding it. And modifying it, or writing tests for it.
    – phjr
    Sep 17, 2008 at 19:36
  • 4
    Reading code is interessting, but it doesn't really get under your skin until you actually do it.
    – tovare
    Sep 17, 2008 at 19:38
  • You must DO it to learn it. It's like riding a bicycle...
    – user1249
    Nov 21, 2009 at 9:16

Pair-programmed with very diverse and opinionated people

  • The only "experience" with pair programming I have are the times I have to help out fellow colleagues. I program much happier when there is another person there with me to discuss the problems I face and how I will solve them.
    – user6147
    Feb 6, 2011 at 0:09

The basic things that helped me as a programmer:

  • Learned Touch Typing.
  • Learned to overcome shyness and ask questions.

Typing for a programmer is essential. Everyone has had a "programmer" coworker who typed using exactly two fingers and had to look at the keyboard for everything. Not fun. Learning to touch type give a huge boost to your productivity as a programmer.

And if you don't ask, no one is gonna tell you.

  • 15
    Touch Typing is the most important skill. The greatest crimes in programming have been committed by those trying to save a few keystrokes.
    – James Curran
    Sep 23, 2008 at 16:45
  • 5
    This beats all the other answers, in my opinion. Typing saves tons of time, which means you can spend more time entering code and trying it out. It means you can type in the examples in a book instead of just nodding your head, moving on, and forgetting. Trying to be a programmer with hunt-and-peck is like trying to be a concert pianist by tickling the ivories with your feet.
    – Kyralessa
    Aug 26, 2009 at 18:22
  • 2
    I have seen people hit 15 up arrows to recover a 2 character command. Pretty sad. It's like some kids without an IDE... completely incompetent.
    – xcramps
    Sep 2, 2009 at 16:09
  • 7
    To be contrary here, I never learned to touch type. I tried learning once, but immediately started getting pain in my wrists, resting them on the desk to assume the proper hand positions was putting pressure on the all-important carpal tunnel. So I figure my pick typing at least has some ergonomic advantages. And I've been doing it for so long, I only glance intermittently at the keyboard, so no real productivity loss. Most of my time is not spent entering chars anyway, it's spent reading code and figuring out how to best solve the problems as they come.
    – Eloff
    Nov 12, 2009 at 2:39
  • 2
    The hand positions are not important - the important thing is that you can type without having to look. On my laptop I do not rest my wrists.
    – user1249
    Nov 21, 2009 at 9:19

Contributing to/participating in open-source projects was by far the biggest thing for me.


You can read all the books, code, and open source projects you like, but you need to understand the end-user aspect of software development. You need to step out of the echo chamber. So I'll address a couple non-technical points that will help your technical career.

  1. Step away from the keyboard and interact with the end-user and see, through their eyes, how they use the software. End users are typically not technical, so they see software as a magical piece of work, while you see software as a logical set of steps. The two worlds are completely different. So what seems easy and logical to you may seem cryptic and intimidating to others.

  2. Test, test, test. A lot of the software I've seen in large corporations use test cases. Hell, they use JUnit, xUnit, and all the other unit testing languages out there. But the problem I've seen is that most programmers never see what their software looks like in Production. Learn how users (or systems, if these are batch jobs) interact with your application, library, or interface to find out what kind of abhorrent information they throw at it. This will help you generate good test cases and stop assuming your program will always be fed the correct set of data.

  • True. You could test your (till now) final version by letting a bunch of people you know to be non-technical try it, and hear their comments on it (being sure to pick ones that won't say "It's good!", because this oviously doesn't help you in the slightest.)
    – Jonta
    Nov 20, 2008 at 15:18

Learned Scheme.

  • Yup, that was the big one for me too. Also significant were touch typing and pair programming.
    – Anonymous
    Jan 12, 2010 at 22:08

Writing code and lots of it.

  • We all start writing crappy code. If you write enough and you work at it you will get better. Code reviews help, but the best way is to review your own code.
    – Scott Rosenbaum
    Sep 16, 2008 at 20:44
  • Reading code and lots of it.
    – Stefan
    Oct 25, 2008 at 15:46
  • 3
    Reading and writing lots of code... Open source is such a boon to us ;)
    – Oded
    Jan 11, 2009 at 17:13

Learning regular expressions .

  • Just did this four months ago when I started to teach myself perl! My ability to use vim and unix in general sky rocketed! Amazing. May 20, 2010 at 20:18
  • Regular expressions aren't just useful, they also get you to think in a different way. Jun 17, 2010 at 6:10
  • +1. Completely agree. I am surprised to make people surprised quite often doing quite basic things in vi, sed or grep.
    – Valentin Heinitz
    Jan 11, 2011 at 21:55

Competing in TopCoder Algorithm contests.

  • 14
    I find TopCoder a little problematic. OK, it makes you better at thinking about algorithms, but you are forced to work with bad style (all code in one class) and under time pressure, so you probably won't comment and test. Perhaps Project Euler is the better choice.
    – hstoerr
    Dec 10, 2008 at 16:12
  • 3
    You're not forced to work with bad style; you can have as many classes as you like. Also, you had better test if you want to pass consistently, since a solution that fails a single edge case gets zero points.
    – mquander
    Feb 13, 2009 at 19:39
  • 2
    @hstoerr - not to mention the fact that competitors are rewarded for making their code difficult to read (their solution is harder to challenge) May 18, 2010 at 14:27
  • 7
    (sorry if this sounds offensive) I find people who don't like Topcoder (or other similar contests) try to invent reasons why doing them will make you a terrible programmer. Its ok if you don't like them. But making up spurious reasons is IMHO not helpful. No serious contestant at TC intentionally obfuscate code (it is actually grounds for disqualification if caught). I see lots of people who don't compete write bad code all the time. Algorithm contests do not aim to teach good coding habits (learn that from somewhere else), rather they aim to teach/develop something much deeper.
    – MAK
    Nov 3, 2010 at 12:45
  • 2
    TopCoder is way to show yourself how much better you could become.
    – Thomas Ahle
    Feb 6, 2011 at 2:07

Go all out: create your own project, your milestones, your resources, dependencies, requirements, and test plan. It will force you not only to improve your programming skills to operate within specific parameters, but will also serve to highlight exactly where you most need to improve. Make regular updates about your progress, whether through a blog or more formal project updates, so that you can see exactly where you've been and where you hope to go.


Quit my last job.

  • 2
    me too! (need some more chars...)
    – synhershko
    Sep 28, 2010 at 8:50
  • 6
    If you would tell us why, this might even be an answer. ;-)
    – hstoerr
    Sep 28, 2010 at 10:45
  • 2
    Supporting project that was made with inhouse framework (based on EJB2) wasn't my idea of fun. No new stuff, just old crap. And perspective in new job aren't better. :(
    – mihn
    Sep 28, 2010 at 17:57
  • Been there, done that.
    – Allbite
    Sep 29, 2010 at 6:05
  • +1 Good luck landing a job that isn't a dead end. Sep 29, 2010 at 7:08

I think constantly questioning what you are doing is the biggest thing. Never think that your code is perfect, always strive to improve it.

It seems like I've had 2 or 3 times when I thought my code was perfect, then realized I had a long way to go.

I guess the biggest thing was when I started seeing my code itself as consumed by other programmers and not a machine. It's easy to write code your machine can process, but it's tough writing DRY, understandable code.

And I don't mean just understanding "What does this line do", I mean making it trivial to figure out "How does this class fit in with all the other classes" while making the classes interface so well-formed that it's virtually impossible to misuse it.


They say that 70% of good code is error checking and handling. When I started programming that way, my code got a lot better. Thinking about what can go wrong and then handling it right away has made a huge difference. It feels like doing all that checking is just getting in the way of getting the code up and running, but it shortens the time from start to finish by a factor of 2 to 4.

Just who are these people "they" and where do "they" live?


My coding skill improved a lot when I started wondering before implementing something how am I going to document this thing.

"Thing" here should have all the possible granularity. From the method to the whole product. For instance at the method level it prevents adding a method in the API that doesn't fit, or is unclear, before actually writing it. And if I really need to implement a method I cannot document (easily), it's a sign there is a design problem somewhere...

Automatically, the attitude "if I can't explain it, I don't write it" filters out bad code and conversely once I know how to document correctly a thing, it becomes simpler and cleaner to implement.


Constantly learn and practice what you learn.

By means of:

  1. Personal Projects: Ever since I started programming I have been doing personal projects. Ranging from little games, image processing, steganography, implementing file type specifications, implementing various protocols from scratch, or implementing various programs over time.

  2. Reading books: I decided to read and follow through various books in my spare time. There are a lot of well written books by experts just sitting around waiting to be read. The depth you can get from a book is unmatched by for example reading various forum posts.

  • 10
    +1 for mentioning books. A lot of experience is not worth much if it's all spent doing things the wrong way.
    – mbillard
    Sep 13, 2010 at 4:53

This is usually my chronological order of learning any new technology:

  1. Regularly read good blogs (Atwood, Martin Fowler, etc.), Keep up-to-date with technology news, Follow stuff about interesting new technology. These steps will let me decide if I find anything interesting to further explore.

  2. Read the right book or any other resource to learn for your level (e.g. for beginners if you want to learn design patterns, I would suggest 'Head First Design Patterns'). I have also specific preferences for books.

  3. Roll out a toy project or two using the thing I learned. I don't worry about the usefulness of the project. My intention is just to exploit my learning. (e.g. A calculator project for OOP would be fine)

  4. I would see if I could use the stuff at work. (e.g. Though we don't use subversion at work, I use it as my local repository, I used Ruby for a task which would otherwise be too monotonous, and time consuming)

  5. This is the best part which I think most people miss out. Knowledge sharing sessions.Give a session or two to fellow team members for example. I believe teaching is one of the best ways to really learn the technology. I guarantee your level of understanding of the technology will become multi-fold, whether you audience gets it or not. :-)


Hack on some open source project for a few months; the larger the better. When you're interacting with some highly opinionated, geographically diverse people who don't know you, you can't help but learn from your mistakes far faster - I think it's a certain embarassment factor. Plus, if you identify one or two really smart people, then you can glean valuable insight, if not pure knowledge, from them.

2 3 4 5

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