Teaching,

Showing another programmer something you have recently learnt. I find it reinforces my knowledge, since they tend to have pesky questions they need answering.

I think it takes more than just one thing to make you a better programmer. I think it requires a passion about programming, a willingness to always be learning and a multi-faceted approach.

I head over to Project Euler ^[1] every now and then and work through their programming problems. I enjoy the problem solving and seeing how other people solve the problems in different programming languages is often enlightening.

Another option is to present on a programming topic at a local user group, code camp or even a lunch'n'learn at your company. It will force you to dive into a subject more deeply. Not a member of a user group? That would be another good start ;)

The third thing that I always do is to learn a new language or technology (like WPF in .NET) by assigning myself a pet project using the new language or technology. When I do this, I try to create something I will use to keep my motivation and to make it real. They are usually little utilities that just make life easier.

Here's an answer from an old post on my blog:

Secret Teachings: The Programmer's One Inch Death Punch

How do programmer's get better at their job? Few programmers think of programming as a true profession. For most it's just a job. They go to work, do what's asked, and go home. They don't read. They don't attend conferences. They don't train. In fact, the training business for software is pretty much dead and has been for years.

Other professions have different attitudes. Professional athletes train constantly to improve their skills. Even doctors and accountants have stringent continuing education requirements so they stay current.

What can we programmers do? Let's first look at how expert performers are created in the first place. That might help us figure out how we can become better. Time in an article called The Science of Experience has a lot of potentially fruitful ideas:

1. The number of years of experience in a domain is a poor predictor of attained performance.
2. Rather than mere experience or even raw talent, it is dedicated, slogging, generally solitary exertion, repeatedly practicing the most difficult physical tasks for an athlete, repeatedly performing new and highly intricate computations for a mathematician, that leads to first-rate performance. And it should never get easier; if it does, you are coasting, not improving.
3. They key is "deliberate practice," by which is meant the kind of practice we hate, the kind that leads to failure and hair-pulling and fist-pounding. You like the Tuesday New York Times crossword? You have to tackle the Saturday one to be really good.
4. Great performance comes mostly from deliberate practice but also from another activity: regularly obtaining accurate feedback.
5. Experts tend to be good at their particular talent, but when something unpredictable happens, something that changes the rules of the game they usually play, they're little better than the rest of us.
6. Entire classes of experts � for instance, those who pick stocks for a living, are barely better than novices. (Experienced investors do perform a little ahead of chance, his studies show, but not enough to outweigh transaction costs.)
7. Researchers found that élite skaters spent 68% of their sessions practicing jumps, one of the riskiest and most demanding parts of figure-skating routines. Skaters in a second tier, who were just as experienced in terms of years, spent only 48% of their time on jumps, and they rested more often.
8. Experience is not only insufficient for expert performance; in some cases, it can hurt. Highly experienced people tend to execute routine tasks almost unconsciously. Experience in a particular task frees space in your mind for other cognitive pursuits, wondering what's for dinner, answering your cell, singing along with Justin Timberlake, but those things can distract you from the accident you're about to have.
9. Experience can also lead to overconfidence: a study in the journal Accident Analysis & Prevention found that licensed race-car drivers had more on-the-road accidents than controls did.

None of this trips my BS meter. It makes a lot of sense and jibes with experience. We all know people with 10 years resume experience in X who couldn't program their way out of a paper bag while someone with just 1 year of experience continually delivers quality results. And I know I've grown the most when truly challenged to solve new problems.

Given the science of experience article I think Coding Dojos seem like a potential solution to the programmer training dilemma. A coding dojo is "a meeting where a bunch of coders get together to work on a programming challenge." It's a form of deliberate practice, which is "not the same as experience gained while doing your job. It is when you actually seek out experiences that will stretch your skills just the right amount, and give you feedback that enables you to learn."

For thousands of years martial arts have been taught in a deep mentoring relationship using a long progression of increasing difficulty and challenge. The path from a white belt to a black belt is long, it's hard, but in the end you learn. You learn through constant practice and challenge.

It would be interesting to consider how a similar infrastructure could be setup to train programmers.

Learn a new programming language.

Particularly something that had features or a style you haven't used before.

Ok, this is going to sound really insane, and it's not a joke, but actual exercise makes me a much better programmer.

Something to do with endorphins and blood-flow to the brain I imagine, but after a workout, I get really good programming flow.

In the past, I would figure things out on my own, but now the ubiquity of answers on the web has made me a lazy developer. I realized I was depending too heavily on Google for answers to small coding problems.

So I decided to give myself a five minute window to analyze a problem and see if I would be able to arrive at a solution myself, using the documentation. It seems trite and silly and, well, obvious, but I don't think I'm alone in developing a lazy dependency on Google (or SO for that matter).

Now, if I want to know how use LINQ to reorder a string, I sit down and write the code to figure it out. Then I truly understand it, rather than just pasting someone else's answer into my code. The exercise forces me to understand things I wouldn't normally dive particularly deep into.

That was a difficult thing to admit, by the way.

(Why am I not surprised no one mentioned this....)

I carefully document my code (and sometimes other people's ^[1]) particularly if it involves an API other people will be using.

It forces me to re-examine the choices I made in the design, particularly those concerning the interface ("if ParamB can only be true when ParamA is false, why am I asking for both?"). These often lead to more efficient implementations.

Write code EVERYDAY

Exercise your brain with math puzzules: ProjectEuler.net ^[1]

Read a book on Design Patterns or Refactoring. I'm in the process of reading one on each right now.

Write / blog about some coding problem, explaining it to the you of a year ago. Take some technology or algorithm that challenged you and write it down in a way that you think is so clear that "if only I'd read this a year ago..."

What you'll find is that you want to break down the steps into discrete functions. You won't want to use inaccurate or unclear names. When you do something tricky, you'll realize "I can either explain this in three paragraphs or refactor my code so that it's clearer," and that realization will help you understand if the issue really called for a tricky technique or, more likely, that with a small bit of refactoring you can make tricky programming less and less common.

When you write about programming, you come to understand that the readability and comprehensibility of code is deeply linked to code quality.

To expand on the prior post - "Teaching"...

A great way to expand your knowledge is to begin teaching a real class in a formal setting like a community college. By "real class" I do mean paying students.

The thing about teaching paying students is that they then have expectations of you. There is nothing quite like having to demonstrate real examples in front of a group with expectations to hone the skills.

Start with something you know very well. You will quickly discover just how much you need to learn! ;-)

Having said that, teaching is not for everyone. I liken classroom work to "tap-dancing naked in front of a large audience". You are on display, with all your faults clearly visible. It can be a rush, or a nightmare (sometimes both).

But nothing else will so clearly demonstrate just how much you have to learn as that.

As another bit of advice - forget the lectures. Lectures bore people unless you are a really gifted speaker. Besides, most lectures are just the same info found in the text. These are adults (at a community college level). What most learners at this level want is TONS AND TONS OF EXAMPLES. Don't use the simple examples in the text, but derive new ones based on the material. Especially work examples similar to the assignments.

I started out lecturing, and quickly found that it was the examples that captured the class. Sometimes the class format still requires lecturing (like if I'm teaching a multi-secion class and the lead instructor is preparing new powerpoints (yuk) each week), but when it's my class, I assume they have done the readings and just leap into examples.

Cheers,

-R

Sleep. I make sure I get plenty of sleep, so that my brain can run on all cylinders longer.

Try doing something by hand that your IDE will normally do for you. This forces you to actually learn many small things about your environment that you may not even know that you did not know.

And conversely, learn something new about your IDE too. Sometimes its worthwhile to go to an online tutorial for your ide and see what's new. You would be surprised that there are many things in the IDE that would make you a more productive developer and you may not even know about it.

I try and work out four days a week. Healthy body == Healthy mind

I read books (and magazines) on lots of different topics. It gives me a different perspective on things, both from a business perspective and from a design/development one.

I try to pick a question on SO that I have no clue about, and try to learn about the different things involved. I found that I learnt alot from this way, and you tend to get real life production problems that other users encounter.

There are several good points and answers already given. I'll add this:

It's a different class of programmer that programs outside of work hours, with no monetary compensation (at least at first). You get exposed to a refreshing and invigorating world when you step out into the realm of open source (OSS), and contribute to OSS projects, or even start up some of your own. Think about it: what would you think of a mechanic that worked on cars in his day job, but never worked on his own vehicles at all? Or a chef that cooked in a restaurant by day, but had no passion to cook at home? Or a musician that never played music outside of his place of employment?

My experience has shown me that the coders who are not involved in OSS at all are just stuck in the languages, tools and technologies they learned years ago. There is no desire to learn anything new, in any area, whether that is picking up a new version control system, or a new language, or a new build tool, or a new web browser, or a new UNIX shell, or a new window manager, or a new editor. They just want to come into work, bang out code to spec, then go home.

In the OSS world, most people are interested in cutting-edge stuff, regularly trying to push the envelope and find things that make process X flow better, or task Y easier, or to try out the next cool thing that is generating buzz in the blogosphere.

In my opinion, getting involved in OSS makes you a better programmer.

I like problem programming like Project Euler ^[1] to get yourself forced to code things you perhaps wouldn't do yourself. You can also see how other people did the problems in different languages.

Coding in "hard" languages like machine code or doing some more hardware-related stuff also can be very refreshing.

Analyze/Optimize your code. Either use a profiling tool for your language or write your own timer function (make sure it's accurate enough: in C# the Stopwatch class is very accurate, the DateTime class is not).

You're guaranteed to be surprised at what is making your code slow :)

Refactor til DRY, constantly, in different languages.

I don't jump right into coding when given a problem. I let the problem rest for a while then code.

It is not for everybody, but trying to raise two kids with any kind of authism, helps a lot:

• communciation, you need to be very clear to say what you mean. (And they are better than the best lawyers to find the loopholes).
• patience...
• react to new situations every day.
• and react predictable.
• keep yourself together.
• and try very hard, not to get angry.

And of course, wait patiently for the day you can teach them how to program.

And just a warning for you all, if you mix the genes of two geeks, you have bigger chance to get kids with authism or related effects. But then again, we like chalenges. (But we also like some rest...)

I run at lunch. On days that I run at lunch, I'm much more productive in the afternoon. Running helps me clear my mind or figure out things that are nagging me. It also gets me away from the screen for a little bit.

I play mind-exercising games that are different from what I normally do.

For example, Trivial Pursuit, Sudoku, Go, Chess, Pinochle, and many others.

Changing my patterns of thought make me think about things differently.

I also read-up on other industries, to see what processes they're using may apply to me.

Ditto with project euler

However, I tend to jump out of the IDE and go crazy in Notepad.

Tutorials. ... on any and all languages I can come up with. Granted, most of them are "hello world" kinda tutorials, but its always best when you know what else is out there other than your core.

Oh! and attend meetups, interact. Sometimes this ONE PROGRAMMER tells you this ONE tidbit that makes your code 200% faster or easier to read or ...

/mp

I recently discovered a blog that addresses this problematic. It's not updated anymore but it's still a valuable ressource : http://codekata.pragprog.com/

Change your keyboard layout to "Programmer - dvorak" and learn to type like that

I do problems out of books. Programming Pearls ^[1], CLRS ^[2], and tAoCP ^[3] all have exercises at the end of each chapter. Find a good textbook in the subject you're interested in and do the problem sets.

I like to review my old projects and rewrite them a lot of times in different ways and different languages. It always helps me to write better new projects.

Zen. Try to solve the problem, not the program.

One thing I've found is that as time goes by more of what I do becomes easy in the sense that I don't really have to figure out how to do it, so occasionally I'll spend a bit of time on a problem just for the sake of thinking about it.

(something from http://golf.shinh.org/ for example)

I also tend to think about how I would like to add certain features or change portions of things that I work on, even if I'm not planning to do so in the near future, as I've found that generally improves the design of the work I am doing.

There are some excellent answers above. However, my favorite it trying to abstract out reusable frameworks or toolsets form every app that I write, then refactor to make them efficient. Some times I only do this on paper for the mental challenge and not because I think I'll really reuse it.

I'm a language junky, and have spent my time learning lots and lots of languages of all different sorts of paradigms: functional, prototype, OO, symbolic, etc. "When in Rome, do as the Romans do" has always been my mantra when using a programming language. That is, I don't try to write REBOL as if it were C, or C# as if it were VB. I always try to write a language according to its own idiom.

So, how does this help you be a better programmer? It introduces you to new ideas, new ways of thinking, and makes you more flexible. Not only that, but you can see new ways of doing things in the language(s) you pay the bills with (as long as it's not forced and un-idiomatic). For example, learning Haskell has gotten me to use a bit more recursion in more conventional languages like C#, but only where it's clear, performs well, and it's practical to do so.

Also, learning many languages helps you understand languages in general. Things like scope, closures, objects, etc.

Read (in order of importance):

The Pragmatic Programmer ^[1] - This book was a total revelation for me when I read it a few years back. The practices contained therein are not about any language or tool in particular but instead are about the process of becoming a better programmer and being more effective both in personal projects and as part of a team.

Pragmatic Thinking and Learning: Refactor your Wetware ^[2] - This book is unique in that it's not so much about being a more effective programmer per se but about becoming a more effective learner!

Code Complete ^[3] - This is the only one on the list that I have to say I recommend with 'a grain of salt' - I agree with most of what Steve McConnell has to say but the style and some of the content are not exactly to my liking. Still, there are nuggets of real wisdom here that aren't to be missed.

here is a good article on the subject http://steve.yegge.googlepages.com/practicing-programming

Any time you're tempted to copy and paste code from somewhere else, hit your head hard against a spike until the temptation has gone away.

Then work out how to change stuff so that the same code is only written once.

• chose a number of the best programmers' blogs and add them to your RSS reader. this will keep you always uptodate and you will read about their best ideas and challenges they face every day and learn from that.

• read books about any cutting-edge technologies in your vacations.

• run for 30 minutes every morning to refresh your body.

• be part of an active online/offline programming community.

• discuss programming topics with others.

In short, I make myself a better programmer by programming. :)

Exposure to programming just through work isn't enough. I start up pet projects that touch technologies I don't generally get exposure to. I go through exercises in programming and algorithm books. As others have mentioned, I work on the problems at Project Euler. More importantly, I discuss the process with other engineers that I look up to and learn ways to approach and solve problems more effectively.

There is not one good answer. I am sure that there are dozens upon dozens, because people respond differently to different things. Here are some of the things that I do or have done in the past:

• Interact with your peers. Whether it is here, a newsgroup, or through user groups. A good combination of online and face to face interaction is great. When other people are asking questions and participating in a conversation, the flow is lead by more than one person - possibly taking a path that you did not expect.

• Share your own knowledge. By sharing your knowledge with others, they often will ask questions that will make you rethink your approach or point out something that you had not previously considered.

• Stay current. Pay attention to new tools and products within your area of expertise. Research upcoming products and see how they can be applied to what you are currently doing. Participate in betas and CTPs if you have the time to do so.

• Understand architecture. Coding is only one aspect of being a good developer. Understand some of the common architectural methods in various types of application development. Often you will gain an understanding to why something is done. They "why", in my opinion, is just as - of not more - important than the "how".

• Try to know your platform better. I have been enjoying books on subjects like architecture, performance, and scalability. It is incredible how many ways there are to do one thing, and there is a very good chance that they all do not work equally as well.

• Apply what you learn. Ask for more challenging assignments or things that you normally would not be involved in. Try to do proof of concept work and present it for the basis for a legitimate project to expand upon.

• Podcasts. There are so many to choose from. I can't keep up with the ones that I am subscribed to any more - but don't mind listening to them while working in the yard or in the car.

• Books. Yes, they still make them. I try to pick up a book every six weeks or so. It helps if you can expense them. If not, try to get two to four a year.

The best exercise is always to do the task. Solve real programming problems, not toy problems. Think of software you'd like to write, and the thorny problems will emerge, and you will have to learn to solve them.

This happened to me recently - I was programming what seemed on the surface to be a very simple multiplayer word game, and now I understand concurrency issues much more deeply than I did before.

Explaining things to others also helps. Making your knowledge intelligible to someone else has the beneficial side effect of clarifying it in your own head. In the work place, this is often referred to as the "Cardboard Programmer Effect" - you have a problem, you start discussing it with someone else, and in the process of structuring your thoughts for the purpose of explanation you solve the problem without any need for actual feedback from the other person.

I have found that the following have helped me in the past:

• Reading programming books, such as Code Complete, Framework Design Guidelines (if you're into .NET) or Programming Pearls. The best books are those that make you think and encourage you to find your own solutions to problems. Programming Pearls may be old, but it's still a classic in this respect. The same goes for Cormen's algorithm work or Knuth's multi-volume Art of Computer Programming.

• Buddy programming. Take turns in 'the driving seat' and develop a feature in collaboration with others. Not only is this occasionally a lot of fun, but you get to experience different programming styles and can mentor others if you have more expertise in the subject matter.

• Code reviews. This can include going over others' code in a work environment, or reviewing your own work some time after completing it. Often you can learn from your own or others' mistakes in addition to improving past work that you thought was done and dusted.

• Take a break. If you can't see the wood for the trees sometimes, then I've found that a break or a change can give me fresh insight into the problem when I return to it.

I hope this helps. Best of luck.

Pushups

Read others' code!