What is the single most effective thing you did to improve your programming skills?

Question

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.

Answer 1

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

• trying to solve other people's problems

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

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

In the process, I

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

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

Answer 2

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

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

Working with smart fellows teach real world solutions to you.

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

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

Answer 3

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.

Answer 4

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.

Answer 5

Read. Code. Read code.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

Going to a good university.

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

Sleep!

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!

Answer 14

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

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

Answer 15

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

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

In no particular order:

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

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

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

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

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

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

Answer 16

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.

Answer 17

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.

Answer 18

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

Answer 19

Ask lots of dumb questions on Stack Overflow. Seriously.

Answer 20

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

Answer 21

1) Teach

2) contribute to mass open-source products

Answer 22

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.

Answer 23

Try your hand at writing a compiler.

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

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

Answer 24

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

Answer 25

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.

Answer 26

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.

Answer 27

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

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

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

Answer 28

Engage on a open source project.

Answer 29

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

Answer 30

Many great answers here. However, one of the most effective things for me personally was to join Stack Overflow. There are many people here that are smarter then me, and I learn a lot from their very thorough questions and answers