I guess that many of you have read 7 habits of highly effective people . 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?
Don't be satisfied with an apparent fix; full understanding is the standard.
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.
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.
Always willing and able to learn...
If you don't keep up with the times, you won't be a developer very long.
Fix Broken Windows . http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy
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.
Close and kill any e-mail reader program/clients.
That really saves a lot of time.
From my experience:
Don't assume it - prove it. In other words: don't base critical work on unverified assumptions. Make sure the foundation is sound.
Understanding that the answer is always "It depends".
“Try not. Do, or do not. There is no try.” - from my buddy Yoda.
Take ownership, willing to accept mistakes, positive attitude..
Follow principles like DRY, KISS..
Never stop learning..
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.
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  http://en.wikipedia.org/wiki/Overengineering
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).
Keep in mind "80/20" rule and constantly ask yourself: "Do I really want to do this that way?".
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.
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 , I'm looking at you), and offer specific techniques that can help you improve. http://www.pragprog.com/titles/pad/practices-of-an-agile-developer
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.
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!
Questioning your own solutions and looking for ways to do things better.
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.
Discuss what you have modelled/written/thought with others, even though (and most likely if) you are sure of what you did.
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.
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.
Obligatory Programmer-Fiction References - Caffeine and Hot Pockets
Serious/Semi-Serious Answers - Never willing to settle for what you know at this very moment.
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.
One thing at a time. Multitasking kills productivity. Seriously.
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".
Don't have mercy to delete all your source code!
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.
Habits? Okay, here are my suggestions for the 7 most important habbits of a programmer:
Most of the time a solution for a problem is much easier than you would expect. Try to find this easy way.
If you stop being critical to yourself, you will stop making improvements.
Everyone makes mistakes. Don't try to abadon them.
Just because you know that you should write comments, use principles like KISS  or something else doesn't mean that you are a good programmer, until you do it.
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
Very important. No coffee, no ideas^^
More than 6 hours of sleep are lethal for your programming skills :D http://en.wiktionary.org/wiki/KISS_principle
Highly effective programmers create maintainable products that other people like and purchase.
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 :).
Be a pessimist
I don't see these 3 very basic skills mentioned here in this order:
Programming is about...
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.
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.
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.
Attaining this requires a lot of willpower, but works fine and does wonders:
Take the last half hour of your work day to plan the next day
When making the list of what you want to do, put the most complex thing first in a big block
Next day, do that first even before checking email and stuff
Come mid-day, do your mail and usual office chit chat
Do another 2 stretches of work on smaller items
Final mail run
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! :)
Don't give up.
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.
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...
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.
If you mean productive too, there are a lot of great tools. Two Windows tools that I use:
I would recommend The Productive Programmer  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 . http://www.launchy.net/
Either be Jeff Atwood, or read his blog: http://www.codinghorror.com/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?"
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.
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.
Automate If you have to repeat things 3 times, don't. Make a program. What program, what language, that depends on 2) and 1)
Don't underestimate newbies. Sometimes n00b can give you better advice then a pro :)
Always Comment! The more green, the better. Even if something is obvious, comment it anyway!
Always test, even the smallest and least signifigant change. When testing, do unexpected things, like purposely hitting the wrong key or misclicking.
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.
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.
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.
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.
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?
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 )
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. http://en.wikipedia.org/wiki/Total_Commander
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!
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]...you will be fine....thats until the boss decides he doesnt like the tie your wearing....
The best advice is probably
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:
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.
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.
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 :)
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:
This is much more important than many think. Noise stress you...
From the wall of a corporate building in Zurich :
I used PowerPoint to create an image from that. It's not my desktop wallpaper. http://maps.google.com/maps/ms?ie=UTF8&hl=en&t=h&msa=0&msid=105852379886197898420.00044fd8962bc3cb1cc2c&ll=47.41458,8.548605&spn=0.001751,0.001663&z=19&iwloc=00044fd89b6ef704b840e
Cope with procrastination, roll up your sleeves, and do the job.
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.
DON'T BUILD PROTOTYPES!
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. :)
My choice for Habits would be.
Adding to what has been said already...
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  or BDD  practices, but writing tests helps you understand the code better, and it will absolutely find problems in your code (that you thought was solid). http://en.wikipedia.org/wiki/Test-driven_development
Don't try and fix every bug. Pick your battles.
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.
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.
Only a lot of refactoring and Unit tests can save your soul.
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.
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.
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  (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.
Set up a black list for time-wasting web sites.
According to this article , heavy drinking is something every programmer should practice regularly. http://www.prospect-magazine.co.uk/printarticle.php?id=10751
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)
Always willing to learn and understand new concepts and how you would benefit from them.
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.
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.
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.
Beyond other very good points and observations, just one more thing:
Keep it simple ;)
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.
Good ole hard work.. like everything in life.
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.
Have a moan with colleagues about how as developers were always going against the grain when trying to get things done!
Understand the technology you implent solutions on top of.
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.
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.
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  (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? http://en.wikipedia.org/wiki/Sabr_%28Islamic_term%29
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 ;-)
Always be up to date. Follow blogs, read websites..
Doubt your own solution. Try to find a better one.
Take back control over your time and your tasks to maximize your efforts. I'm just starting with the Pomodoro Techique  upon the suggestions of my friends at our XP User Group. http://www.pomodorotechnique.com/
Going to bed early ? http://www.wikihow.com/Go-to-Bed-Early
Use Test Driven Development and make your code crash, plan for the worst case scenario. (works for me)
For me effective programmers usually:
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
Eating directly before your PC.