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.

Edit: Wow - what great answers! Keep 'em coming people!!!

+39  A: 

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
Reading code and lots of it.
Reading and writing lots of code... Open source is such a boon to us ;)
+143  A: 

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.

I agree. Getting my hands dirty in a project has been probably the biggest contributor to my improvement. ; )
Mike Grace
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.
+54  A: 

Pair-programmed with very diverse and opinionated people

Heath Borders
+80  A: 

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

Grant Johnson
I second that... I can hardly even read some of my old stuff.
When I go over old stuff of mine I get nearly-irresistible urges to delete the whole file. Sometimes the whole directory.
Christopher Mahan
+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.
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
Carson Myers
@Christopher Mahan: And on really bad occasions, the entire volume.
@ThanatosOne word: re-image.
Christopher Mahan

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.

Andrew Jahn
+4  A: 

Writing code, I tend to read too many books,it's good to know the theory but the practice is really where you can become a master.

+58  A: 

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

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
Reading good code of course... and understanding it. And modifying it, or writing tests for it.
Reading code is interessting, but it doesn't really get under your skin until you actually do it.
You must DO it to learn it. It's like riding a bicycle...
Thorbjørn Ravn Andersen
+34  A: 

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.

+27  A: 

Competing in TopCoder Algorithm contests.

Paul Reiners
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.
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.
@hstoerr - not to mention the fact that competitors are rewarded for making their code difficult to read (their solution is harder to challenge)
Shane Fulmer
I'm really late here, but that's not true at all. Wrong answers are wrong answers no matter if they get challenged or not. They are still worth 0 points, even if someone doesn't challenge them.
+34  A: 

Learned Scheme.

Yup, that was the big one for me too. Also significant were touch typing and pair programming.
+71  A: 

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.

Christopher Cashell
And he probably has less skill because some of his knowledge became obsolete..

Finally starting to work again in the field after excruciating years at college, at the Swiss Federal Institute of Technology in Zurich (ETHZ). I had worked as a web developer / graphic designer for a large company during the dot com boom after high school, prior to college and the mandatory army service here, and missed these days while my brain was being hammered with endless lessons on Eiffel, Prolog, compiler design, algebraic set theory etc...

+2  A: 

I enjoy picking up any language that I can get my hands on. Then I can decide what the language would best be applied to and throw it in my "toolbox". I really like being able to pick the right tool for the job.

+13  A: 

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.

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?
Thorbjørn Ravn Andersen
+180  A: 

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.

AND one of the best ways to learn what NOT to do :)
You can see how they do something. Maybe they do it in a better way than you?
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.
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.
So true, that was the hardest part of my job for a long time.
whats neeed of reading documentation . they sucks
+1 for reading others code : Agreed
+1 Sydius. I recently had to work on an old project, looking like a real jungle. I can't say I've learn a lot of good programming practices reading it's code, but I definitively learned a lot of bad practices to avoid at all cost, as well as the value of comments!

I think you will learn a lot by reading books and taking a look on the code of open source projects.

Alexandre Victoor
+519  A: 

In no specific order...

  • 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

  • working with people far smarter than I

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

  • Disagreeing with everything Joel says. ;)

Definitely agree with actively seeking out the smartest people. Conversation floats *everyone's boats*
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.
I second the "smarter people" advice
Manrico Corazzi
+1 for "working with people far smarter than I"
Cristian Ciupitu
Disagreeing with everything Joel says, while nevertheless reading it all and finding it extremely thought-provoking...
Bill Michell
Bill- ayup. He never ceases to get a reaction from me... I love to hate him, and hate to love him.
another +1 for working with smarter people
what if there are no smareter people around? i mean i know i could improve in a lot of things, just there are nobody around who i could learn from :/
@Zizzencs - that's a good question and I have a simple answer (which is, admittedly, nerve wracking and difficult to implement): Get a new job. We're hiring, if you're interested. ;) (
"Working with people far smarter than I"... I'm still amazed at what I'm learning.
Matt Hanson
why disagree with joel?
Click Upvote
@Java: Because he's there? ;-)
Peter K.
I would like to work with smarter people, but I find it hard in my circles. +1
Martinho Fernandes
Watch how smarter people handle mistakes - that's when I learn the most from them
Mike Robinson
+1 for all of the points except for the Joel hate.
Jens Roland
I don't think it's wise to ignore everything Joel said, or for anyone for that matter. You should listen, then analyze, then make your own judgment.
Hao Wooi Lim
@Hao Wooi Lim: who was ignoring Joel?
Michael Myers
Observe and learn :D
Angkor Wat
if this is a list in no particular order, shouldn't it be an unordered list rather than an ordered one? :P
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.
Cristián Romo
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.
Heh, wasn't the question the SINGLE most effective thing you've done? OMG -1 FOR NOT PAYING ATTENTION THE QUESTION!!!! ;)
Hooray Im Helping
+0.5 for all of the points and +0.5 for "Disagreeing with everything Joel says"
+1 for Pair Programming, doing consulting work also made me learn a TON about very weird issues and how things are used in different ways, ways that are wrong sometimes, and ways that are clever...
What Joel does is to frequently play devils advocate which makes people question their current thinking. This can only be a good thing and is what makes him so interesting and helpful to follow.
Russell Giddings
+1 Sometimes you can't agree with everyting Joel says! You MUST have your own opinion!
+3  A: 

Working as a programming lab teaching assistant -- having to teach another person to code, particularly through example, really made a big difference in the quality of the code I wrote.

Joe Corkery
+1  A: 

I believe that reading and experience are the most important in improving.

When I first start a language, I like to read a couple quick start tutorials, then I work with it a bit. After I have a better feel for the language, I read a more complete book cover to cover. In order to use whatever language you choose to it's full potential, you need to know everything about the language, including it's strengths and weaknesses.

Reading books about general programming has helped me out as well. A lot of the most important concepts of programming are not language specific. A book about a single language doesn't cover the same areas since learning a language and learning to program are different things.

+3  A: 

Ensured that no matter what role I was in (e.g., currently software architect of a large project), I would be writing code. I've seen too many former developers stop coding entirely and they went up the technical or management hierarchy, and gradually lose touch with the reality of building software. The only solution to that is to keep writing code.

Learning new languages, writing in different environments, doing different kinds of applications... as much diversity as possible helps to round out your programming skills.

But the bottom line is that the only way to get better at something is practise, and to continually challenge yourself with projects of ever-increasing difficulty.

Jason Etheridge
+1  A: 

Used them.

Seriously though, I often find myself repeatedly implementing the same sort of functionality in new ways. Each is an adventure that always raises new questions. Answering those questions allows my skills to grow.

+2  A: 

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

+127  A: 

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.

Bill the Lizard
I can vouch for that.
John Calsbeek
how did you get into that?
Martin Clarke
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.
Bill the Lizard
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."
Too True. Teaching photography made me a better photographer. Not much of a coder tho :(
CAD bloke
Yes, it forces you to go over the basics again and again. Not particular for coding, but for any profession.
mutuo ista fiunt, et homines dum docent discunt - Seneca
I am totally with this one. i have learned a whole lot too when tutoring, especially stuff i wasnt sure about before
Steve Obbayi
+42  A: 

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

+1  A: 

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


The most effective thing I did to improve my programming skills was while I was in college I learned to teach myself any subject and not to rely on an instructor or a course to learn somthing.

Lost in Alabama
+3  A: 

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.

Nice. an everquest reference. So what are you then a druid?
Brian G
don't waste time playing MMO spent it learning instead could be a valuable advice to ;)
Rob Williams
@Aston: You have gotten better at answering! (255)
I'd guess that either way can work.
@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".
I disagree. Consider product development. I find the PC software, embedded software, electronics design, and mechanical work are usually done with minimal communications between groups after an initial requirements process. Everybody does their part of the puzzle with few chances to do cross-disciplinary improvements... they wouldn't even occur to a specialist. Being a generalist lets you make more optimal overall designs. A PC guy may make an app that uses 100% CPU handling small data packets, instead of upgrading embedded memory/proc/going to FPGA to allow the use of bigger packets.
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.
I had to learn a new language for every job so far. At my second job, I was hired as a Java Web developer because I knew C++, and had some Java in university. I learned XSLT, Javascript and CSS on the job. Then I got a job as Ruby programmer because I had Java and Web experience. Recently I got a Groovy/Grails job because of my jQuery experience. It helps to know the differences between languages, frameworks and tools. Sure, if I needed serious database optimisation, I'd get a specialist for that, but for general programming, allrounders are often better.
@mcv: just wondering: why would they hire, for example, a Java developer with Web experience to program in Ruby? Wouldn't they just straight out hire a Ruby guy with web experience? I find it strange you keep getting jobs that you didn't have the required skills for (unless they are entry-level positions?)
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.

The obvious answer is:

Learned my first programming language.

This answer doesn't make any sense.
+1  A: 

Learn another programming language, possibly one that has a fundamentally different approach. Scheme, D, Scala, JavaScript. It will open up your mind at what can be done with each of them, even if you do not get to any level of procifiency.

+13  A: 

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.


Get your feet wet doing some basic "hello world" programs. Read programming books, read blogs, get to an intermediate level and do a lot of programming in different things, keep yourself challenged, pair program as often as possible, contribute to an open source project. Next, read "code-complete" Write more code, start to write good code.

Chris Ballance

Reading what other people had to say about good practices. Writing more code will only get you so far.

Marc Gear
+24  A: 

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.

Bill K

I switched to an editor with syntax highlighting, contextual autocomplete ("intellisense", etc), and automatic indentation. This has had a greater positive effect on the efficiency of my code production and the readability and maintainability of my code than any other single thing that I have done or learned.

+3  A: 

Answer questions on StackOverflow, of course!

Loren Segal

To learn how to ride a bike you have to ride the bike. To learn how to program you have to program. The more you program the better you become IF... if you always try to improve yourself and you always strive to create good code. And this brings us to what good code is and what good programmers are. There are so many answers to this. But some basic guidelines are: clarity, simplicity, generalization. The reality is practice alone doesn't make perfect. Perfect practice makes perfect. You need to code and also have your code reviewed by some other eyes. You need to read code written by others - good code and bad code. You need to understand how code rots and good code yesterdays becomes mushy bad smelling code tomorrow when the conditions, requirements, constraints change. It seems I can go on and on forever... Okay the gist is code a lot in various areas with various languages and think critically about it while exposing your code to others' opinions.

+1  A: 

I read books that have nothing to do with programming and everything to do with what my product will be used for.


Working in the team which used Extreme Programming
Especially the following aspects of this approach

  • Pair programming – the best way to learn biggest and smallest things from your fellow programmers that improve your programming skills, from advanced programming methods to using editor shortcuts that you would never be aware of otherwise
  • Continuous Testing
  • Writing self explanatory code that does not require comments

Find something outside of work that you can develop. I'm just starting to jquery and there are heaps of JavaScripts people have written that simplify tasks. I've been looking at these javascript files and learning how they work. I broad answer I was trying to get at was to use other people's work and incorporate it into your own (following copyright laws) Then understand how they they do. Good hunting.


As of c++: strict const correct code.

+1  A: 

Being open to languages or approaches that were outside my comfort zone. I would say another major player was sharing what I learned with others. When you have to explain why, it pushes you to be certain you know it.

John Kellar

Typically, I didn't really get into languages until I dived in and started actually working with the code -- preferably, other people's code, so I could see how things actually fit together.

Also, from the first day in college classes, legibility was emphasized almost over functionality. Write code you can make sense of the next day. :-)


I found reading Code Complete 2 by Steve McConnell from cover to cover (and actually trying to follow most of his advice) has drastically improved my programming skills, especially since I don't get the benefit of working with other programmers in a large corporate environment.

Also, practicing good design (explained in the book) and analyzing other people's design is important to moving in the right direction, skills-wise.

+101  A: 
  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
Very good suggestion to learn something halfway familiar.
+1 for pet project
Leigh Shayler

I think the single most effective thing I've done is to force myself to use various languages and alternative tools on projects based on what fits best. IOW I tried to look at the capabilities of the language to see if it is a better fit than one of my standard choices. This has forced me to learn and use various tools based on their individual merits.

I try VERY hard to never stuff square pegs into round holes when it comes to my programming style also. We have many languages available to use because there are many different ways of doing things. The more I can understand about other styles the better!

+1  A: 

lol. typing in code from magazine articles (yup, back in the day we used to do that for full-page Amstrad and Atom code listings). It may be like rote learning, but it got me from nothing to something, everything I've done since is incremental to that initial bump.


One way to improve programming skills is to learn different business domains and how software is used to solve problems in those domains. For example, if you only work on business web applications, you may gain substantial knowledge of HTML, CSS, and relational databases, but not necessarily ever have an opportunity to master concepts like concurrency or 3D graphics programming.


Write a non-trivial app in multiple languages/systems. I've written a betting pool app in VB6, common lisp, java/jsp, java/spring/struts, rails, grails and django. I am now writing it in ruby/cocoa OSX

Each implementation is different. And I've learned how the systems differ from each other.

+400  A: 

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.

Craig Trader
"Jack of all trades, master of none, though often better than a master of one." -Adam Savage
I completely agree with this. Learning lots and lots of different and similar things will teach you knowledge that is worth something for a lot of time. For example knowing how values might be handled in a language will probably help one learning new languages forever.
I would call this the Professor Challenger principle.
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
Couldn't agree with you more! My ADD has kept me from focusing on anything long enough to specialize and it is really the defining characteristic of my career!
Chris Boran
Very insightfull, i would +1 today if i had any votes left for people smarter than me
hmm, actually i was deciding whether to specialize in something or learn and explore various technologies eg. Zend Framework vs ASP.NET MVC vs Ruby on Rails, Flash vs Flex vs Silverlight. and i guess from here i can deduce that to a certain extend i shld generalize... but the hard part will be to take time off... and that also means i lose some chance to be even better in what i am currently doing
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.
Craig Trader
"Specialization is for insects." - Heinlein
Kelly French
Where is your "Generalist" badge? ^^
Arnis L.
What was the database you worked with that lost out? I still do a large amount of work with a 1990s product (R:Base) that has become very much a niche product, notwithstanding that it's still manufactured and updated. Also, I heard somewhere that the decay rate of software knowledge is 20% per year.
Larry Lustig
Pick -- a combination OS and database. Also know as Universe or UniData (when hosted on Unix) or Information (when hosted on Pr1mos).
Craig Trader
I want to be Jack of all trades and at least master of some .. :)
Mahesh Velaga
@Arnis, when they implement the "Generalist" badge, I'll be there.
Craig Trader
Someone said something like - a specialist is someone who knows more and more about less and less, until person knows everything about nothing.
A generalist is someone who knows less and less about more and more until person knows everything about nothing.
this is a good ideal until you try to get hired somewhere with no tangible experience
Dan Beam
Getting the first job is always hard, but if your skillset is broad and flexible, then you've got more opportunities that someone who only knows a single skill. The hard part is in selling yourself, and then delivering on what you're selling.Once you've got that first job, then you'll be getting tangible experience, and if you really put the effort in to learn new things (above and beyond the day-to-day needs of the job) then the effort will pay for itself.
Craig Trader
Be "The Jack of all trades" but first master One
@n10i When does mastery start? I therefore disagree. Be good enough for the current task at what you do, then move on to the next thing.
I prefer to be "master of one and jack of all" :) although i haven't succeeded at being "master of one" or even at "jack of all" for that matter
+1  A: 

Stopped writing procedural code and started creating objects.

+1  A: 

Teach the concepts to someone else. Then you quickly realise which parts you don't truly understand.

Ross A
+1  A: 

Coming to the realization that you can't rely on your company or the 8 hours you spend "at work" to keep your skill set up. Being a better developer is an ongoing process that never stops.

+1  A: 

Told my boss "yeah I can fix that for you, give me two days." Then had to learn a new language to do it.

Lincoln Johnson
+1  A: 

Taking part in code reviews. This really combines the idea of reading other people's code with having to think about presenting your own. Seeing other people's mistakes is just as valuable as seeing their whizzy clever stuff, and the pressure of having other people see your code really concentrates your mind on making your code as comprehensible as possible.

I now think about the ease of maintenance of code as being WAAAY more important than its efficiency, and I choose an easily comprehensible design over a super-efficient but incomprehensible one every single time. Of course it helps that the poor maintenance programmer figuring it out may well turn out to be me :-)

Bob Moore

Working with a diverse set of more experienced and intelligent programmers.

People who say 'just write code' are being short sighted. I have seen many a project where someone 'just wrote code'. That doesn't give anyone insight to good habits and practical programming, nor does it help develop solid skills in the secondary parts of coding. Specs, documentation, clearly getting ideas across.

  1. Reading the source of whatever (open-source) software is brilliant and important in your area of expertise.

  2. Learning and appreciating different programming paradigms (i.e. OO isn't the answer to everything)

  3. Writing libraries/components rather than monolithic 'systems', learning the value of interface design, documentation, conceptual simplicity.

+1  A: 

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.

+1  A: 

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

+1  A: 

Wrote code on my own time, just for the fun of it. Not just any code, but deliberately concentrating on low-level reusable objects and modeling the relationships between them.

+21  A: 

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.

+1  A: 

Math degree.

+2  A: 

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.

+44  A: 

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.)
+1  A: 

Program all you can and associate with people that are smarter than you who program.

Joe Skora

Programming with at least one other (experienced) person, ideally in an Extreme Programming environment. Debating alternative approaches will assist in hashing out the pro's and con's of each.

+1  A: 

Learning different coding paradigms can really open your mind up to a higher level of thought. Looking at your standard diagramming vs the COBOL VTOC for example. Reading the Extreme Programming tenants. Actually trying to do a program with a top down programming method, then a bottoms up method.

Understanding your standard OO theories is helpfull - Overloading, Inheritance, Polymorphism, etc.

I used to think, before I learned so many languages, that if I only learned enough languages that would make me a great programmer, because every language has something special - Pascal has set notation, COBOL has extrodinarily efficient memory allocation for multidimensional arrays, BASIC is... basic. But chances are that simply learning a small set of languages that are radically different, like (COBOL, C++, and LISP) will be an improvement. I cannot verify that though.

Knowing that every language is just syntax - especially if your not going to take the time to learn what a language is really good at.

Digesting the grim reality that documentation really does matter.


Write lots of code as many already have written here.

But, write so much that you don't want to write so much more, get lazy basically, the first of the three great virtues.

"Brevity is the soul of wit" -- Shakespeare


I saw a huge improvement after I started learning how others (best programmers) code. One of the things I did is started watching "How do I" videos by the experts/gurus of any technology I am interested in.

I see great benefit in Learning Videos compared to reading a book. Not to discount the fact that reading books is a great way too. But videos are more interactive, quick and make a great visual impression (that is if the videos are good)

Tech Podcasts, dnrtv are my other favorites. Read this SO thread.

+11  A: 

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.

+1  A: 

There is nothing that will do more for coding skill than writing code. I would go so far as to say there is limited utility to be gained from anything that does not directly involve crafting code. If you are fortunate enough to work in a job where you are not constantly hammered by deadlines, stepping back and working through your section of the project with another programmer then doing the same with their section of code will do more for your programming skill and understanding of how to make engineering decisions than ten books [unless those books have Stroustrup, McConnell, or the likes on their spines].

.. the same could easily be said for software engineering students. Be brave, let others read your code and read theirs. Constantly be working. You will be much better for it.

+8  A: 

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


I always have a list of "small" project in my head. Every time I think of a "there oughta be..." I file it away for future use. Then, any time I come across a technology that looks interesting and I want to play with, I compare its features against my project list. If one seems like a good fit, I'm off to the races.

This allows me to always have something more practical than "Hello, World!" to work towards.

+72  A: 

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.

I gotta vote you up just for bringing back wonderful memories! Maybe I even teared up a little :)
Charlie Flowers
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
Ah, the 6502, brings back great memories. I learned so much with assembler on this chip.
Mike Nelson
EVERY student of programming should have in-depth exposure to assembler early in their education!
I did the same thing as a youngster. It really taught how computers work, moreso than a high-level language ever can.
CAD bloke

Not believing every tutorial I've ever read. Being critical of "good" code and questioning "bad" code.

Learning to think more object minded, getting into custom collections.

Most of all, the greatest things I think you can possibly do is:

  • love your craft and surround yourself with the kind of programmers you would like to be.
  • Never stop re-educating yourself and never think your way is the very best way.
  • There is and always will come, a better more effective way, and a lot of times you will just be flat wrong in the first place.
  • Digging through libraries and tinkering around with methods and functions just to see what they can do.
Peter GA.
+1  A: 

Switching from a pseudo OO language to a fully OO language. It changed how I look at things.

+1  A: 

I found that when in the initial phases of my career, moving around often helped tremendously. This forces you to expose yourself to different ways of doings things. I've interviewed people twice the seniority of myself that have spent the last 10 years at the same company and was surprised by how little they've evolved since college with respect to their programming abilities. You can easily surprise yourself at how differently people do things when you move to a different company and how much better (or worse) their approaches are. Point being, you want to expose yourself to as many different ways of doing things as possible, especially while you have the luxury and the opportunity to move around often.

+1  A: 

Learning FORTH


Actually programming for a purpose. Once I started working and writing programs that would actually be used by users and not just handed in for a grade I started to get a better understanding of the impact my programs had. I was able see the big picture.


Let others review my code and criticize it. I regret didn't do enough of this.

+24  A: 

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?

Harold Bamford

Doing fundamental computer science and learning that it's all the same. It all comes down to the same concepts and it's all built on logic and turing machines, and you can do it all the same.

Applying OOP to Assembly and Digital Logic is entertaining...


When I began to write code that looked "beautiful" and very clean, my programs started to work almost at first run, with very few bugs. If there are bugs, they tend to be very easy to find.

So I simply look for simplicity, cleanness, and beauty. :-)

Don't ever write code in a "clever" or complex way. Write as clean and readable as possible, and the programs just work and are easily maintainable.


Reading good books like Effective C++. Mind you, I had already programmed in C++ for several years, but it wasn't until I started reading good C++ and other programming books that I felt a jump in knowledge, which translated into becoming a better programmer.


Doing lots of code reviews with the principle that I wasn't done with the review until I found at least one piece to critique.

Incidentally, in many cases to be able to do such a code review I needed to sit next to the original author and ask them to explain the code to me line by line until I understood it. If you happen to be lucky enough to be asked to review code from great programmers, you will quickly ramp up your skills too.


For language proficiency, digging though the core API and writing code that utilizes each method/class. This has 2 benefits:

  1. You learn the API, so you can stop reinventing the wheel.
  2. More importantly, you get a good grasp of the major idioms of the language. This keeps your code clean and readable. Like when you finally stop trying to code procedurally in Lisp.

reading, working with others, and general get in and play with it :)


Anything that encourages you to write more code. I'm currently working through Project Euler to improve my skills, but I've also learnt a lot in the last year, just through looking at the codebase I'm dealing with at work. Also, reading more books doesn't hurt, although it's best to focus on Software Engineering ones until you know what languages you actually want to program in.


Python Challenge

+4  A: 

Write code-generation software. Create a simple database with a few related tables. Then write a web interface to interact with it using whatever tools you can find. Then, using the same language, write software that will write what you have just written.

You'll see that a well designed relational database, with well thought out field definitions (type, length, nullable, default, etc), contains all the information your code generation software will need. Write a code generator to generate your data abstraction layer. Then write one to create a web interface (list view, add form, edit form, etc).

The more you write, the further you realize you can go. It gets addictive and you get better...


Writing code not only at my job but also at home. This has given me the time I don't have at work to find out very interesting and useful things.


Painfully copying the printed samples from computer magazines in the 1980's. Line by line. Only to figure out there was an error somewhere.

In general, reading other peoples' samples and modifying them; finding bugs in them; extrapolating from them.


Moving from the team I was lead programmer in to a new team which deal with a widely different technology I know nothing about.

And then doing it again after 2 years.


Wrote a Scheme compiler in C. Not only did I have to learn Scheme inside and out, but I learned all about compilers, how code is executed on hardware, how garbage collectors work, among other things.

Josh Segall

As a lot of others have said, write A LOT of code, and ensure that you learn languages of a few different styles. By that, I mean don't limit yourself to languages that are similar. For example, if you know Java then learning C# will not be too difficult because there are quite a few similarities (automatic garbage collection, etc) but learning c++ after Java or C# will improve your skills much more because if forces you to think about your app differently. Also, learn to use the correct tool for the job. There is no point writing a simple file transform in Java when you can do the same thing with half of the code in Perl or with standard tools like awk

Doing things that were a challenge for me helped the most


In my experience:

  • Practice heavy test-driven development (TDD) until you feel comfortable writing tests before actual implementation. It will make you a better programmer.
  • Have pet-projects on the side or simply participate in open-source projects.
  • Try to team-up with people better than you. Observe what tools they use and how they approach problems.
  • Always find new things that keep you excited about programming. Be passionate.
  • Create. If you're in just for the money, you can forget about being a programming guru.
+1  A: 

Learning to learn from the mistakes of others.

  • Making mistakes and learning from them - One of these was writing a prototype in three weeks which 12 years later I am still maintaining, because I allowed it to go into release, instead of re-witting it correctly.
  • Doing algorithms 300 and especially order of complexity. In someways it is the bleeding obvious, but it crystallized in my mind concepts that I use everyday.
  • Going back to basics and witting code to the OS and in 'C'. (This was partly a reaction in part to putting a a prototype into production.). Makes code so much faster and more robust. I think that as the improvement in the performance of computers flattens out, this will become more important in the future. I am not a big fan of frameworks. I suspect I am in the minority here, and might post this as a question later.
  • Reading 'Code Complete'. From that the biggest thing was the layout of my code and the focus on simplicity.
David L Morris
I suggest you remove "300" since no two universities have the same course numbers. Also, this makes me wonder how much experience you have. I wish most of the comments here included a "I have N years of school/work experience".
Kimball Robinson
@k.robinson The course I did was Algorithms 300. Generically, '300' courses are at a 3rd or senior year level at University in Australia, and many (if not most) CS courses include an Algorithms 300 unit or the equivalent. Your experience may differ. There may even have been an Algorithms 100 unit, (I can't remember) which, evidently, didn't have as much impact. Answers probably didn't mention the years of experience because it wasn't asked. A better nitpick in order to chastise me, might have been: my four answers rather than the implicit single one. ;)
David L Morris
@David L Morris - I wasn't meaning to chastise you. I was just confused by the 300 because I've been to two universities in the USA, and the algorithms classes had different numbers at both. I thought I might help you improve your answer, was all. :)
Kimball Robinson
@k.robinson Thx. I wasn't quite sure how to take a response to an answer 8 pages down, from nearly two years ago. Incidentally, I should have said 3xx courses. The n00 (or n10) in Australia, are usually courses at the higher level of difficulty or at least subject purity.
David L Morris

Working on a variety of technologies and programs. The key is to continue trying new things, so I guess the ONE thing is challenging myself to do things that I have not done!

Mitchel Sellers

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.

Babak Ghahremanpour

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.


I read Effective Java by Josh Bloch. Overnight I was a better programmer.


A lot of people have said to program, and I agree. Specifically, I like to:

1) Do programming Competitions! I just did my first one this summer and it was actually pretty worthwhile (although I admit, I didn't do phenomenally). It forces you to work on interesting problems quickly. Google Code Jam is excellent for this.

2) Write algorithms I know well (sorts are awesome for this) in languages I've just picked up using the helpful features of that language to do it. It just doesn't make since to write an imperative sort in ML when the elegance comes from doing it functionally.

3) Talk to people who LOVE particular languages about WHY they love those languages. Rather than picking a side in the Perl/Python debate, I'd rather talk to a person from each side about why they like their language of choice and grab the useful bits for future reference.

4) Read Tech Blogs. You'll discover a lot about different languages by reading the blogs of the people who know about them. Of course, this applies to a lot more than programming.

Of course, these things tend to do more to make you a better programmer and may or may not help you with Software Engineering.

Alex Gartrell
+1  A: 

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.

  1. read research papers [ACM, IEEE] on topics that interest you

  2. try to solve hard problems; even if you fail, you will learn from it

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

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


Figured out my learning style (or maybe my learning disability.)

I discovered that listening to people talk is the hardest way for me to learn. So classroom lectures, podcasts and videos are the least good way for me to learn and I don't waste my time even trying them if I can help it. I'm way better at learning by reading. So I buy and read lots of books and web articles. (You know. Sort of like this site.)

Just as there is more than one way to solve a problem, there is more than one way to learn. Optimizing what works for me has been the best way for me to improve my craft.

+1  A: 

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.


I tried to apply good programming technique to a language such as TI-83+ BASIC.


Writing and knowing exactly what each command you typed do


It is easy to get caught up in coding marathons. It is critical to stand back once and a while, look at how other people have implemented similar projects.

Read books written by excellent authors. Go through books such as "C: A Programming Language", "The Perl CookBook", or any of the best for your favorite languages. Read about the problems they solve, don't look at the code samples, write them up yourself, and then compare your code with theirs. Figure out why theirs/yours is better.


Used different frameworks, IDEs, operating systems, and languages. In general, if you're not confused you're not growing. The bad thing is not to be mediocre. The bad thing is to be mediocre when you think you're great.


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.

  1. I joined developer centric communities web and physically
  2. Read/Try to read other people's code.
  3. Write code.
  4. Read read read (Blogs, podcasts, books etc.) and do do do what you've read read read.

Reading lots of books and articles..


Read more books, and write more codes.


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.


I think the biggest thing for me was when I took a step back from implementation and started looking at the bigger picture, and better understanding architecture, patterns, processes, requirements analysis etc.

+2  A: 
  1. Read. Books, Blogs, other people's code - anything you can.
  2. Program. A lot. I won't say practice makes perfect, but it certainly helps.
  3. Along with #2, keep an open mind. Be ready to accept criticism. Don't take offense; take it as a challenge. Admit and learn from your mistakes and get better.
  4. Review others' code. Figure out how other people think about problems. It can be really eye opening. Perhaps they're doing something more efficiently than you are. (or perhaps less)
  5. Challenge yourself. Take on crazy difficult projects that branch into the unknown. Try to learn something with every project you do.
  6. Tinker. Never let work/school be your only development experience. Invest time in toy projects.
Matthew Cole
+1  A: 
  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.


I'm sure this is simply reiterating previous comments:

1: Read code from numerous languages. Understand how the language handles a given situation. It may make you more enlightened in the language you are looking to become better at.

2: Teams...Debating programming practices, approaches, testing, planning, implementation, etc.

3: Use the above to focus on a smaller set of languages.

4: Never assume your 100% right, then you'll have no reason to question anything.


working with people far smarter than I

+1  A: 

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.

+10  A: 

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 an 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. Game's 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 are great sets 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.

Jeff Thompson
Write a language? Are you kidding me? Clearly you're unfamilar with the term 'opportunity cost'.
Jim G.
Wow, that wasn't very polite.
Jeff Thompson
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.

Use your computer and understand it thoroughly.
Write code for whatever you thought you can.
Read good code and learn how to write. Read bad code and learn how not to code.

+4  A: 

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
+3  A: 

I asked really smart colleagues "stupid" questions I was embarrassed to ask. As Einstein said, "If you can't explain it simply, you don't know it well enough." I have also investigated the codebase at work on my own time. You have centuries of programming experience at your fingertips if you work for a decent sized programming outfit.

+1  A: 

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.


There are many things but the following had great impact on making me a better programmer

1) During university days, I was in a continuous competition with a highly talented classmate for creating the best game/program judged by other classmates. It was like 2 small start-ups fighting for market share.

2) Reading "Deep C secrets"

3) Participating in Open Source projects where smart people can comment on your code.


When you are programming alone, it is very easy to assume that the things that come easiest to you or which seem most obvious are therefore the best. However, when you are in active contact with a group of knowledgeable others (especially ones that have more experience than yourself) you will probably find many problems that you never considered, and solutions to them that might not have occurred to you either. It is much better to learn from someone else's experience than to make your own mistakes and by doing so screw up an important project (of your own or of your employer's). If you can learn these things from your peers before you are ever confronted with them yourself, you can avoid many early missteps that catch most programmers unaware. It is possible to become a programmer with a junior amount of experience but a senior's understanding of software development if you pay enough attention to what other more experienced people are doing.

Probably the most useful thing that I did was to spend a few years reading online forums such as comp.lang.c, comp.lang.c++, and regularly (on a daily or at least weekly basis), and participating in forum discussions. (In the day when I actively frequented forums, most of them were on Usenet. Now, they tend to associate with specific websites and developer communities.)

In active discussion groups such as these which attract large numbers of professional developers (and in particular high-level professional developers, such as language authors and the implementors of important libraries) it is much easier to get a sense of which programming techniques are considered useful versus discouraged, and which programming languages, tools and libraries are coming into favor or out of favor. Also, it's useful to pay attention to what software engineering techniques other professionals are using, ranging from version control systems to visual modeling languages to programming methodologies and so forth. Learning which areas are controversial is important too -- Watching an extended debate between two high-level experienced developers with markedly different views can be a tremendously educational experience.

You may find after a while that your favorite language or programming approach is not as universally liked as you at first believed, and you may find you are starting to consider alternatives -- that is good! That means you are starting to become more nuanced and more realistic about your beliefs (rather than just adopting the latest fad), and hopefully expanding your horizons to include different ways of doing things.

Paul Rowland
+1  A: 

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.

+1  A: 

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
+9  A: 

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.

Kent Beck
If your current work on designs ever makes it into a book, I'll buy a copy.
Tim Stewart
+3  A: 

This is very subjective, but I find that teaching a concept to other people really helps me master it myself. I think this works for a few reasons:

  1. It puts some pressure on you to really take the time to understand what you're talking about (you usually can't just Google it in the middle of a lecture).
  2. Explaining something really helps you find the gaps in your won knowledge.
  3. Just adding a social element seems to help motivate me.

Hope this helps.

Jason Morrison

Learning a new language a year has been great (Although I learned 3 languages last year alone). I still prefer C++, but knowing different ways of solving things has improved my coding skills in many ways. That and I have a series of "Katas" or small coding goals I keep trying out on my spare time, each time applying my new knowledge to them.

Robert Gould

Work with the smartest people I can and ask them questions. Don't be afraid to ask.

Someone should build a website to do that...;-)

Stuart Helwig
+1  A: 

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.


Participating several times in ICFP Programming Contest.

There is no other programming competition like that! Every time I learned a lot. Especially working in a team with people much smarter then I am.


I read K&R2 for a 2nd time. And then read it again a 3rd time.


Back in elementary, I wanted to create a fake login screen that would steal passwords from my dad's office PC. It was just a batch script that run on MS-DOS and there was nothing fancy. Then, in high school, I went on to write simple MSWord macro viruses because I found it fascinating to be able to "customize" MSWord according to my liking.

The programming skills that I learned then were just side-effects on doing something that I found fascinating.

+1  A: 

Learning vim


There is no single think you can think of to improve it. its a learned skill. it will make u better by practice. By practice i don't mean of single attribute. the most important attributes i can think of are 1. Write code 2. Pairing or collect persapactive from different ppl (activity like coding dojo - 3. code review

kiritsinh parmar

Working in pair programming with a 50+ programmer who is an expert on Smalltalk. We were programming in java, but I really learned a lot about object oriented design and debugging techniques.

Pair programming with an experienced mentor is something to be recommended, as long as we keep an open mind.

Mario Ortegón
+1  A: 

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.

+1  A: 

Learn Haskell.


Working with people who are smarter than I (not that hard) and being curious about how thy do stuff. Reading a lot helps, but you have to be able to find your own way on how to solve things.

+11  A: 

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.

Henrik Warne
The books should be required reading before you can install a compiler
Even Mien
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?!"

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

+1  A: 

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.

petr k.
+328  A: 

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.

Ville Laurikari
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!
awesome post, and the first comment hits the nail on the head as well.
Neil N
Great post, and I have witnessed the rub-off effect as well.
+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"
"never stop at the first working version"??? - when are you supposed to get the rest of your work done? :)
Ronnie Overby
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
Everyone should have a guy like Aaron. However, as you also put it, *consciousness* is crucial -- one must be open to new things and willing to learn, otherwise improvement will never happen. I'd say the desire to learn new things is the key for continuous improvement!
+1 because my name is Aaron ;)
I like stories like this. My Aaron was a guy named Andrew. I actually got back in contact with him 5 years after we parted ways, and seeing where he is now gave me another kick in the backside. Plus, i'm currently going through some old code and refactoring/beautifying it at the moment.
@Ronnie: during all the time you're now saving because you wrote quality code three months ago.
@Dan: On the one hand, there are people who come in thinking they're Aaron and trying to change everything without listening to the reasons things were previously done the way they were. On the other hand, there are people who have learned their own lessons, and are trying to continue to learn lessons. They teach, and they listen. That's what being Aaron is really about. It's always worthwhile to listen. Once you have listened and understood, you can then decide whether you should do what the n00b's suggesting, or stick with what was done before.
Why anonymous? Sounds to me like the man deserves some credit.
Logan Koester
The problem is too many people think they are "Aaron"
+1  A: 

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

+1  A: 

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.

+1  A: 

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


Working with another people was the single thing that made my skills to explode. I started learning from their failures. :)


code a lot don't be afraid to learn new things

+1  A: 

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.

Neil Burroughs
+1  A: 

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.

Scott and the Dev Team

I know most of these have been previously mentioned but I will reiterate them again as they have worked for me.

1) The most important thing is to have an interest in what you are doing. If you are interested in it you are half the way there. Nothing kills your desire to work/improve more than disinterest.

2) Find someone in your organization that is smarter/better/faster than you and absorb as much of their knowledge and expertise as you can. This applies to anyone, junior/senior/etc. Job titles are entirely meaningless as far as I am concerned. I've seen "junior" level developers who had far more expertise/knowledge than supposed senior level ones.

3) I've tried as best I can to follow my own Code of Coding. Write, Read, Analyze, Review, Discuss. Once you Write your code, Read it over. Is it maintainable? Is it commented well? Does it look like it does what it should? As part of this you need to Analyze the code. Is this the best way you could have done this? Could it be improved in any way? Make changes accordingly. Next, Review it, test it out. Does it do what it should? Does it do anything it shouldn't? Do your best to try and break your code. Once you are happy with it, Discuss your code with others. What is their take on it? Do they or Don't they agree with your decisions? Have they any other ideas on what could have been done to improve it.

4) Always be willing to learn new things and/or idea's.

+1  A: 

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


100 % unit test coverage.

Doing unit testing have really improved my programing.

But using a code coverage tool to measure the coverage of the unit test takes it to another level.

A good exicise is to take a module and try to make a 100% unit test coverage.

You might even make a friendly competition with your coworkers by taking a module each and see how can get the highest coverage.


Follow me on


Started teaching programming and program design. I was mostly clueless about OO until I taught a Freshman-level Java course and a Junior-level Software Engineering course.

Lewis Baumstark

Using my brain, instead of hammering out pointless code. Code once, code correct.

+1  A: 

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.

+1  A: 

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.


Started writing code for real. The code they have you write in school is nice, it teaches you some of the functions of the language. But, to really write code to business specs, it's different. I would say that I really didn't become a good coder until a couple years after I had to start writing stuff that other people had to maintain.


A lot of reading and learning assembly.


couple of things..

  1. Reading others code.
  2. Working with smarter people than you & learning from them...
  3. Working on variety of different platforms and different domains.

I had a keen interest in software process improvement after completing a masters degree in computer information systems, and studying about the Capability Maturity Model in one of the courses on the Software Lifecycle. Since the company where I worked was located in Pittsburgh, I attended Software Engineering Process Group meetings that were held monthly at the Software Engineering Institute. Watts Humphrey came to one of the meetings and did a presentation on Personal Software Process shortly after writing the book, and so a work buddy (Jim) bought 2 PSP books (one for him and one for me) at the CMU bookstore. We started doing the excercises together during lunch, and started applying the stuff to my work.

Completing the programming exercises along with the process material from the Introduction to the Personal Software Process book was the single most effective thing I did to improve my programming skills.

Steve Karg
+62  A: 


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

Plus, frickin', 1. I was starting to wonder where this choice was.

an open mind.

be critical at everything what has been written. and perhaps the most important thing, sometimes it's better not to develop.

we are already implementing everything while a simple pencil and paper works better.

+2  A: 


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
+1  A: 

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.


I remember getting grueling code reviews where my boss made me think about every line of code, and taught me to be critical of every line. Now I'm a paranoid sob in exchange for less buggy code.


Well... For being someone without a lot of experience (I'm fresh out of university) I still must say that what changed me the most was when I started unit testing. It made me write much better code.

+1  A: 

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.

+1  A: 

Reading Books, Megazine , google different type of scenario and go theu that code , writting code working with smart ppl who can give you good idea how to improve programming ,always keep updating your knowledge about new technology

+1  A: 

I grabbed a development site and just started churning out web sites that would just pop into my head. This helped me learn several new languages and a vast amount of technology pretty quickly.

I still buy a programming book a month to read and learn from. I have expanded my knowledge a great amount over the last year just by doing this.

+1  A: 

Maintaining other peoples code. Having to dig through 1000's of lines of undocumented, under/over designed code will do more to teach you about code structure, re-use, and documentation than any class or any amount of code writing. Being able to write clear easily understandable code is the best thing I've ever done to improve my skills.

Rob Booth
+1  A: 

Learning how to write short, understandable comments.

Gordon Bell

Being Passionate

I'm not talking about the kind of passion where you're annoying and saying, "Hey everyone look at me.... I'm passionate!"

What I'm talking about is possessing an energy that makes you want to do the tasks that everyone else shies away from. It's a sacrifice for the greater good of the company and this will get noticed... it's unavoidable.

Examples might be:

  1. Working on the build system (or being the one who spear heads it)
  2. Digging into legacy code to figure out a nasty bug
  3. Doing more QA type services that are not necessarily expected of you
  4. Etc...

When one can do these types of tasks without making a big deal out of it, it tends to go much further then if one tells everyone about all the great things one's done. All of this seems to start with passion.

Scott Saad
+1  A: 

Undoublty learning assembly (or should I say assembler, as I started coding in hexadecimal? :-)

Once you know how the processor executes code, you realize what really an "if", an "while" a "struct" and any other language construct really are, and you start to appreciate these language constructs exist. Also, once you know assembly, the speed in which you learn a new language is so fast that this for its own is worth the effort.

Just to help people realize how great is learning assembly, it's like when Neo starts to see the Matrix how it really is by the end of the movie. Someone will come and show you this "new great framework" and how it works, and you'll just say "is this just it?"


Jump into something I don't know, try to code. If I don't know how to do something, look it up, then ask questions of others. Looking to coworkers for pair programming or asking why certain things are coded the way they are helps you out by finding the history and trying to think of how to rework the way their code works.

All in all, experiment and don't be afraid to make a mistake... especially in a test environment. It's there for you to wipe out every now and then

+1  A: 

Knowing the business of software and understanding how to become profitable. You become very adept at managing clients, requirements, and quality. From a technical perspective you apply appropriate architectures, patterns, and methodologies that lend itself toward simple, pragmatic solutions.

+1  A: 

Reading Code Complete

Juan Manuel

Give trainings. You wouldn't believe how much new stuff you end up learning when the pressure of being an "expert" for a day hits :D

+48  A: 

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.

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
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.
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.
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.
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.
Thorbjørn Ravn Andersen
I still think that thinking is more important than typing. Typing is essential for writing code using verbose languages like Java, C#, etc. When I write code using language like Haskell, I find that the typing vs thinking ratio is rather low.
I'd like to point out that touch typing != home row. I personally use home row as a starting point and then let my fingers go wherever, which I can do because I know the keyboard very well. However, I've seen plenty of people touch type without even touching the home row, and that works fine for them.

1) Write code.
2) Read Code Complete.
3) Write code.
4) Keep reading and learning.
5) Write code.


personally i could not answer. However, as a group learning techniques, we've implemented weekly coding dojos and weekly lightining technical talks - be it about a particular library, language, tool, whatever is pertinent to our skillset.


I started to read and do things similar to development, but NOT development. eg

  • Joel On Software.
  • Managing Humans (Rands FTW!!).
  • photography (creative outlet which isn't software, but uses a LOT of software)
  • mountain biking (same - technical, but not development)

Worked for me :) the last two are great ways for me to work thru a problem - esp MTB.

that, and learned a new language, or atleast looked at new stuff, often. I can atleast read C#, java, VB.NET, Ruby, Python (well, getting there), Pascal, x86 ASM, Obj-C etc, even if I can't WRITE all of them well.

Nic Wise
+4  A: 

SQL - it changes your view of the world to data-centric rather than process-centric.

I don't think I realized until reading this how big a difference figuring out SQL made to my programming ability.
SQL? How about NOSQL?
+1  A: 

I learned to read other people's code.

This might seem overly simple at first, but being able to understand the subtleties in code before modifying it is a great asset. When you work on a project for a couple of years, code gets old, so you're bound to have to modify code you're not so familiar with. I too often see young programmers who have a lot of trouble understanding the big picture when going through code they didn't personally write.


Some of the effective ways to improve your programming skills

  1. Make sure you have set of good developer's blog feeds in your feed reader and make sure you browse through them atleast once a day.
  2. Listen to good podcasts.
  3. Mentor people !! (surprisingly it does improve your programming skill)
  4. Make sure you always work on a pet project apart from your normal project work.
+4  A: 

Learn Regex, as early as possible. Every tiny little string problem becomes a no-brainer later.

Do you mean this as "lean regexes so you learn more about string manipulation", in the same spirit as "learn assembly so as to learn more about your processor", or "learn regex and solve all string-related problems with regular expressions"?

A programmer needs only to solve 'unsolved problem'.

Do not reinvent wheel.


I took a developer job in a field I didn't have any particular interest in prior to being hired.

The specific issues encountered in this line of business that I had to solve changed the way I approach solving programming problems.

I think the lesson here is that I was taken out of my comfort zone and had to tackle issues I would never have had to solve in programming projects in fields I've already worked on in the past.


Take up a role where you are purely testing for a few months / or do a significant body of testing on someone elses application.

This will give you a much better perspective on what a user wants\needs\worrys about when using an application.

Apply this when you develop your own applications.

(yes I know testing is not popular/fun, but I've found that ex-testers make the best coders from the point of view of giving the customer what they want)

+31  A: 

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.
Regular expressions aren't just useful, they also get you to think in a different way.
Tikhon Jelvis

Always try to imagine what is going on inside the software I see running. What is the compiler doing? How does the app server implement that connection pool? What is the version control system doing with my file?

Then when something breaks I have somewhere to start to look for problems.

David Plumpton
+1  A: 

Taking courses. This might not be what you referred to but there have been three courses that helped me immensely.

  • AI - A course that helps learn suitable algorithms for problems you may encounter as a programmer. Don't let the title scare you. AI courses are broad which makes them easier than they sound. These courses are more practical than generic algorithm courses.

  • Programming paradigms - Courses that explores different ways to program. You should expect a lot of haskell, lisp and regexp. Beware that functional programming is like a drug that is hard to get rid of once you've mastered the wonderful world of one-liners.

  • Computer architecture - Any courses that teaches you assembler and "behind the scenes" stuff. You are then forced to learn about memory, cache, DMA, floating-point calculation and the like. Some might say that C++ must be learned to be a good programmer, but it only forces you to learn about pointers and how classes are built internally (if even that).

Daniel W

What helped me significantly which I feel is relevant was pushing myself out of my comfort zone as often as I could.

Just because you can do something doesn't necessarily mean your getting better at it. Think of it like working out in the gym only using your mind. Break a mental sweat as often as possible.


Fresh out of university I got some of my C++ (a language I thought I knew) reviewed by someone who really did know the language. He completely took it apart and spent a long time explaining why it was awful. Up until then no-one had ever criticised my code, so I thought I was pretty hot, but after that day I realised I still had it all to learn. Getting taken down a peg or ten was absolutely essential and I'm so glad it happened early in my career by someone knowledgeable enough to set me on the right path.

Since then I've always been prepared (even eager) to give up "my" way of doing something in place of a better way.

+1  A: 

Reviewed Code and let my Code get reviewed

+1  A: 

Studying the best books on our profession. (E.g. the GangOfFour book about Design Patterns). Working on projects gives you experience but there is no substitute for the good old learning.

+1  A: 

Learning C++ was the single greatest thing that has helped me in my programming life! It just makes everything else so much easier


Learned how to type!

+9  A: 


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!


creating games was the best thing I ever did. now competing on and is the best thing I am doing ;P

Abhishek Mishra
+1  A: 

Applying the Extreme Programming aphorism, DoTheSimplestThingThatCanPossiblyWork, probably improved my overall software-engineering skills more than any other single event or practice. Of course, sometimes that "simplest thing" doesn't work, but that's OK: you've learned something, with minimal investment of time and effort. Even if you hate everything else about XP, that one principle is worth the price of admission.


Understand the hardware that runs your program, understand the people that will use the program and test every day if your knowledge of both of them is up to date.


I adopted different methods. 1. Doing actual programming (especially working in diverse range of applications and languages helped) 2. Learning and reading programming/software engineering books and applying knowledge (as people often just read it) 3. Learning and modifying frameworks. 4. Learning from senior fellows (wherever they are) 4. I used to be a teacher as well so i learn quite a lot from my students and their questions. 5. Never restricted to any platform/language , so got diverse thinking and always apply my experience to use one across the board. 6. And the final "Never Stop Learningg whatever offer" ?


RTFM and practice, practice, practice!

+1  A: 

The single most effective thing? That's easy: listening to other people.

+1  A: 

Switch Industries every 3 years.

+1  A: 

There are many effective things I did to improve my skills. I read and still keep reading as many programming/technical books I can cram into my skull. I also write as much code as my fingers will allow me.

Programming is an art form. Plain and simply. Just like the artists of history. Leonardo did not just see art as "just a job" but it was his life's work.

Another great thing to do is listen to other software developers who are not only better than you but who are on your same level. There are many ways to come up with a solution to a certain problem. This is where collaboration not only helps solve a solution but it also develops your programming skills as well as your team work abilities.

If you study and practice at it then you will be a great developer.


Understand that knowing what question to ask is more important than knowing the answer (that's what Google or sites like this are for).

What is the best design pattern?

What regular expression...

How should I test...

Once you get that, life as a programmer becomes a lot easier.

+1  A: 

Read Code Complete by Steve McConnell

Brad Osterloo

The single most effective thing I do to improve my programming skills is read books. Not reference manuals or how-to-do-something-in-x-days books but books about best-practices, etc. Like these...




Maintaining a constant curiosity and a passion for learning. Observing my bored co-workers stuck in a rut is a great motivator for maintaining that on a daily basis.

Michael Zanussi

Programming! I love this, anyway, so I do it at work, and at home, on open source projects or my own little projects. I keep learning, new languages, new algorithms, new APIs, etc. The only problem is that days are too short... :-)

+1  A: 

Teach someone else how to program.

I teach programming after work at the local college and it requires me to be able to plan, to think on my feet, anticipate errors that people (including mysef!) make, and to empathize with the difficulties of people learning something new which makes it easier for me to face the frustrations of learning something new.


The single best thing I did for my skills? I taught for a few years during the economic downturn. (Finding "real" programming gigs was tight in late 2001!) By teaching for a few years, not only did I have to learn and know my craft at a way deeper level than normal (thus being able to explain it to other talented coders), but I also had to learn to think like a compiler.

That was the biggest benefit. I can often read a chunk of C# or VB .NET code (my strongest suit, and that which I was teaching) and determine beforehand whether or not the code will compile, and what the effects will be if it does. This helps me out on a daily basis when maintaining my clients' legacy codebases -- especially those I didn't build!

John Rudy
+1  A: 

Joined a relatively big open source project and contributed thousands of lines of code to it. In the process, I learned a lot about architecture of big programs, good cases to use programming patterns, advanced object-oriented design, teamwork, cross-platform compatibility and UI design. Ever since I joined the project, my programming skills keep improving.

So, to answer: it's the working with other people in a team that opens new horizons. And open source projects are very good for this since:

  • there is no pressure to get the work done ASAP
  • people will tolerate if you lack some skill and help you learn it
  • you don't have to program some part of application you don't like or find boring
  • the entire team is friendly, since it's in everyone's interest that the project goes well
Milan Babuškov

Got a job teaching programming at university. Had to read all those text-books that I never read as an undergrad in order to try to get it into the heads of bored 19 year olds.

+1  A: 

In terms of coding, it would be learning Common Lisp for me. I never got to do real projects in it, but it taught me most of the language features possibly present in other languages. It helps me learn new languages/think about problems in unusual ways.

For professional development, I learned a lot from a senior developer at my first job while still in college. He guided me through concepts/things like version control, deployment to servers, testing, and working with designers. These things were confusing to me as a new developer.

+1  A: 

Learn assembler and write a disassembler to see what the compiler really does.

+1  A: 

Being around people that are much stronger than I am. You pick up the scent of good skills from these folks. On the other hand if you are around folks with much weaker skills, there's a tendency to cut corners, etc. This applies more generally than just coding. I take it as a general rule that I need to always be around people better than I am. I have always benefited when I have done so.

In terms of techniques, one that has really helped is actually reading blogs. Putting together a good collection of technical blogs that you read frequently is an invaluable growth tool. For example through blogs I learned about DDD, IoC, SOC, SRP, etc. Yes you can learn them many other ways, but blogs tend to be much less book knowledge and much more real application.

Glenn Block

I decided to get better. It's easy to figure out where your deficiencies are, and it's even easier to ignore them. I read Bill Wagner's "Effective C#", and anything else I could find. I remember I was working this contract and I wasn't getting along with the internal staff, and the other consultants on the engagement were blatantly stealing bad code snippets from CodeProject and billing the client for a full day's work. I felt like there were enough poor developers out there and I wasn't going to be one of them. I always felt like I was a good developer, probably because I was just tenacious, but on that contract I made the decision that I was going to work on the hard parts, the uncomfortable parts, and that I was never going to stop learning how to do things better. Since then, I strive to live up to a standard, as Phil Haack said, "compared to yesterday, I'm always a bargain".

Daniel Crenna
+1  A: 

I started life as a C programmer.

The biggest jump came when I switched from MS-DOS/Win 3.1/Windows 95 to Slackware Linux.

Close runners up:

Learned assembler. Learned about Functional Programming


I started programming about 25 years ago when programming was not taught in classes anywhere and whaever you learned you learned by reading and trying it out. All this really to say that programming was never a job for me... Even now that I work at a large company writting code and designing solutions all day long it's still a hobby for me - something that I love doing more than anything else in the world...

So the answer is I never had to decide to do anything special to get better at programming I always did it because I loved it so I always have been in the learning mode for more than 24 years now and I still learn new stuff almost everyday!!!

Programming is AWESOME!!!!

+1  A: 

I read "A Framework for Representing Knowldge" by Marvin Minsky - and discovered the Science part of the field, as opposed to just the Programming part, which I had gotten bored with

Steven A. Lowe
+3  A: 

I felt like my turning point from "okay" programmer to "good" programmer occurred during college. Two things, which happened to coincide:

  1. Take a compiler construction class (Compilers Construction and Finite Automata), where I built a C compiler
  2. Learn a decent UNIX text editor: I picked vim.
Samat Jain
That turning point turned me from a wannabe programmer into a halfway decent one. I've got the feeling that I'm only now approaching "good programmer". I've got a far better understanding of methodologies and their impact, of design issues that nobody taught me about in university, of really fundamental differences between the paradigms of various languages, etc.

Typing in crummy BASIC games from magazines, and then writing my own crummy games.

I'm a big fan of not reading code, but typing it in. For me the code is more real when I type it in because I "read" it slower and trying to understand it as I go. Downloading tutorials and clicking on buttons never really did much for me.

Will Hartung
+1  A: 

To be honest, learning LISP, Prolog and ML went a long way to improving my skills as a programmer. Looking at the programming world through the lens of functional programming goes a long way. The math behind it is fascinating. It puts you in a completely different state of mind when you go back and work in C#/C++/Java/what have you. Functional programming is clearly not the end all be all of programming paradigms, but it's a great tool to have in your mental toolbox.

+1  A: 

Read. A lot.

And write. Write about programming.

Fashion a passion for programming. Let it fester, er, grow!

The thing about programming is not the programming, but the concepts. If you learn the concepts well, you can apply (most of) them with any development language.

The single most effective thing you can do though is to never stop learning. Pay attention when working with others. Even a senior dev can learn from a junior dev if the senior programmer pays attention. Just remember that you never stop learning.

Second most effective thing you can do is read Pragmatic Programmer.

+22  A: 

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

+1 for knowledge sharing
Leigh Shayler
+1  A: 

I'll go with some bullet points:

  1. accquired a relentless passion for learning
  2. failed foward and always committed to learning from mistakes/lessons learned
  3. made adequate time for reading and attending user groups, etc
  4. made sure to take on work outside of my primary job and contribute to open source
  5. made a point of taking workshops/lessons/classes with industry gurus
  6. learned a new skill or programming language every year if not every 6 months

Wrote code and took an interest in improving it.


Having a background at mostly Perl, PHP and C++, I once started learning Common Lisp. This lead me to learn functional programming and metaprogramming, which dramatically opened my mind.

Nowhere man

To boil it down into a few sentences and echo some things I'm sure others have said (didn't get a chance to read ALL the answers):

  1. Try new things. See a little blog post somewhere about erlang and it sounds kinda neat but you don't have any specific or practical use for it at the moment? Spend a day goofing off with it anyway. You might never use it in a real project, but the extra perspective will help more than you realize. I actually have a policy wherever I'm working that anyone who works for me (who are mainly software engineers) HAS to spend Friday working on whatever they want, and a big reason for that is specifically this point.
  2. Sounds silly, but talk to people who aren't programmers but involved in the same projects/products/companies as you. Get perspective. Learn WHY somebody would want to do something, have a feature, etc. and how it would impact them. I've found this generally leads to designing more practical and well thought-out software, which requires you to think about it a little harder and thus, learn new things.
Chris Ingrassia
+1  A: 

Took a job where I was in over my head, yet had a great mentor who was willing to show me the ropes.

Sean Gough

In my opinion, the most important bit is to keep you mind flexible as the decades whoosh by. I see so many people who are unable to embrace anything new, as they forgot the principal rule of IT: everything changes. If you lose the ability to learn and change in an environment that changes rapidly, you will soon end up fossil-minded.

I personally like competitions like google code jam,, - it really keeps you CS skills in shape. The rest - it's just reference. After using a few OO programming languages, the rest is pretty much the same. It's all the same in the end. It's easy to learn the N+1. th language. But paradigms, algorithms and the rest don't change all that often.

Agoston Horvath


Improving my communication skills with bosses, other programmers and customers

This was my most effective thing to learn. Back in the beginning of my career, I usually thought I understood my boss or a client, when they told me, what feature etc they wanted in the program I was coding. But usually I did not completely understand, what they really wanted, because we usually have different views of things - this is especially true for non-coders!

But with each project and with each mis-communication I learned to listen more specific, to ask for more details and to let the other person explain their ideas in full and to make sure to visualise their ideas with simple sketches - so today I spend a lot more time to make sure I understand the task given, but I save a lot of time and frustration with coding things that were neither wanted nor asked for.

Best regard, B

+1  A: 

I kind of learned it the hard way, but something that eventually really improved my programming skills is knowing when it's time when not to be using them anymore. To be more specific, to know when to take a break. I have spent hours trying to figure stuff out while being a certain state of thinking that made me run around in circles. Taking breaks really improves your skills... or at least their effectiveness.

+1  A: 

The single most important thing I've done is code. Anytime I've learned a new language, or was presented with a new environment or library/assembly, I try and just write some code for it, even if it's a stupid little program that doesn't do much. I used to try and do a hex editor in every new language I learned, it was fun and challenging.

But also, things to remember:

  1. Never stop learning. Also, realize you can learn from anyone even the "green" programmers. I think that I've tried to learn at least something from ever project I've been on.


  1. Never stop growing. Don't get too arrogant to think you know it all, and stop trying to improve yourself.

Learn Lisp or Scheme


Learning Java and getting a Java Certification. It's a really well thought out language, with great support and community.

  1. Faithfully reading development blogs such as Phil Haack's
  2. Reading Code Complete 2nd Edition
  3. Attending developer conferences annually
  1. Working with developers more experienced and smarter than me.
  2. Mentoring developers less experienced than me.
  3. Paired programming
  4. Code reviewing other people's code
  5. Learning new programming languages
  6. Writing cross-platform code
  7. Coding for fun
+1  A: 

I think that most effective moment in anyones career is the moment you decide to get out of your box and meet the real world!

Once you start reading blogs, listening to podcasts and actively include yourslf in the community - your skills will boost dramatically.

Great answer. I agree, totally. If I had points left I would uprate you right now. See you tomorrow. :)
John Dunagan

RTFM, everything else had to wait until I figured that one out.


For me, it has always started with an idea and a problem to solve.

For example, I had learned C in 9th/10th grade on my own, and then wanted to learn this "C++" thing. I had an idea for this simple little "Quote of the Day" app that would greet me when I booted my machine (this was back in DOS and autoexec.bat). I realize it didn't have much to do with OO but I used it as a challenge to begin thinking that way and wrote the app.

I often meet programmers today who seem overwhelmed by the sheer size of the frameworks and other "stuff" around the languages and what not today. It almost paralyzes them from really exploring because the fear of the unknown stops them from spelunking.

When I didn't know how to open a file and read its contents (for my quote of the day app), I started digging (The Programmer's BBS! and spent way too much at B. Dalton/Waldenbooks back in the day.) for answers and ultimately rigged up a solution. I have also always been interested in the best solution, so when I would find a better way to do it, or learned that I had maybe not solved a problem appropriately I would refactor my code.

Start with an idea, a problem, and then write code.


I definitely support Aaron - being a better programmer involves solving problems, not reading about the language. For me the key event was my Latin course back in school. Each "feature" in Latin was explained in our textbook by a text solely constructed of the new grammar style, e.g. a text with an "ablativus absolutus" in each and every sentence. Wow, how I hated this. After sometime we moved from the textbook to Caesar and - BOOM - he wrote about history and I simply wanted to dig through his stuff, so I wanted to read and understand him. No artificial language any more but I created a self interest.

For me it is exactly the same with programming. It's nice to know, that a certain feature exists, but you can grasp it fully, if you use it to solve a problem, even if it's a problem you just thought up for training.

Think about a nice simple tool and hack it up in your language of choice. That's learning how to program!


Learning a unit test framework and integrating tests into everything I did. My code quality went from so-so to sterling in a matter of months. Learn from others who are successful and read lots - the pragmatic programming series of books are great for tips and tricks.

Pragmatic Programmers

+13  A: 

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.
Yes, thank you for this, Choy. Great answer.
John Dunagan


Many people have mentioned reading blogs, but I think that's too passive.

For me, blogging technical topics has really helped boost my rate of learning, and also retention. As Joseph Joubert said:

To teach is to learn twice

It's important to note that I'm not talking about posting stuff like "silverlight sux". I mean set yourself the task of writing a blog post that properly explains the thing you are trying to learn.

Having to write about your learning is a great discipline, for it forces you to fill all the gaps and leaps of understanding in order to convey the topic well.

It matters less whether you have a real or imagined 'pupils', but if you write well enough then the readers will find you!

  • Learn a new programming language every year. Include some very different, non C based, languages like Lisp.
  • Write articles and present at user groups. There is no better way to learn something than having to explain it so someone else :-)
  • Focus on problem solving skills instead of technology. The latter changes every few years anyway :-)
  • Pair programming.
  • Listen to smart people (and know when to ignore them).
+1  A: 

One of the most effective things that I did to become a better programmer was to get laid off in 2003. Once I saw how few jobs were out there for my slender set of skills, I started to work harder at growing (and maintaining) my skill set, both to get a new job then and to keep up my skills since then.

One thing I find helpful is to read a lot of programming books, and to do the exercises and type in the code in the examples - instead of just reading over them, sit down and work at them - doing the work by hand, typing it in letter by letter, helps you to pick up on where you're likely to make errors in the future - do you forget to put in ; at the end of each line, do you accidentally skip putting spaces in... and you also can figure out any system problems - if the code should work, because it matches the book, it can make it easier to figure out why Java's not working.

Reading blogs is good too - keeping up with what people are talking about in the biz is helpful to keep yourself interested and up to date. You may not end up using hot new thing X - but just hearing about it helps keep your brain ready for new things on the horizon.

John Fiala

Diversify your logic training. Any chance you get you should branch out and really explore as many other logic based disciplines as possible. It can be surprising how learning the techniques of another field can help you bring fresh insight into algorithm design and help you approach programming problems from a new perspective.

Spencer Stejskal


Back in the early 90s, I remember reading a column in C++ Report that said if you read one book per year on your own time you are ahead of 90% of your peers. It stuck with me and helped motivate me to read a lot on my own time, which helped me a lot in my growth as a developer and in my career.


I got myself into the habit of writing pseudocode or otherwise planning the LOGIC before starting to do actual programming.


Two things together:
1. Stopped (actively) programming
2. Learned security.
And then there can be 3. Go back and start programming securely. I did this when I went to become a HPC(/security consultant), and I highly recommend it.

I know, I'm a bit of a security bigot - but seriously, secure code IS better code. Works better, usually performs better, by necessity has fewer bugs, and is overall more thought out.

And in addition, I had to learn a lot more about, well, everything, things I'd never touched on while programming and things I would have never experienced. Not to mention reading HUGE amounts of MANY other peoples production code - the good, the bad and the ugly - and seeing the results of the difference between them. This also forces you to think about EVERYthing up front, in very short time frame - so you're virtually guaranteed that your design is solid from the ground up.


Watch all of the SICP lectures and learn to program in the way that they do.

I've known rudimentary Lisp for half a year now and programming for 1 and a half years before that. Right now I'm starting to watch the videos, and I'm almost certain I'll watch them again in a few years to refresh my memory. They're entertaining, interesting and mind bending of the way you think about programs.


During my university days the single most course that improved my programming skills the most was the data structures and algorithms course. I chose c++ as my language of choice and it was a classical experience.

Umer Azaz

On each project I try to use a new technique or apply a different design pattern. I also go back to older code and re-read to see what areas of opportunity I missed try to match those items with new things I have learned. I also read, read, read programming blogs and books.

David Robbins

Hiring really good developers and working with them, as much I was able to.

Robert Brook

Learning vim AND regular expressions well.

Zsolt Botykai

Started reading the development blogs. It's almost too much information and I doubt I'll ever get to even 25% of the stuff I bookmark but it keeps me up to date and excited about development every single day and because of that I'm a better developer.


I listened, attentively, to those who were willing to teach and show.

Optimal Solutions

Be responsible for both writing and supporting the customers who use the code you write. Any lack of quality will be your own job to fix, you get the irate calls, you soon learn to make the code better.

Mike Edwards

Worked with other developers. Moving from a small 2 person development department to bigger outfits really opened my eyes in terms of different ways of approaching problems, different coding styles etc.

I'd say that was the "Single most effective" thing for me.

+1  A: 

Going to local developer user groups and connecting with members of local development community. As great as it is to blog, read books, and your job...there's something about going to a user group meeting, getting pumped up about a concept/technology, and going home and plugging away at it. Or just grabbing a beer afterwards and discussing tech with the fellow user group members.

Karthik Hariharan
Emphatically Yes to this answer. Uprating as soon as I reload points. But, in the meantime, this Developer User Group leader thanks you profusely for understanding.
John Dunagan

Just love your job, and you'll improve. If you wake up every morning in bad mood because you don't want to work, then leave your company ! Your work is 50% of your life, if you don't enjoy it you'll never improve.

Nicolas Dorier

I've found that I can read about something and I'll remember some of it. But to really make it stick, I need to work on a project using it. This forces you to get into the details of how it works and then you have experience to lean on instead of just trying to remember something you read.


Teach. Become a resource for other people wherever possible, and you will learn to think of things in different ways as you try to understand why their mental model doesn't match yours. Find ways to give speeches, tutorials, etc. You'll find that teaching a topic well requires mastery.


Learning BNF (Backus Naur Form) and its various dialects, brought my understanding of computer languages in general to a whole new level. Making my first compiler (a really simple script compiler) sky-rocketed my skills.


Working with developers that are better than you is extremely important to self-improvement. They can provide valuable critiques of your code, and impressing them with your code and other contributions will push you to become better. They also provide positive examples of good code, time management, documentation, etc. If you are the best programmer in your company/project, it will be more difficult for you to improve. There is usually someone around that is better at some aspect of your job than you are. Watch them to figure out how they tackle problems and ask them how they learned to do it.


In inverse order:

  • Programming
  • Thinking before starting to program
  • Discussing my thoughts with other developers
+1  A: 

Set aside some time every morning to do some study. In the past this was 30 minutes before I started reading email, now it is often reading books or RSS feeds on the bus on the way to work. The amount of knowledge you can accumulate simply by taking a small amount of time every day to study something new is quite startling. Equally, it is alarming how quickly my skills started to whither when I did not.

John Channing
+3  A: 

Getting involved in an open source project with a lot of developers that are smarter than me. For me, it was getting involved in the Asterisk project ( However, the key thing is finding a project that you can be passionate about.

Russell Bryant
+1 for passionate. That is what will make you go the extra mile which makes a difference.
Thorbjørn Ravn Andersen
+1  A: 

Lots of good answers in this thread so far.

I learned more about the art of software development, programming, testing and documenting in the first month of contributing/working on an open source project than I'd learned in about 5 years working in software companies.

Its hard to quite explain really why this is other than if you find a reasonably popular well run open source project, you tend to find many like minded peers who love to both share useful ideas and information as well as learn new things and push the boundaries of the art. You also get to read lots of existing code and documentation and see it being changed in real time to help learn new ideas and approaches.

Programming is such a broad topic from design, testing, technologies, frameworks, APIs, building tools, documentation, IDEs, patterns and being lean & agile to name but a few off the top of my head - its kinda hard to pick up this vast landscape from a few books or courses or to figure this stuff out all yourself; its better to just watch some highly experienced folks demonstrate it all in action on an open source project.

James Strachan

Loving what I do and striving daily to learn, learn, and then learn some more.

Jeremy Reagan

If there's something I can't do, and I know someone else can, I usually ask them to do it for me the first time, and then try to do something similar looking at their code. This is how I learned MySQL, OOP, a whole lot of machine learning, version control... the list is pretty large. The good thing about having a person do it instead of a textbook is that you can ask them specific, pointed questions about their code should you get lost, and you don't have to skim through three pages of discussion around a piece of code, like you would with a textbook.

Robert Elwell

If we're talking about "the only" then it would be starting learning LISP. I got bored after two months, but LISP has prompted me to move onto OCaml, Haskell, Erlang... Each of those improved at least something in me.


Not being afraid to say or suggest dumb things.

A good listener (dev + team player) will tell you why it's not such a good idea and you learn heaps from the experience. Kind of like not being afraid of rejection. Use it sparingly, though. ;-)

+1  A: 

learn another programming language and then go back to the first one later

+1  A: 

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.


I realized that I had a problem understanding the more advanced topic in software design, so 8 years after completing my bachelor degree I signed up for a number of cources at one of the IT universities here in Denmark. I have often heard that the subjects was only of interest for academia and was of no use outside campus. In this case those rumours were dead wrong, as most of the stuff can be used in real life. Both the SQL and Advanced Design Patterns classes were excellent. Btw. I totally agree with Bill the Lizard, teaching forces your to KNOW your subject in each and every detail.


Locate and attach the fellow travelers in your area. If you don't have a Group or a community that meets regularly to support, challenge, teach and learn from each other, start one. If they don't know more than you, they know different from you, and for that, each and every one of that community is priceless.

What also works for me is to have at least one thing I'm working on, always, to get better. Whether it's working through a book, or doing a project, or downloading some cool thing and playing with it.

John Dunagan
+1  A: 

Reading others' code and learning TDD.

+6  A: 

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) !

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

I've been programming in various languages for about five years, and I have to say that the single most important thing I've done to improve my skills is to simply keep doing it.

Allow me to illustrate with a (true) story.

Improving my coding skills

The first time I did any programming was a small personal website for my Bar Mitzvah (with which I managed to make half my family mad because I didn't bother with paper invites). That was simple HTML and JavaScript, and I hate to say that a lot of the HTML -- at least initially -- was done in FrontPage. And I used frames.

Next, I made up a small site for a project I was doing with a friend, and based the first version on my Bar Mitzvah site. Still with frames. But I wrote my own (insecure, yes) JavaScript password handler with only one or two hard-to-debug errors (a mismatched brace).

Fast-forward to me learning CSS for the second version of that project site. I redid the entire thing, HTML and JavaScript, to be single-page (no more frames!) and tweaked the password handler some more. Then I discovered that the server I was using had PHP installed. So I looked up a reference (I think it was and started teaching myself the language; I learned the basics in about six hours at a coffee shop while I was supposed to be doing my homework.

From there, I developed the site template system and coding practices I have used and evolved since then into the Southwest Robotics Team website.

So, it was just a matter of just continuing to program for me. I've also talked to other programmers, read books, looked at the source for everything I could (at least HTML, CSS, and JS), and played around for no reason sometimes. It's definitely worked for me; I'm only learning more stuff (my knowledge regular expressions, for example, actually started with me using AutoWikiBrowser on Wikipedia).


Working with other people

It is useful even if they are not better than you are. You get to learn new ways of doing things, understand why certain ways of coding are just bad, explain why you code the way you do. This is essential !

  1. Don't be bashful. Ask questions no matter how dumb you feel they may be.
  2. Code as much as you can. The more you code, the more mistakes you are going to make, but as you progress, you will notice that your mistakes start to lessen.
  3. Read books, blogs, forums.
  4. Listen to podcasts, watch videos.

Watching the SICP videos


Never walk away from a coding challenge.

Solving the unsolvable will work magic for your confidence and reputation.

  • Curiosity

Wanting to know, how it works has probably got most of us started in this field.

  • Quality

When you have done something and dont feel right about, and regardless of advice the people around you give, you keep searching for a better way to do it, until it "feels" right.

Those are the two things that have indirectly caused me to question things, and learn a lot.

Rihan Meij

I forget who first said this but "try to learn a new language a year". I think it helps you to approach writing solutions from a number of different angles.

+1  A: 

to care about being better, and to be better means doing the Right Thing not just whatever works.

+1  A: 

Take a programming/algorithms book,close cell phone,close door,sit at desk,
stay away from a computer and started reading.
I need to do this more often.

+1  A: 

Learning about design patterns to reduce chances of duplication of code and thus embracing good software engineering practise in doing so has been the single most effective thing I am doing to improve my programming skills.


Working on and founding a lot of Free and Open Source Software projects...

There has been nothing that have helped me out more then this...

Thomas Hansen

Some great answers in here and definately some things I should try out.

One thing I do sometimes is code with no aids at all. So no warnings, no stylecop, no fxcop, etc, and my profiler (ants) not running.

That way I see just how good I am without aids. It's like riding a bike with stablisers, and then having them taken off.

But when I am writing code for commercial-intent I turn all these aids/tools on and improve my code where necessary.

+1  A: 

I took the Introduction to the Theory of Computing class at my university. It made me understand the math behind a lot of things. Or, more simply, it made me understand a lot of things. Now, when I design algorithms, I have a better understanding of the restraints I face as well as how to find approximate solutions to many unsolvable problems.


When coding, thinking like a von Neumann machine.

I consider this as a problem. The future is in multithreading, many processors etc., and thinking "von Neumann" is a problem there. Think functional / message passing.

Besides writing alot of code , i think understanding everything i wrote actually helped quite a bit. There are too many copy and paste coders out there.

+1  A: 

Doing Project Euler.

+7  A: 

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

Awesome story, thanks!
Liran Orevi
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.
Thorbjørn Ravn Andersen

I worked for 2 years with someone remarkably more intelligent and well-versed than myself. I'm sure he became frustrated at times, but through that work relationship I was able to develop a perspective on application design and development. I stopped just going through the motions. Approaching design and development from a more well-defined position has made all the difference.

I hope that answer isn't too abstract.

+1  A: 

Visiting Stack Overflow of course!

The Alpha Nerd
+1  A: 

Most of what I know I believe come from the blogs I read. You can learn a lot from the people out there.

I also try to read code written by others. Right now I'm browsing the code of ASP.NET MVC (amazing to see what's going on behind the scenes!) and AutoFac.

Sometimes it's hard to put into practice everything new you see, but I try to keep up with the new stuff (libraries, frameworks, etc) I consider most relevant, such as jQuery and ASP.NET MVC.

Gerardo Contijoch

Always go a step beyond what's required.

If a project requires a new technology, rather than asking for training, I'll study some existing code and documentation, then start a pet project on my own. It's always good to have suggestions beyond what others have considered.

Never leave a question unanswered if you can help it. Always satisfy your curiosity. Chances are you'll learn a lot in the exploration.

+1  A: 

Fixing/enhancing other peoples code.

+2  A: 

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

+1  A: 

Never assume anything, sounds simple but I have found assumptions lead to bugs.

Don't be afraid to ask the community for help no matter how ridicoulous it may seem.

Reviewing other people's code, learn from their mistakes/genius


Having an open mind all da time!

+1  A: 

Programmed because I enjoy it and have a passion for it rather than just because it was a "job".


Try not to build anything you design for a few weeks. Often other scenarios will come to you then before things get locked in.

Jas Panesar
+3  A: 

1) Be curious. Learn from the smartest people around. Read books, articles and code on how things have been done or may be done 2) Think. Play around and try out your own ideas 3) Fail. You only know what is good when you now what doesn't work


I would have to echo others answers here.

I think the best way to really get to know something (for me) is to pick a topic that you are interested in and unfamiliar with. Then look at how others have done that while you try to replicate/enhance it.

Currently, I have been very interested with low level systems programming, specifically the boot process of an x86. Looking at others bootstrap code has been immensely helpful in beginning to code my own.

+91  A: 

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.

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

Switching to linux.

+5  A: 

Solve hard problems with code.

In my own experience it has been the code that I didn't know how to write that taught me the most.

If you seek out hard problems you will learn to learn to work hard; learn to do your own research; learn the best language for the job; learn to use development tools (IDE/debugger, source control); meet people who are like minded, and above all else become inspired.

When you are inspired there is nothing that you cannot learn or do.

Evan Moran
+1  A: 

Learning as many languages as possible.

Jon Harrop

Code Reviews: We implemented code reviews within our team. We read other people code beforehand, then all the developers sat in a room on a Friday afternoon and the person who wrote the code explained what they did and the reason why they used that approach. When I came over similar issues later on it definitively helped me look at things in new ways.

Arguing: Even though it sounds a bit strange but arguing with colleges. When people have different ideas about the best approach to take on an issues it makes you think about the problem in more detail, research it etc... and normally in the end you end up with a better solution that either one originally suggested.

Lastly being around passionate talented people...

Jon Jones

Once I decided that my fingers are slower then my thoughts. I spent a week improving my typing skills.

The result was awesome! Programming became a pleasure after that.

Bogdan Gusiev
+1  A: 

Read "Code complete" by Steve McConnell...

+1  A: 
  1. Hobbying. My dad bought an IBM PC a few months after the original was released. Programming for fun taught me a lot and made it enjoyable.

  2. My college thesis. It was hard, ambitious, and took 18 months of coding to complete. And I wrote it as member of a team of brilliant people (the MIT Media Lab), from whom I soaked up lots of things.

  3. Math. As a physics major I had to take lots of math classes. As a result, I do not shrink back from tackling problems deemed to difficult by others.

  4. Reading about patterns.

  5. Learning UML.

  6. Learning Perl. Comes in handy all the time.

Paul Chernoch
+1  A: 

The best thing I ever did was read Code Complete by Steve McConnell.

This had a massive impact on the way I wrote code, the way I thought about code and the way I thought about my career.


Learning PHP and get rid of Windows

Time Machine

Reading, understanding, extending, and modifying source code of programmers who were more expert than me -- i.e. K&R, source code for ThinkC Foundations Classes. Then applying the methods/patterns I learned in my own projects.

Larry Watanabe

Started learning C++ a year ago

+2  A: 

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."
JB King

If you are interested in OO programming, I would also recommend to ready Object-Oriented Software Construction, Second Edition by BERTRAND MEYER. It really helps me to understand the OO concepts and improved my C++, Java and C# coding.


  • read some of the books listed at
  • actively use what you learned above within a few days, or you will lose it.
  • contribute to a wide variety of open-source projects.
  • rleir
    +1  A: 

    Hmmm - I think that the #1 single most important thing to improve my programming happened more than 10 years ago when I read the GoF Design Patterns book Although my skills have greatly improved since then by learning TDD, database design, IOC, DI, Agile processes, etc.

    But those have all been a lot of small steps - the GoF book was a huge leap.


    Write a new IT book, if you want to improve your knowlege and skills.


    Learned to read!

    ...seriously. If you think about it, we wouldn't be able to code anything without that basic skill.

    Justin Niessner
    Also, taking my first breath, and drinking my first milk helped a lot as well!

    1) Learning varied programming concepts: PLC programming, Assembler, Scripting, RAD Concepts, SQL and various Languages definately gives you a wide range of ways to attach different scenarios. Sometimes this is easier in the situations you find yourself in and sometimes not easy in an commercial/working environment. You can however use new technologies in isolation in smaller projects or disctrete parts of projects as "proof of concepts" to learn and test these technologies and learn new ways of doing things.

    2) Reading Books (for particular help in specific areas) If you find books dont help you its because you're on the right track.

    3) Main Point: Doing varied types of projects, Windows, Web, Windows Services, Screen Savers, Win IP Hooks, etc definately gives one a good overview of how things work and what works. Doing small projects when learning a new technology, either rebuilding existing apps you've built or cloning other small apps can definately take you throuhg the development processes quicker. 10 years of varied expereince is better than 10 years of repeat expereince.

    4) If you dont like certain things in development eg Regular Expressions, JavaScript, become an expert.

    5) Code Generation: Use code generation tools, you will soon learn to spot repeatable patterns to implement using code generation to save you time.

    Mark Redman

    Taking the AP Computer Science courses in high school helped me the most out of anything.

    I say that because prior to that I was self taught and would code in QBASIC as a hobby. I mostly just did my own thing, paying no attention to coding practices or readability. But in computer science I was taught C++ and the fundamentals of OOP.

    Obviously I've done a lot to improve my skills since then, but some level of formal training can be extremely helpful to provide a little structure in your coding style. And on top of that I'm glad I had a good teacher to learn from.

    Steve Wortham
    +1  A: 

    Learning to say I'll get back to you on that when when pressured to answer the question How quickly can we do that ?

    Martin Spamer

    First, writing code. It helps you to improve your basic programming skils. Trying not to copy paste. Trying not to repeat yourself, find another aproach. Trying to learn different languages and new technologies and best practices. Also trying to understand what other people are saying rather than what you think. Trying to read other people's code. Those helped me a lot to improve my programming skills.

    +10  A: 

    Read. Code. Read code.

    i like what you wrote. ;)

    One of the ways that I have used to learn to be good at programming has been through code reading, lots and lots of it, practice everyday and invest in books. Again, there's no one trick that helps - you decide what works for you and stick to it. But what ever you choose, it's always important to keep coding daily if you can.

    Here are a few list of books that I have recently bought and found very useful.

    Helen Neely

    Started Caring.

    +1  A: 

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


    Pay particular attention to your life outside of work, and invest as much or more time in friends/family as sitting coding. How can you be good at work if your needs arent met outside of work?


    Joining StackOverflow and seeing the huge number of outstanding programmers in the community. It was a kick up the bum and an inspiration at the same time.

    +1  A: 

    Leaning Object Oriented Programming when I moved from C to C++
    And the principle of SoC

    Binoj Antony

    abstract one mile long, code one inch deep

    -1: Huh?? Can you please explain?
    Jim G.
    +1  A: 

    Listening to DotNetRocks.

    A number of years ago, after I started listening to each show during my commute, this podcast really unlocked a whole world of knowledge that expanded my understanding of software development, patterns, architecture, books, and the Microsoft community in general.

    The quality may vary, but they still put out a lot of good stuff.

    Guy Starbuck

    Reverse engineering. Looking inside massive compiled proprietary applications, and web applications from only the client side gives you a great view of how things are currently being done in the real world. Also teaches you what to avoid when programming.


    Wrote a custom VM with a custom ASM syntax and a custom C-style language. It helped really a lot in understanding low level programming and architecture..

    +1  A: 

    Getting to 10,000 hours of programming... Experience and just do do do...


    Mentioned several times and voted up, but without a doubt - working with smart(er) people and better developers has had the most impact for me. It gave me a chance to learn from them something I didn't know or how to do better what I already did know and motivated to work on my craft as a developer.

    Also, there's a great book by Chad Fowler - "Passionate Programmer" - covers very well a lot of points discussed here, and I think very relevant to the discussion.

    Coincidentally, my 2nd one would be being passionate about / liking what you're working on - nothing as motivating as labor of love. Once this happens, you do want to make your end product better, and this leads to trying better yourself as a developer.

    Ed Y.

    The single most effective thing that did improve my programming skills, was to initially invest much more time to think about the design of a program before starting to implement it.

    Learning from other people helps optimizing the style and engineering and detail parts of programming, but it does not help much you when it comes down to finding a solution for a given unique problem.

    The solution finding process is still a creative process, that you have to go through for yourself (or in a team). There often is no standard process and/or pattern to help you resolve the problem as a whole (if there is one, then you are probably solving a known problem once again, which still happens often in programming..).

    After all it can be an extremely great satisfaction when your program takes shape. Even before you wrote a single line of code. And its an even greater satisfaction if your design, concept and plan works good when you write the code.

    The coding is not less important, but its just the second step of programming.


    I have some dissatisfactions against many inefficiencies in the internet world. These inefficiencies are usually gone if you start paying some money to the service provider, eg., where it provides more services.. But being a cheap guy, I started my own pet projects trying to mimic the provided services.

    Lucky me, Google app engine provide free resources, from which i can start experimenting.

    So I guess start with your own need and displeasure as (internet) user, and see what can you improve.. (i am stuck with app engine jdo relationship now


    The ability I believe aided my programming skills the most is:

    Take a complex problem and split it up into smaller manageable chunks; arrange them in a logical order; handle them one at a time....then TA DA! you look around and it's DONE!

    Aside from that...Know the business process you are assisting...AND KNOW YOUR DATA!

    +1  A: 

    Learn to justify (in your head) other people's code. It's just too easy to hit programmer's block because of existing code is written badly and needs refactoring. Instead of immediately re-writing and re-testing everything, try to find some perspective from which that code would seem more reasonable. Your perception of code depends a lot on how you look at it. It can be hopelessly bad, or be slightly out-of-date at the same time.

    Example: for a long time I hated visual studio .sln and .vcproj files "poluting" my folder structure. It bugged me that my main folder should start with some application specific configuration files. I saw other people's projects that had folder structures like:


    And it made sence to me, simple and elegant. But still, for own "ultimate" projects, it was too poluting...

    Well, finally I found a perspective, from which this folder structure made sence - think of it as a generic file listing. Those .sln and .vcproj are just some standard, that is common enough to be chosen for declaring all the files in all subfolders. Kind a like declaration of functions in c++ header files. It's just there for Your convenience, and at the same time it can be used for pre-compiling executable binaries from c++ code. Sure, it's xml-format is improssible to read or modify, but for now we can ignore that. As long as it saves time for us to start new projects we can live with it.


    Lookup programming coursework in a language of your choice online and try and solve assignments.

    +1  A: 

    Studying "Software Engineering" at a Technical University.


    Sorry if this answer is a duplicate (as I did not read most of the old answers with score less than 2) - in any case it combines some stuff from others (yes, I did upvote them):

    1. Look back at your old code, and rewrite it (from scratch if it is horrible enough)
    2. Read about design patterns and notice the ones you are prone to
    3. do not re-invent the wheel. Ever. If there is a perfectly good freely available library for something USE IT, do not re-write it (unless you can convince the original programmer to accept your re-writing as the next major version). Using good libraries written by other people will teach you more than writing a shoddy one yourself.

    Documenting my own code as i write the code. It helps to clearly define the interface (what goes in, what goes out) and to find corner-cases before they pop up in real-life use. It also makes the code re-usable, in that six months later i can look at the API docs and know WTF the code does without having to decode it. My mantra has become "WTFM" - Write The Fine Manual.

    Stephan Beal
    +2  A: 
    • 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.
    1. Read Code-Complete and other books on the philosophical design of software [as opposed to technical books]. Technical books help too, but you don't really need to absorb as much because you can just look it up.

    2. Read blogs-You won't agree with everything but you should evaluate everything and take away what you think works best.

    3. Don't ever, ever think you know all there is to know about a topic. Even if you do, consciously thinking that is a good way to stop learning.

    +1  A: 

    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"?
    Ed B

    I spent roughly six weeks working through one of Charles Petzolds great books, Programming in the Key of C#.

    I went through it front to back, things i used to struggle on became a breeze and now I'm borrowing books about programming from the University library as often as i can.

    For me the best thing to do was to just keep going, unless your forcefully try to learn something you're never going to make any advancements. It takes effort and patience which is well rewarded.

    Jamie Keeling

    One thing that really improved my programming skills was watching and applying Misko Hevery's Clean Code Talks from the Google Tech Talks (available on Youtube, here's a playlist). They're presented in Java, but instill principles that can be applied to any OO language.

    By getting into test-first-design I realised that code maintenance and maintainability was multitudes more important than just getting the first working version out. By applying TFD & TDD my code became cleaner, easier to maintain and had far fewer bugs than my non-TDD/hacked code.

    I agree with the other comments about reading other people's code to improve your own coding, but one beneficial method was to print out some open source code and look over it with your development team and perform some code analysis. Find ways to improve certain code, find ways of refactoring the code to be more efficient and easier to understand. Look acutely at the variable and method names chosen in that code. Do the names of the variables and methods explain their function? Ask questions!

    Kevin McKelvin
    +2  A: 

    Learning different classes of programming languages...

    C, Java, Python, LISP...

    +1  A: 

    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.

    +1  A: 

    Creating 3D scene with phong/gourad lights and phong shading rendering terrain using only... setpixel - it was my university project, it was hard but I learned much

    +1: because of doing your own sw rasterizer
    Stringer Bell
    +1  A: 

    Learn languages other than object oriented languages.

    One of the most effective things for me was one of my undergrad classes where we worked with functional languages, logic programming and constraint programming (in my case it was ML, Prolog, and the prof's own constraint language). With languages like Java and C# being all the rage today, it's easy to have a one track mind when it comes to programming, but I found it extremely beneficial to learn something totally different.

    The other big thing for me was working with others that have more experience. When I was working as an intern I learned a LOT by reading code of the most experienced developers. Also learned by having the more experienced developers rewriting my poor code, so I saw first hand better ways to accomplish what I was trying to write.

    +1  A: 

    1) Learned to use a good text editor for everything (Emacs)! You can become so much more efficient if you never have to take your hands away from the keyboard! Keybindings have made me a faster programmer! 2) Learned to use Bash to it's full capability. I can do things twice as fast because I do not have to code everything. I can write two small programs and send the output of one as the input to another using pipes. It is surprising how many good programmers don't know how much time can be saved using the shell.

    +1  A: 

    working with Nemerle

    +7  A: 

    Ask lots of dumb questions on Stack Overflow. Seriously.

    William Jockusch
    Asking dumb questions is a LOT easier than fixing dumb mistakes.
    +1  A: 

    Learning from mistakes and refactoring old code

    +1  A: 
    • Make mistakes and take criticism as an opportunity to learn
    • Learn how to read code and understand the original intent
    • Learn when to ask for help (and when NOT to ask for help!)
    • When to read books vs start hacking.
    • Break the build...but please fix it :)
    Jimmy Lyke
    +1: Some really good advice here.
    Jim G.
    +18  A: 

    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.

    +1  A: 

    also innovative about doing something new. this is not a matter that you know much more and have a small knowledge. i am agree to doing practice. and also be passionate about your work.

    Improvement + Innovative + Practice = successful programmer.

    steven spielberg
    +1  A: 

    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.
    For some people, strict adherence to rules can give a false sense of programming ability (I'm guilty of this). Not to say we shouldn't be strict, but that it is important to distinguish the difference between "thinking" and letting the rules think for us.
    I think, best practices are there for a reason. Moonshining code was never a good idea, and I have seen many bad, bad, terribad examples of implementations in the last years where people thought they were more intelligent than, say, GoF.I DO believe that there is some virtual "normalized form" of software, a way to make every application work smoothly and in an uniform way. Design patterns and best practices are a good approximation to this.Thinking? About what? How to implement a visitor or a strategy? There is no need to - thinking in software development happens on a much higher level.
    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
    @Mongus this is a valid point, but I believe that it's also necessary to understand the code in the context of the application. my EXTREMELY verbose commenting is like what an O/R mapper does for objects and relational tables... it bridges the gap between the two totally separate domains.
    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
    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
    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.
    You should almost never need to comment code. When you need to comment, it means your code isn't clear enough in the first place, or you're trying to be too clever. The only time comments are really necessary is to explain something clever that needs to be done that isn't immediately clear (and these cases should be pretty uncommon).
    @Jim G. The perspective is that you learn a fundamentally new way of thinking that way. Before I started with F# I was still using foreach in C# for many things, as well as other imperative constructs. Now I have started to solve more and more things in a much more elegant - the functional - way. And you also learn about the value of immutable data.For me, it was like a epiphany. It takes a few days (or weeks if you are not as quick a study as I am) - but then it goes "click".
    @stormianrootsolver: Good stuff. Thanks!
    Jim G.
    > Forget everything I learned during the years I wasted with lowlevel timesinks like "C++"-1 for this, everything important (browser, os, office) is still written in C++
    +3  A: 

    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.

    Joel Hoff
    +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.
    @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
    +4  A: 

    1) Learn an assembly language (any chip, just learn it well) -- it will make all of your other code much better.

    2) Learn how to find the documentation and actually read it. I am pretty convinced that the most programmers refuse to read the instructions that are available for their tools.

    Joe Zitzelberger
    +5  A: 

    The best thing I did was start my own side business with some partners.

    Since my personal time & money was on the line, it forced me to re-evaluate & analyze everything I used in development & determine how to best utilize them for this project.

    • frameworks
    • source control hosting
    • unit
    • testing development
    • methodologies
    • development tools
    • third party controls
    Ed B
    +1: Did your side business experience make you more aggressive or conservative with new development technologies, frameworks, and 3rd party libraries?
    Jim G.
    Ed B
    +8  A: 

    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.

    Wayne Werner
    C++ was your Blub. :)
    Paul Nathan
    +2  A: 

    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

    joe snyder
    +2  A: 

    What I am following,

    1. Write Code for every single concept you learn.
    2. Buy books and read on the subject.
    3. Talk with the experts.
    4. Never lose hunger to become an expert.


    Kirk Hammett
    Writing code for every single concept is interesting, I try to do this for every interesting algorithm I learn..
    +8  A: 

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

    you mean debugging?
    @DeltaRogue can you elaborate on that
    Yes Benny. :)@c0mradeAs 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 ?:)
    I second +1 pad
    +8  A: 

    1) Teach

    2) contribute to mass open-source products


    Interesting projects in new technologies (to you) are the best way to learn. I picked up C++ and Python because they were the best options for specific projects.

    Michael Shopsin
    +4  A: 

    What about projecteuler? I've started to solve the first few problem, will see how efficient it is..

    +1  A: 

    I accepted the patterns revolution


    I know patterns always existed but we were not conscious of them in the way we are now.

    Patterns always existed. It's just that they now have names...
    Please see edit
    In what way did you accept a patterns revolution? Was it also reading about design patterns from specific authors? Was there any specific reading or action you're trying to recommend?
    Kimball Robinson
    +5  A: 

    Learn C and C++

    +8  A: 

    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.

    +1  A: 

    On a long term: Constantly trying to adopt new technologies and development techniques. Also, reading Design Patterns by Gamma et al.

    On a very short term: Getting away from my computer for a while. I often get the best ideas when I am NOT staring at the screen. Works almost every time I am having a hard problem to solve.

    Adrian Grigore
    +1  A: 

    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.

    Saladin Akara
    "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
    @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
    +9  A: 

    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.

    +19  A: 

    Quit my last job.

    me too! (need some more chars...)
    If you would tell us why, this might even be an answer. ;-)
    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. :(
    Been there, done that.
    +1 Good luck landing a job that isn't a dead end.
    Tomek Szpakowicz
    ahahaha...I did the same thing! :)
    +8  A: 

    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.

    Chris Knight