Stack OverflowWhat are the best habits of highly effective programmers?
[+130] [96] Vimvq1987
[2009-04-30 12:30:22]
[ improvement ]

I guess that many of you have read 7 habits of highly effective people [1]. They're great, but still too general.

Can you suggest some good habits of a highly effective programmer? The habits that make you more productive in work? Faster in learning?

(55) how could you link to something that uses the word synergize? :( - Zeus
synergize means to cooperate with another or others, so you can make a better work - DaDa
(14) "Synergize" is commonly regarded as an "industry buzzword" with little practical meaning/usefulness, so using (or advocating the ability to synergize) detracts credibility as an implied byproduct of too much marketing-speak. - Andrew Coleson
(10) "Synergize" did become an "industry buzzword", but it does have meaning. it's a 1+1=3 kind of thing. I tell you my idea, you expand on it, which sparks ideas with me, which sparks ideas with you, etc... at the end of the day we're both better off for cooperating. I hate buzz words too, but don't let it blind you to it's value. - John MacIntyre
(1) BTW-That should be Synergy not Synergize. - John MacIntyre
(6) How does this have a bounty? It's not like there is a correct answer. - Zifre
The "7 habits" book might have some buzzwords in it, but it is well known and a standard for a good reason. It certainly opened my eyes to some things. - MadKeithV
Zifre, it may not be the only answer but the best answer will get the bounty (in 4 hours from now) - Neil Trodden
[+212] [2009-04-30 12:35:01] plinth [ACCEPTED]

Don't be satisfied with an apparent fix; full understanding is the standard.

Right! Just the way it is! - DaDa
(16) Absolutely, if you can't explain it or don't understand what caused it and where in the code, you didn't fix it! - torial
Yup. If you don't know WHY it broke in the first place, your "fix" isn't likely to hold. You've essentially left a land mine in your code. - BlairHippo
You must perform an ABAB trial. State A: broken. State B: you apply fix., re-test State A: undo change, fails same as originally. State B: fix applied, re-test. This gives some confidence that you can manipulate the critical variable. Look up "experimental design". - Tim Williscroft
(2) Does that go down to the electrons moving across the wire (or traces, as it may be)? Not to rain on anyone's parade, but I really doubt any of us have "full understanding" of just about anything. Reasonable confidence is the best I hope for in a day... - Mark Brackett
(2) @Brackett, You can't have a full understanding of anything. The goal is to understand what you wrote, not how it works (thought that sounds like the same thing). - strager
You should have a more-or-less accurate mental model of how the electrons go across the wire which goes all the way up to the observable behavior of the application. It doesn't matter if you have details wrong unless those details start leading you to false conclusions, in which case you should fix the details. - mquander
@strager You need to understand partial/fully the CPU (assembly) to write efficient code, so your conclusion is absolutly wrong - Quonux
I disagree with this. The only details that really matter are the underlying mathematics... All the rest tends to represent a "constant" overhead. - Pedro Morte Rolo
[+163] [2009-04-30 12:33:50] Gus

Learn how to close SO and get to work...

Seriously though, working with a computer brings around a lot of distractions, and that is something I fight a quite a bit. One solid habit that good programmers have is that they work on focusing. I don't personally believe that this is easy for any programmer, so it becomes a habit that you have to embed in you.

(3) That's very true! Damn, I need to get back to work... - John Topley
(130) StackOverflow has been THE single biggest distraction from my job ever. - TheTXI
(7) So true. Thank god for the 200 rep limit. :) - Emil H
(6) i think we should work without internet connectivity !! - Yassir
(1) I was going to say exactly that: I am so much more productive if I have to work without any internet connection, it's incredible... - none
How the <censored> should we work without Google, though? - Arafangion
How does the rep limit help? It doesn't, in my experience. - Mehrdad Afshari
This is a big problem for me trouble is you need the internet often in the day - PeteT
damn, you got me. - Victor
(1) @Emil, @Mehrdad The rep limit is a bad thing, cuz you know you have a daily duty of 200... - Shimmy
I think that the time invested in stackoverflow ends up yielding something. I would even classify it as a long-term investment. Though, as any investment, it also has risk. ;-) - Pedro Morte Rolo
[+120] [2009-04-30 13:16:20] MattH

The 'original' 7 habits adapted for programmers...

Be Proactive: Take initiative, both in understanding and in problem solving.

Begin with the End in Mind: What problem are you solving? What is the best solution? How will you know when it is solved?

Put First Things First: Set priorities. Use good judgement. "Premature optimization is the root of all evil" - Knuth.

Think Win/Win: During design/collaboration, what is the best solution for all parties involved?

Seek First to Understand, Then to be Understood: First understand the problem and/or the person for whom you are solving the problem.

Synergize: Work with others to gain a greater understanding.

Sharpen the Saw: Always be learning. Learning about new technologies. Learning about the business, and the business of software.

"Premature optimization is the root of all evil." - By far the most abused, misused, and overused computer quote ever. Except for perhaps the "Now they have two problems" regex quote. - Robert Harvey
[+88] [2009-04-30 12:35:47] Justin Niessner

Always willing and able to learn...

If you don't keep up with the times, you won't be a developer very long.

(39) +1, either "you won't be a developer very long" or you will be a crappy developer for a very long time. - Brian Ensink
tell that to all people that are still working in very old technology. - IAdapter
agree with this, one has to constantly learn - Michael Ellick Ang
Well said Brian. You must have the propensity to always be learning something new. - Chuck Conway
[+71] [2009-04-30 12:45:09] Steve Haigh

Fix Broken Windows [1].


(12) even when they are really boring to fix. - dr. evil
(2) Microsoft has been trying to do that for years! :P - alex
[+65] [2009-04-30 12:33:30] Nebakanezer

Master use of Google. It's a programmer's best friend. The quicker you can find what you're looking for, the better.

Edited for clarification: What I was really getting as was the ability to be resourceful and self-sufficient. Google is just the first tool that came to mind. I wasn't implying that one should use Google to build their application, but, as an example, the ability to find a specific snippet of code quickly can come in handy on a few occasions.

(2) is it jus me or are 50% of answers = Google Oo - n00ki3
(56) I don't know. You should Google up some statistics. - Grant
(5) You don't get maintainable code just by using google. In my experience, bad maintainability is the main reason why productivity becomes really poor. Google "has" all the answers, but you have to know what you are looking for, so you almost know it yourself and just look up the details. - Stefan Steinegger
(3) I would add that being able to find resources by yourself makes you a better asset in general. The real skill in using code out in the wild is being able to evaluate that code and to graft it into your codebase. Anyone can copy and paste. - Min
(1) If Google makes your application, than it's poor programming! Hopeless, I would say! - DaDa
(5) stackoverflow seems to be better than google (couldn't believe I would say 'better than google' someday) when the technology is "newer" - ByteNirvana
@ I would say to master Google by Vim's K shortcut. - Masi
(1) You should master Google and control yourself: when and how to use it, to prevent copy-paste programming. - Vitaly Polonetsky
+1 for the edit... - Shimmy
(1) But you can't alway google for specific complicated answers, for this purpose SO was constructed, don't you remember ;) - Quonux
[+34] [2009-04-30 12:33:03] Francis

Close and kill any e-mail reader program/clients.

That really saves a lot of time.

(2) and cut off your network , phone and cellphone , close and lock the door(if you have a separate room), wear your earphone and start learning/coding! - linjunhalida
@linjunhalida it really works !! - Yassir
I always find myself bz closing opened windows, am i the only one here with this obsession? - Shimmy
[+30] [2009-04-30 12:40:31] Stefan Steinegger

From my experience:

  • Makes things work first
  • Refactors and keeps his code clean


  • distinguishes important things from trivial things
  • doesn't get lost in details
  • does the minimum to solve problems, does not produce exorbitant solutions

[+28] [2009-04-30 13:08:25] Brian Rasmussen

Don't assume it - prove it. In other words: don't base critical work on unverified assumptions. Make sure the foundation is sound.

only dijkstra and knuth do it. - Peteris Krumins
(10) Assumptions are only dangerous if they are not documented and brought out in the open. There will always be assumptions. - Robert Gowland
@Robert - that's a fair point, I guess you could reword it to something like: if the assumption is really important, you better make sure it actually holds. - Brian Rasmussen
500 years before the Common Era there were two philosophers living in different cities: One said "You can only trust your senses", the other said "you can only trust your reason". Both were wrong, and both were right. Find a balance. Don't limit yourself to watch the shadows in the cave wall. - Pedro Morte Rolo
[+25] [2009-04-30 13:05:24] Ed Schwehm

Understanding that the answer is always "It depends".

(2) Good answer. From a person who has long understood that it depends, I'll get a good solution for the circumstances. From someone who thinks they know best practices that always apply, I'll get something that sounds good. - Patrick Karcher
[+20] [2009-04-30 12:33:49] Galwegian
  1. Writes software with few bugs.
  2. Writes unit tests.
  3. Delivers code on time.
  4. Shares knowledge with team.
  5. Communicates well.
  6. ...
  7. Washes.

(4) 'Writes unit tests' should (and normally does) come before 'Writes software with few bugs' - Matt Lacey
(7) +1 for Washes! Up until half a year ago I took this for granted. Nothing distracts more than an olfactory disturbance in the room. - pi.
#5 is very VERY important. - Xorty
[+20] [2009-04-30 13:49:47] johnny

“Try not. Do, or do not. There is no try.” - from my buddy Yoda.

(23) That's the comment I put in empty catch clauses. - Joshua
[+19] [2009-04-30 12:53:52] OderWat
  1. Be fascinated in transforming problems into data structures and algorithms
  2. Check all available tools for every task, select only the best for your work
  3. Learn different programing languages and do the same in all of them for practice
  4. Understand that the computer is always right (this is the key for bugfinding)
  5. Make use of other people code but understand how it works
  6. Find something to balance your mind (like sports and art)
  7. Never accept that something "seems to work".. understand why it does! always!

it's algorithms not algorythms - Peteris Krumins
(2) ty for the correction. I am german and sometimes have a hard day in writing good enough english :) - OderWat
[+19] [2009-04-30 14:06:45] Gulzar Nazim

Take ownership, willing to accept mistakes, positive attitude..

Follow principles like DRY, KISS..

Never stop learning..

Don't take ownership of the code. If you coworker has a better solution use it! - ByteNirvana
(1) DRY--that would be my #1, a programmer must be completely unwilling to duplicate himself--every copy/paste should feel like a knife wound in the shoulder. - Bill K
For others, put a link for DRY and KISS so they know what they mean. - Thr4wn
[+16] [2009-04-30 13:38:06] Brett Douville

Minus promitte, nivus perfice.

Loosely translated: under promise, over deliver. Your customer wants a widget that does x; promise him x, but give him X, a better, more configurable widget that solves a few problems that are related.

What if they only actually wanted x? Beware feature creep! Of course it depends on how you define "better, more configurable" since that doesn't necessarily mean "extra features." - Andrew Coleson
(2) Just don't give him the documentation for the extended feature set until he asks you to extend it... then you can look like the wizard adding the extras when really all you've gotta do is write the documentation for those features... which you already have waiting on the sidelines to insert into the production documentation. - BenAlabaster
(1) Most of the time, the customer will be happy with LESS than what they ask - they often don't realise just how much they ask for! - Arafangion
[+16] [2009-05-01 05:29:02] Frederic Morin

Don't overengineer [1]

Edit: For me, it means, don't overdo something. Make only what's needed to be done and trust yourself for the future. Also, keep the complexity at the bare minimum. For example, don't use interfaces or proxy or whatever pattern you have on your mind on a beautiful day just for the sake of it. Keep it simple !

More info: SO: overengineering-how-to-avoid-it [2]


(2) Blade: This really needs more elaboration, not just a link, as good as that link may be. - Arafangion
I second that! please elaborate. - Decio Lira
Here's a slice of my exeperience with overengineering. Hope it clarify things. - Frederic Morin
[+15] [2009-04-30 16:46:21] Anders K

Split problems into smaller, more understandable tasks.

Try to design a solution in your favorite editor about the problem before coding - get rid of the feeling that if you do not code you are not being productive.

Always have unit tests, it's a life saver.

Try to keep things as simple as possible, verify this by explaining your design to somebody else - doesn't even need to be a programmer!

Never be afraid to ask questions.

Never assume anything, whether it is assuming knowledge by a manager or an end customer.

Don't take verbal requirements, all requirements need to be written (even though they may change, it is good to have them written down to better understand them).

Really Good. I like the most the first one: Divide and Conquer - backslash17
[+15] [2009-04-30 18:37:04] Piotr Czapla

Keep in mind "80/20" rule and constantly ask yourself: "Do I really want to do this that way?".

But as Joel said: The 20 varies widely. - Lucas Jones
-1 because this rule is bullshit... - Quonux
[+13] [2009-04-30 20:52:30] Huntrods

Dig deep into the question when a client requests something. Don't assume because they ask for a program they actually NEED a program. Be willing to ask questions until you get down to the actual business problem they want to solve. Then look at ALL the possible solutions, including those that don't even require a computer.

Not every problem is a programming problem.


[+11] [2009-04-30 18:29:02] Chris Simmons

If you're interested in getting some books on general development best practices, I suggest these:

They're much quicker reads than some of the traditional best practices texts ( Code Complete [3], I'm looking at you), and offer specific techniques that can help you improve.


[+10] [2009-04-30 22:12:58] Matt

Use other ways to visualise a problem - I've lost track of how many times I've been stuck on something, or procrastinating about something complicated, and found that by just drawing a simple diagram or flow chart of the code I was able to quickly see what the problem was, or how I could improve my code.

I think the problem is that because I spent 8+ hours a day on a keyboard, I forget to pick up the pen/pencil next to me occasionally.

[+10] [2009-05-01 11:37:36] Scott Langham

Produce Value

Don't spend time working on something that doesn't have business value. For example, doing something in the latest fancy technology just because you want to, when there's a quicker way to achieve the same result with well understood tools. Note, I'm definitely not saying don't make progress and don't move forward.

Effective programmers don't get carried away with the technology and the means of producing something as a thing in itself, they get excited about actually producing something that's of high value to someone.

Focus on this, and objectively reflect on whether you're currently doing the thing that will produce most value. Programming takes a long time, so there isn't time to waste working on something that isn't the most useful thing you could be working on!

[+9] [2009-04-30 12:42:00] sharptooth

Questioning your own solutions and looking for ways to do things better.

[+9] [2009-04-30 13:03:35] Vinnie

Learn your tools - especially the functionality in your IDE that will help you be more productive - the debugger, refactoring shortcuts, profiling tools. These are small investments which will pay off big in productivity.

[+8] [2009-04-30 12:37:01] Alberto Zaccagni

Discuss what you have modelled/written/thought with others, even though (and most likely if) you are sure of what you did.

[+8] [2009-04-30 17:11:05] Aaron Daniels

I don't know if this qualifies as a habit, but communication is key to being an effective developer, imho. If you cannot communicate your ideas, intent, and even source code to other people, your skills will never be fully valued.

To get hired by a good company, work on a contributing team, and work on worthwhile projects, you need to be able to deal all sorts of different people.

Unfortunately, many of us, including myself, are the epitome of introversion. Effective developers seem to be able to conquer this.

+1 for learning to comunicate! That cannot be emphasized enough. - Decio Lira
[+8] [2009-05-15 03:41:55] Alex Jenter

Keep a daily todo list and leave a little and easy task as a "hook" for tomorrow (and maybe for after-lunch), to ease yourself getting back into the programming flow.

[+7] [2009-04-30 12:33:07] TheTXI

Obligatory Programmer-Fiction References - Caffeine and Hot Pockets

Serious/Semi-Serious Answers - Never willing to settle for what you know at this very moment.

in the morning to you - Tim Abell
[+7] [2009-05-12 16:34:59] Evansbee

The best habits of highly effective programmers have nothing to do with programming. People assume that programmer's grow by learning new algorithms and languages. This is true to an extent, but let's not forget that problem solving is the basis for our entire profession. In my opinion, the best habit of a highly effective programmer is to be well rounded such that they can learn how other people solve problems that are unrelated to the programmer's field. Get out and take photographs, learn an instrument, become an arm-chair nutritionist. There are many things that we all can do that will help us grow in ways that we would other wise have not found.

[+7] [2009-05-15 11:04:00] VVS

One thing at a time. Multitasking kills productivity. Seriously.

[+5] [2009-04-30 13:45:06] Sherri

Be accepting of change

I've suggested several improved processes or ideas - like let's try to organize our classes uniformly, or let's add security testing to our standard testing procedures. But I'm often met with a "we've always done it this way" or a "you can't expect everyone to follow that rule" response. Developers get stuck in their ways too often and it can bog down progress. Especially when people have some long-standing but out-dated techniques. For example, many of our projects continue to get developed in classic ASP, because "you can't expect everyone to learn .NET".

[+5] [2009-04-30 16:14:13] DaDa

Don't have mercy to delete all your source code!

(1) But don't go overboard: - Runcible
[+4] [2009-05-15 11:20:19] jens

DRY - Don't Repeat Yourself. Make it a habit to never easyily accept duplication in any form: - writing the same code twice - performing the same manual installation steps again and again - making documentation by copying the same content to several locations - stepping through pages of QA protocols before every release

This principle first of all does not make you lazy - though this can happen :-) - but helps you to focus on automation, simplicity, consistency. Sometimes you are forced to enlargen your toolbox, which is good either.

[+3] [2009-04-30 14:37:34] Gushiken

Habits? Okay, here are my suggestions for the 7 most important habbits of a programmer:

  • don't think too complicated

Most of the time a solution for a problem is much easier than you would expect. Try to find this easy way.

  • be critical to yourself and about your skills

If you stop being critical to yourself, you will stop making improvements.

  • accept your own mistakes, and try to prevent them the next time!

Everyone makes mistakes. Don't try to abadon them.

  • Use what you have learned

Just because you know that you should write comments, use principles like KISS [1] or something else doesn't mean that you are a good programmer, until you do it.

  • be interested in new technologies

Especially at the moment, it's important to be interested in new technologies. If you are not, you won't be going on as a developer for very long

  • always have coffee near you if you are programming

Very important. No coffee, no ideas^^

  • don't sleep too much

More than 6 hours of sleep are lethal for your programming skills :D


[+3] [2009-05-01 05:02:58] MrDatabase

Highly effective programmers create maintainable products that other people like and purchase.

[+3] [2009-05-13 19:08:21] Maciek

Some of the habits posted so far are fantastic. Here's mine:

Take mental breaks and listen to the perspectives of other programmers.

There's a scene in the movie Pi where the character Saul, an old mathematician, describes the story of Archimedes wrestling with the problem of measuring the mass of gifts given to the King to determine if they have real or fake gold in them. Frustrated, his wife tells him to go take a bath and relax. Archimedes takes a bath and solution occurs to him while soaking in the tub. Displacement of water can measure mass. He famously shouts "Eureka!". Saul finishes the story and asks the other character, Max, what the moral of the story is. Max replies: "that a breakthrough will come". Saul replies "Wrong! Listen to your wife, she will give you perspective! You need to take a bath!".

In other words, brute force rarely works well on finding the solution to vexing problems, but taking a break and discussing the problem with other folks, or even discussing something else, can do wonders for the background processes of your brain.

Many programmers here would agree there are diminishing returns to working extremely long hours and killing yourself while trying to be the hero programmer. Sometimes you just need to take a bath :).

[+2] [2009-04-30 13:17:30] Mike Robinson

Be a pessimist

It is a sort of Murphy's Law! - backslash17
[+2] [2009-05-01 01:10:57] phillc

Social Life

[+2] [2009-05-11 17:49:00] BenAlabaster

I don't see these 3 very basic skills mentioned here in this order:

  1. Listen
  2. Understand
  3. Think

[+2] [2009-05-12 22:20:23] jplindstrom

Programming is about...

Keeping track of all the details

While programming you will see things in the code base and think about things that, if you tend to them there and then, would distract you.

This can be anything: telephone numbers to call, noting that a class needs refactoring or bug fixing, the next three things to do, test data, file names you also need to check, and what to talk about in Scrum.

These other things are important, but it's also important to complete whatever you're doing right now.

Keep track of all these things in a journal / a todo list / a scratch pad / a notebook / whatever.

This can be as simple as a text file where you separate your notes with some newlines. Actually, the simpler the better. Key here is the ability to extremely quickly offload your thoughts so you can come back to them later.

Sometimes this isn't the right place or format to store this information, but it's important to have a default place to write things down. You can always move it to a Wiki, shell script, document, source file later on.

The same way of working can be used for shell commands, SQL statements or anything else that would be more effort redoing the next time you need it. You're essentially cheating by copying the solution. From yourself.

Personally I use Emacs org-mode which, amongst other things, is an outliner. This way I can very easily keep track of which things are todo, just idling, and done. I can easily keep the important things expanded and visible, and hide things thath are irrelevant at this point, or already done.

[+2] [2009-05-13 12:54:21] Paul Nathan
  • Planning
  • Take notes
  • Not putting things off
  • Be interested
  • Overdocument
  • Listen to other people
  • Have perspective

[+2] [2009-05-15 14:15:25] Jimbugs

Keep code simple. Simple "ain't" easy.

Amateur code can often be identified by modules at all levels (including libraries, classes, methods, etc.) that try to do too many things. Ultimately a single task is enough, but there is room for some elaboration. When additional tasks for a module are discovered they should be refactored out into new modules. This is often scary or tedious (depending on how confident the programmer is) and so it is sometimes avoided.

Deep nesting is another indication of overly complicated code. Some advocate using no more than one level of nesting. The important thing though is to examine why the nesting was introduced in the first place. It probably indicates multiple tasks depending on various conditions. Factor out those tasks to separate modules.

The very difficult task of taking already complicated code and simplifying it leads to code that is less likely to have bugs, but more importantly to be far more maintainable. Future modifications to that code are much less likely to cause side effects. (Don't get me started on purposely using side effects :)

This quote from the link sums it up.

"It’s not about making the computer do the right thing. That’s easy. The hard part is helping humans understand what is happening." [1]


Excellent! This is what it's all about. - Patrick Karcher
[+2] [2009-05-15 17:40:21] azamsharp

I think we should focus on the simple things since being simple is beautiful. We should focus on managing our tasks, sleeping 8 hours a day, exercising, not multitasking, writing unit tests, automated builds, learning to use new tools, reading articles, writing blog posts, working on a side project, taking part in discussion boards and forums.

These are all simple things that most of you already do!

The main point is do what makes you happy! If C# is not for you try Ruby!

In the end the more comfortable you are with your life the more effective you are as a programmer.

[+2] [2009-05-16 12:39:30] winden

Attaining this requires a lot of willpower, but works fine and does wonders:

  1. Take the last half hour of your work day to plan the next day

  2. When making the list of what you want to do, put the most complex thing first in a big block

  3. Next day, do that first even before checking email and stuff

  4. Come mid-day, do your mail and usual office chit chat

  5. Do another 2 stretches of work on smaller items

  6. Final mail run

  7. Plan next day...

The strongest part is actually closing your email, im, news reader and social site while working, and opening it just for the time you are going to focus on it. If you can work on your own machine and don't need the internet connection, the simplest way of achieving that is to just unplug the network cable / turn off the wifi. Works wonders! :)

Unplug from the internet is very drastic! - Luc M
I don't advocate disconnecting from the internet, just stop being interrupt driven and be task driven. Read on interrupt mitigation at the NAPI page there... - winden
[+2] [2009-05-16 15:23:17] Richard Hein

Don't give up.

[+2] [2011-01-26 21:47:19] PraveenGorthy

Fix the cause, not the effect.

As programmers we often come across situations where we are try to fix an issue. It is generally easy to find the problem and fix it. Many times we do not have time or awareness to search for the cause of the problem. This can lead to many problems and a highly inefficient code base over a period of time. Even if the time factor forces you to fix the 'effect', you should make a note of that and make it a point to correct it sometime later. This will help you build a clean and maintainable code base.

[+1] [2009-04-30 13:17:47] kent

Nomenclature / language and terminology.

How you name your classes and methods / functions is a critical measurement for how well you yourself understand your design. AND how easily others will be able to interpret it...

[+1] [2009-05-02 10:11:33] Blerta

Create a comfortable work space that suits you. Whenever you don't feel like working do something else that cheers you up and brings your inspiration back.I don't know maybe you should take a walk, drink some coffee, talk to somebody it's up to you. I think this is the most important habit one should have on their minds. Because at some time you feel like not working at all if you don't do anything about it time will pass by and your work day will be over without doing anything worth in the office.

[+1] [2009-05-10 04:19:06] Raphael Montanaro

If you mean productive too, there are a lot of great tools. Two Windows tools that I use:

I would recommend The Productive Programmer [3] as well. See, all the way to program, from starting the SO to the IDE can save you time and make you much more productive. Cant imagine working without multiple clipboards [4].


[+1] [2009-05-11 17:08:46] Jeff Ferland

Either be Jeff Atwood, or read his blog:

Long footnote: Jeff Atwood is a creator of Stack Overflow, but I've been reading his website long before SO came into being. The things he discusses, and the way he presents them, provide for the best representation that I'd give to anybody who asked "what should I be doing?"

sucking up. is that a habit? - Jeremy Samuel
[+1] [2009-05-11 17:37:41] majkinetor
  1. Theory - every day learning.Don't think like some people - I did enough of learning, now its time for pay day.If you don't learn every day, even the stuff distant from your main job, you will not understand the big picture of things, u will become borred and will start thinking in patterns.

  2. Try to be open minded. If X people did it one way, that doesn't mean that way is OK. It might be OK, but there can be better solutions. 1) is the double bladed sword - too much theory can make a man to think in patterns.

  3. Automate If you have to repeat things 3 times, don't. Make a program. What program, what language, that depends on 2) and 1)

  4. Don't underestimate newbies. Sometimes n00b can give you better advice then a pro :)

[+1] [2009-05-11 17:51:05] icemanind
  1. Always Comment! The more green, the better. Even if something is obvious, comment it anyway!

  2. Always test, even the smallest and least signifigant change. When testing, do unexpected things, like purposely hitting the wrong key or misclicking.

  3. Visio is your best friend. Chart out and diagram everything. If something needs to be changed later in the program, you should be able to visually see all changes that will be affected.

  4. Program lasagna code, not spaghetti code. Layer everything. Create your program so that a piece of it could be taken out or changed without affecting anything else in your program.

  5. Do not overengineer. If you find yourself using wierd loops or lots of nested IFs or that 4 letter 'G' word, "Goto", then you may want to rethink your logic.

  6. Do not obfiscuate your code by trying to make shortcuts. Once upon a time, computers only had like 4K of memory and compact code was essential. In this day and age, computers have plenty of RAM and hard drive storage. Do not try to "compact" your code or take shortcuts to programming.

  7. Write software, but do not write a software manual. OK, not literally. This may sound nuts at first, but the point is, make your software so intuitve that a manual is unnecessary. Put yourself in the customer's shoe. What would a really stupid person do?

"Put yourself in the customer's shoe. What would a really stupid person do?" :D nice ending... - Peter Perháč
(1) Re. commenting: pointless comments that repeat the code add no value (and are just extra work to maintain). Explain why in comments, and if not needed don't comment. - Richard
(1) commenting should only be done for things that can not be put in the code itself. Proper naming of variables (and intermediate results) can REALLY get you far. - Thorbjørn Ravn Andersen
[+1] [2009-05-11 18:11:32] Peter Perháč

If a Windows user, DITCH, FORGET, ABANDON Windows Explorer. Start using a tool like Total Commander,

Total Commander is a shareware Orthodox File Manager (OFM) for Windows. Some features include a built-in FTP client, file compare, archive file navigation, and a multi-rename tool with regular expression support. ( Wikipedia [1])

I curse every moment I have to spend looking at fellow developers while they switch between a dozen of WE windows, drag-and-dropping, right-clicking, figuring out how to get simple tasks done (like looking inside a JAR file or previewing the contents of ANY file, etc.). It takes them forever to achieve what I can get done in seconds. And on countless occasions, my colleagues barely noticed when and how did I do this-or-that. "Neat," is what they say when I show them how effective I can be with Total Commander.


-1: Better to learn scripting for your tools and automate repetitive task. - Richard
I must disagree with this. Total Commander has some good sides, but it does not share the context menu from explorer. This means that integration with svn and many other tools don't work. - tomjen
??? What in the world are you both talking about? Ever noticed the key to the left of your right control button? That will bring up the context menu if you're absolutely desperate for it. Or right-click and hold for a second. I am using Tortoise SVN and CVS from Total Commander. Your comments just go to show how very little you both know about Total Commander. @Richard, command line basically sits below the panes and you will never ever need to Right Click to Open Command Prompt in Directory it's already cd'ed to the currently open position. command-line scripts are saved, so +1 for TC :) - Peter Perháč
[+1] [2009-05-11 21:38:43] Jason Williams

Try to solve problems in the clearest, simplest way.

Don't waste time prematurely optimising. Only optimise something after your program is proven to be too slow and your profiler has isolated the root cause.

Comment everything you do clearly. You'll thank yourself a month later when you have to revist the code and work out what you did!

[+1] [2009-05-12 19:34:01] Gus Paul
  • Keep things simple. Design patterns are guidelines not instructions.
  • Use source control for everything and check in early, check in often
  • Start you unit test project on day one. Don't leave it for version 2.
  • Code reviews - at least one hour twice a week even on a small project. Either online (using telephone/in person) or offline (e.g. using a tool like crucible)
  • Exception handling is for errors not a replacement for if statements
  • Profile your application regularly for performance hot spots.
  • Keep your coding standards simple and written down so they can be given to a new team member on day 1. Enforce them even if you don't always agree with them!

[+1] [2009-05-13 19:35:59] thisismydisplayname

My 3 cents

1) Status: Always update you boss and your team about the status of a task you are doing. The faster you think you need help, the faster you will get it!!

2) Never Assume: Dont go into a project assuming that a=b or anything of the sort, if you have a inclination towards one solution\implementation over the other - make sure its what the client wanted or there will be trouble [read rework!]

3) No specification = No idea what you are doing: The best habit i think you need to inculcate is getting the specs of the task at hand. I am just awed at the num of times the boss will wait for you to ASK then pass over the specs info.

In short, if you can tell them what your doing [#3], when your doing it[#1] and why your doing it [#2] will be fine....thats until the boss decides he doesnt like the tie your wearing....

[+1] [2009-05-13 21:58:49] Thorbjørn Ravn Andersen

The best advice is probably

  • Think things over before doing them.

This includes not jumping straight into coding, talking things over with your colleagues (they may know stuff you don't - algorithms, libraries and stuff), consider if massaging the data you have a little may make your code much simpler. etc.

Then some runner-ups:

  • Be conservative!

Don't use the framework of the week because it does something in a new interesting/fun/challenging way, because then every project will have its own framework which nobody really knows and nobody WANTS to know. Keep it simple, it pays.

  • Be predictable!

Decide on a coding convention and use it. We have Eclipse fixing imports and formatting the source on every save -> everything is always correctly indented and formatted. Saves time for the maintainers since things look the same everywhere.

  • No warnings!

The code should be clean and compile without errors and warnings. This gets rid of a lot of pesky problems usually showing up in late night hours. This naturally only works if the warnings were not just suppressed but actually fixed :)

  • Keep statements on a single line. No breaks.

This actually has more to it than it seems. One is that nested if's gets to get refactored into methods. Another that a lot of helper variables are necessary, and these can be given meaningful names. The third is that I personally think it is nicer to read and easier to understand.

But this is for coding, not for habits. Personally I hear music while coding, and have a quiet office otherwise. I can only strongly recommend:

  • Have a quiet working space

This is much more important than many think. Noise stress you...

[+1] [2009-05-14 15:49:16] Aaron Digulla

From the wall of a corporate building in Zurich [1]:

  1. Do One Thing at a Time
  2. Know the Problem
  3. Learn to Listen
  4. Learn to Ask Questions
  5. Distinguish Sense from Nonsense
  6. Accept Change as Inevitable
  7. Admit Mistakes
  8. Say It Simple
  9. Be Calm
  10. Smile

I used PowerPoint to create an image from that. It's not my desktop wallpaper.


post it on flikr :D - solomongaby
Can't; the image behind the link is not by me. And I have no license to put a PP layout on flikr. - Aaron Digulla
[+1] [2009-05-16 05:27:29] SeasonedCoder

Cope with procrastination, roll up your sleeves, and do the job.

[+1] [2009-05-16 09:30:04] goldenmean

I have seen real good programmers. Most of them have following habits/traits -

1.) Learn more than 2 programming languages - e.g. 1 structural (C), on OO (C++/Java), one dynamic language quick but powerful e.g. Perl, Bash, Python, which enables to do them tasks around their main project task.

2.)They Are really good in understanding others code. They almost dive into any unknown code and figure it out to a point where they can use it,change it,re-write it.

3.) Consider no work as small/trivial. Do every activity with equal seriousness and thoughtfullness.

4.)Have a very large working memory, which enables them to keep many things which they are new to, or dont know in thei 'working memory' so that they can apply those things more and more, and in the process they get it clearly understood or they can find a reference to these concepts in some other place from which they understand it.

5.) Tremendous confidence in their abilities which enables them to take up any unknown task, difficult task and yet they can apply their knowledge and skills and deliver in it.


[+1] [2009-11-25 21:08:29] Matt H


Sorry for shouting that out but I can't stress that enough.

Reason: the prototypes usually become the real product.

When you code don't take shortcuts thinking - "this is just a prototype, it'll never be used in the 'real world'" - hehe... year right! You'll regret it later. Or more like, someone else will be cursing at your code in the future! The joke is, that person might be you several years later when you have forgotten what you wrote. :)

[+1] [2011-02-14 19:07:22] ams

My choice for Habits would be.

  1. Understand the problem before you write the code
  2. Pick good names and refactor when you find better names for things. code will be read for many years after it is written.
  3. You are a professional you don't need permission to refactor your code or apply best practices such as unit testing to your project
  4. Get familiar with the Software estimation paradigms read (Software Estimation Demystifying the Black art by McConnell)
  5. Master your tools and become a tool power user (IDE, Source Control, Bug Database, Continuous Integration)
  6. Focus on mastering the paradigm not just the technology (example focus on OOP and not C# or Java, Messanging and not JMS or SOAP ... etc)
  7. Study programming language paradigms object oriented, procedural, functional, aspect oriented ... etc

[0] [2009-04-30 13:52:22] Jeffrey Chee
  • Learn the tricks of the language, but do not be too eager to jump to a particular trick or design when writing code, try to find reasons for using that trick or design. What are the drawbacks of using that trick or that design?
  • Keep It Simple Stupid, is your code going to be readable with a simple glance?
  • Break up the feature into smaller simpler chunks where implementation will be easier
  • Refactor your code whenever you see the chance, less code is always better than more code

[0] [2009-04-30 18:07:28] yetanotherdave

Adding to what has been said already...

  • don't add too much between compiles
  • check-in often when working on multi-developer teams
  • use CI and set a threshhold for code coverage and stick to it
  • understand how to build your code without the IDE, otherwise the IDE becomes a crutch
  • train yourself to spot reoccurring design patterns
  • learn the standard data structures and when to use them
  • don't be afraid to write your own utilities - even if you end up buying comercial solutions later

[0] [2009-05-01 04:18:48] Walt Gordon Jones

Participate in problem solving, analysis, and brainstorming with other programmers. This is so important, and why Stack Overflow is actually GOOD for your productivity.

Another thing I'm not seeing in the replies... Write tests. I don't always follow strict TDD [1] or BDD [2] practices, but writing tests helps you understand the code better, and it will absolutely find problems in your code (that you thought was solid).


[0] [2009-05-01 04:20:38] Andrew

Don't try and fix every bug. Pick your battles.

[0] [2009-05-01 05:07:42] Evan Meagher

Maintain a desk/workspace that suits you. Whether this means a pristine desktop or piles of notes and books everywhere, the physical environment that you work in is very influential to how you do work.

[0] [2009-05-02 14:35:19] Nicolas Dorier

Can code without a mouse, and know a lot of tips/hotkeys to use his operating system 2 or 3 times faster than a basic user.

[0] [2009-05-11 17:24:17] Bogdan Gusiev

Only a lot of refactoring and Unit tests can save your soul.

[0] [2009-05-12 22:42:41] Liran Orevi

Know thy libraries - designing towards and using preexisting functions will increase the productivity and reduce the likeliness of bugs, just make sure that the libraries are good, and you've read the All the related the doc Before.

[0] [2009-05-12 23:46:12] DanM

Make it go, then make it better.

Avoid premature optimization.

Comment as you go along.

Use unit tests.

Each building block needs to be solid before integrating it.

When integrating add one thing at a time.

When debugging change one thing at a time.

[0] [2009-05-13 01:05:41] Winnie

IMHO, in addition to all the above given tips like - keep up to date on technologies and trends, change of attitude (keep the end in mind before you start). I strongly suggest a time tracker tool plus a few simple diversion techniques (read Browser addons) to keep one from being distracted by the whole plethora of sites we are addicted to.
I have used Manic time tracker available here [1] (which tracks all the windows and applications you have been working on throughout the day) and to tell you the truth - I was really shocked to see how much time goes to drain in my typical work day. In addition to this - I use simple scripts like "Take a Break" for GMail (another of my addictions) to keep me on track.


[0] [2009-05-13 01:36:25] Joel Coehoorn

Set up a black list for time-wasting web sites.

You can't do that to SO! - VVS
[0] [2009-05-13 11:04:05] Nat

According to this article [1], heavy drinking is something every programmer should practice regularly.


[0] [2009-05-13 13:18:13] Khan

Learn something new everyday. When you don't have time constraint, try to use a new tool to do the job. Use the right tool for anything else. Find a proof that it is the right tool.

Don't take for granted that your code is foolproof. You don't and can't know all.

The only advise that I should give is accept that programmers have flaws. Just hope that your team doesn't have the same flaws. And work on it.

Reread the 7 (now 8 habits)

[0] [2009-05-13 19:25:24] CodeSpeaker
  1. Always willing to learn and understand new concepts and how you would benefit from them.

  2. Write easy-to-read maintainable code. An example and a rule of thumb i use is to name your variables as descriptive that they wouldnt need comments, then apply comments to them as well.

  3. Get input from multiple people if you get stuck with a problem and dont be to proud to accept someone elses idea over your own. Balance the pros and cons of each idea to find the best solution.

  4. When you dont have to copy/paste repetitive code around in your projects but instead gather common tasks into smaller units resulting in a change-once-apply-everywhere effect, you know youre on the right track.

[0] [2009-05-13 19:39:29] StaxMan

Beyond other very good points and observations, just one more thing:


[0] [2009-05-13 19:39:46] Martijn Muurman

Keep it simple ;)

[0] [2009-05-15 11:30:20] Wayne Hartman

A highly effective programmer is one that programs the least amount possible. I call him the lazy programmer. The lazy programmer spends more time researching and designing to maximize code reuse and extensibility. The lazy programmer isn't compelled to go reinvent new code if there is something else that will fulfill the need.

I've seen time and time again where projects are only concerned about the here and now without concern about the consequences of design choices and flaws. The lazy programmer looks to the future to solve problems today, so that he doesn't have to revisit them later.

[0] [2009-05-15 11:36:18] CB01

Good ole hard work.. like everything in life.

[0] [2009-05-15 14:14:00] Mark Thalman

Get the source control religion - Having the flexibility to completely trash the code to try an idea and be able to get it back in a couple of seconds to something that works allows you to try wild ideas and not to care if they don't work.

I know developers doing "professional development" (mostly that they are being paid to program) whose teams don't use any version control. Ever.

It doesn't matter if you use Git [1], Mercurial [2], BitKeeper [3], Perforce [4], or whatever. Just do it!


[0] [2009-05-15 14:18:15] JamesM

Have a moan with colleagues about how as developers were always going against the grain when trying to get things done!

[0] [2009-05-15 14:19:53] Kinlan

Understand the technology you implent solutions on top of.

[0] [2009-05-15 14:41:20] Nir

Its definitely the ability to concur the fear of change.

From time to time a programmer faces the dilemma of rewriting code against patching. Patching is good for the short term goal of finishing the next feature quickly. Rewriting is good for the long term maintainability of the software which is obviously more important but less urgent.

Most programmers will fear the change which may leave their code in an unsteady state for a couple of days (the scariest thing for a programmer). The best will delve into the change without fear and end up with code which is not patched but written cleanly as if its the first version of the code. These ones are more effective for the long run, and the ones you want to employ or work with.

[0] [2009-05-15 17:27:09] Dan

I found one Kent Beck’s idea from his Implementation patterns book really useful (does this mean I am highly effective programmer?), to paraphrase it: “Think in term of patterns for every single line that you write”

He is not talking here about GOF or Design Patterns. These patterns are on a lot lower level. As I understand it, it’s like having a bunch of code snippets in your head. If you analyze the OO code you write, it mostly gets down to delegation, iteration, inheritance.

[0] [2009-05-15 18:47:41] adopilot

I can't say for myself that I am programmer with good habits, or that I am good programer at all. But the thing that always help me is sabr [1] (patience). Things can't happen over night. And I sometime say to myself: easy and slowly, just do the thing as it's going to be best, and do you remember how it looks like "Windows 3.1" when it came out and what we got now?


[0] [2009-05-15 23:05:26] Marc Towler

Planning and preparation is always a good start on the road of being a good programmer. You need to be able to block out the distractions that are all over the internet and modern life, stuff like youtube, gaming, IM etc. Then you have to know what it is you want to achieve and work out how you are going to do it, oh and finally plan in some breaks too ;-)

[0] [2009-05-16 09:10:58] Marcom

Always be up to date. Follow blogs, read websites..

[0] [2009-05-16 09:15:00] seb

Doubt your own solution. Try to find a better one.

[0] [2009-05-16 21:29:00] Andrea Balducci

Take back control over your time and your tasks to maximize your efforts. I'm just starting with the Pomodoro Techique [1] upon the suggestions of my friends at our XP User Group.


[0] [2009-05-20 15:45:39] Danielb
  1. The simplest solution that works is usually the correct solution.
  2. Never stop learning and reflecting on what you do and how you work.
  3. Use the best tools you can get hold of and know them inside out.
  4. Keep a personal task list and review it daily.
  5. Measure then optimise: premature optimisation is evil.
  6. Be lazy, automate repetitive tasks.

[0] [2009-05-26 23:12:04] Vincent Buck

Going to bed early [1]?


[0] [2010-02-14 16:06:24] umerh

Use Test Driven Development and make your code crash, plan for the worst case scenario. (works for me)

[0] [2011-08-09 23:19:39] Ninjapig

For me effective programmers usually:

  1. Assume nothing: Assumptions lead to problems and errors
  2. Plan things: Some quick notes, or a full specification
  3. Identify targets: Can't measure success without start and end points
  4. Work hard: Didn't get good by copy-pasting all their code from the internet (only when needed :p)
  5. Delve deep: Identifies symptoms, finds the cause(s), fixes the actual problem
  6. Multiple languages: C#, VB, Java, Perl, etc.: 'mostly' the same, it's the business logic that matters
  7. Experienced: It takes years to become effective
  8. Communicate well: Divining the actual problem/result is an art form few pursue
  9. Recognise patterns: All these problems are the result of that simple error [there on line X]
  10. K.I.S.S.: Complicated code is just a collection of simple things
  11. Shortcut Guru: Hands stay mostly on the keyboard, not moving to the mouse until needed
  12. Always Learning: Stop learning and you stop progressing
  13. Not just a coder: Philosophy, Psychology, Music, Movies, Food, all improve the coders attitude
  14. Know themselves: Knowing what you need and what puts you off means you can prevent/encourage the right environment to be effective
  15. Proactive: I knew this would happen before we even started :p
  16. Help others: Some can do, some can teach, but effective programmers can do both

[0] [2011-08-30 17:23:42] sami

The phrases "I think/maybe because of/it should be/it could be" should not in your vocabulary when discussing programming/algo problems and their solutions - either you know it or you don't, there is no grey area - discuss issues based on facts and not assumptions - never assume

[-3] [2009-05-15 11:32:16] User

Eating directly before your PC.