Lately, I have taken to programming without a mouse to force myself to become more comfortable with different shortcuts. It's been a good exercise as I feel using shortcuts is essential for productivity .

I figured I would ask if anyone else did the same types of things and could recommend other things to help improve my habits.

+8  A: 

Write code EVERYDAY

+5  A: 

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.

+34  A: 

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

Rob Prouse
Proj Euler is great for learning a new language too because you can do questions that you already did. That way you remove the algorithm from learning the language but at the same time it brings up structural differences between the languages if the previous algorithm doesn't work in the new lang.
I too have found this. Project Euler really is great :D
The idea of using it to learn new languages is an interesting one. I am always fascinated by the differences in the solutions in different languages, but I didn't think of applying the problems to actually learning new languages.
Rob Prouse
+21  A: 

Learn a new programming language.

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

+9  A: 

Exercise your brain with math puzzules:

Brian R. Bondy
+65  A: 


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

Mark Sailes
Dialogue in general is a good thing, be it teaching or just discussing things with your team. Everyone has some experience or knowledge that nobody else in the room does.
One of the strengths of Pair Programming.
I graded code as a teaching assistance in school. It was 96% boredom and 4% WOW. Sometimes the teacher gets taught.
And if you can't teach, blog about what you know.
And if you can't blog, apply for a management position.
I had a C++ tutoring gig while in school and learned a lot from teaching it to others. You don't know how much you don't know until you try to teach something to others.
Chris Ballance
+1 Very good answer. Tutoring others at university made me a MUCH better Java programmer AND person.
Helper Method
+3  A: 

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.

+1  A: 

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.

+1  A: 

Ditto with project euler

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

+1  A: 

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

+13  A: 

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.

Robert S.
I've been having the same google-dependent problem. It's nice to have knowledge at your fingertips, but even better to have it already in your head.
Hmmm.. Solved that problem: Most of my heavy-duty coding is actually for an open-source project which I work on, on my laptop, on the train to the office. No internet connection --- like naked savages!
James Curran
@James Curran, lol that made me laugh.
+2  A: 

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


+3  A: 

I like problem programming like Project Euler 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.

+1  A: 

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

+6  A: 

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.

Vincent Ramdhanie
+7  A: 

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.

Larry OBrien
+9  A: 

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

Mike Blandford
I am as well, actually. Design patterns, that is.
Sara Chipps
In the middle of Head First Design patterns now and next will either be The Gang of Four book, or Fowler's Refactoring depending on how Head First goes.
What book are your reading? care to share a link?
I would agree about refactoring, but design patterns are more controversial... some argue that they make people **worst** programmers. For instance see
No. Design Patterns do not make bad programmers. Bad programmers misuse design patterns.It's always best to look at what's out there before trying to reinvent the wheel from scratch. Doesn't mean you have to use it.
Mike Blandford
+3  A: 

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

Mike Blandford

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

Mike Blandford
Yeah, I'm a Dvorak typist.
Gregory Higley
That's a classic.
Ali A

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

+12  A: 

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

I carefully document my code (and sometimes other people's) 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.

James Curran
+8  A: 

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.




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.

Ryan Riley
+27  A: 

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.

Todd Hoff
haaaaaaaa, Todd I almost mentioned the one inch kill bill death punch in my question. You're a good writer..
Sara Chipps
Thanks. I may not always seem like it but I try :-)
Todd Hoff
Five point palm exploding heart technique...
Erik Forbes
+3  A: 

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.

at first I agreed with your comment, but on further thought, I'm not sure if it's the involvement in OSS that makes you a better programmer. Maybe it's just that people who care enough to be involved in OSS in their free time are more passionate about programming in general and therefore excel.
@Jay: That could be. But I think it's a good indicator. When making a hiring decision, I would prejudge a bit when comparing an OSS programmer with a non-OSS programmer.
But if you're not the kind of programmer I describe, getting your feet wet with OSS and getting involved in a project or language community will let you chat with those kind of developers, and you're bound to pick up a thing or two that will improve you.
+11  A: 

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.

Ali A
I just started reading a book called Brain Rules by John Medina and the first of the 12 principles it discusses is the effect of exercise - increasing blood flow and oxygenation to the brain!
Andy Dent
+3  A: 

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


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.

Gregory Higley
+1  A: 

I do problems out of books. Programming Pearls, CLRS, and tAoCP 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.

Bill the Lizard
+1  A: 

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.

Paulo Guedes
+8  A: 

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

People would be amazed at just how much difference two consecutive good nights' sleep can make compared to two consecutive nights of 5 hours or less sleep.
+1  A: 

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

+2  A: 

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

"ASS"?? You typed it twice, so I guess it's not a typo for ADD, but the best I can come up with is "Something Something Syndrome" (And I'm NOT gonna try Googling "ass"!)
James Curran
My bad, it is a Dutch abreviation for Authistic Spectrum Disorder
+2  A: 

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.

+3  A: 

Refactor til DRY, constantly, in different languages.


Read (in order of importance):

The Pragmatic Programmer - 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 - 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 - 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

Ronald Conco

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.

Gabriel Isenberg

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.

Dave R.


Ronnie Overby

Read others' code!

Helper Method