What are the best habits of highly effective programmers?

Question

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?

Answer 1

close and kill any e-mail reader program/clients

that really saved lots of time

Answer 2

Obligatory Programmer-Fiction References - Caffeine and Hot Pockets

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

Always willing and able to learn...

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

Answer 8

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

Answer 9

From my experience:

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

And

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

Answer 10

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

Answer 11

Fix Broken Windows.

Answer 12

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!

Answer 13

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.

Answer 14

Understanding that the answer is always "It depends".

Answer 15

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

Answer 16

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.

Answer 17

Be a pessimist

Answer 18

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

|K<

Answer 19

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.

Answer 20

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

Answer 21

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

Answer 22

• 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

Answer 23

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

Follow principles like DRY, KISS..

Never stop learning..

Answer 24

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

• dont think too complicated

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

• be critical to yourself and about your skills

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

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

Everyone makes mistakes. Dont try to abadon them.

• Use what you ahve learned

Just because u know that you should write comments, use principles like KISS or somethin else doesnt mean that u are a good programmer, until u do it.

• be interested in new technologies

especially at the moment, its important to be interested in new technologies, if u are not, u wont be going on as a developer for too long

• always have coffee near u if u are programming

very important. no coffee, no ideas^^

• dont sleep too much

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

Answer 25

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

Answer 26

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, its 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 manager or 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)

Answer 27

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.

Answer 28

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

Answer 29

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

• Practices of an Agile Developer
• The Pragmatic Programmer

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.

Answer 30

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

Answer 31

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.

-R

Answer 32

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.

Answer 33

Social Life

Answer 34

Participate in problem solving, analysis, and brainstorming with other programmers. This is so important, and why Stackoverflow 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.)

Answer 35

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

Answer 36

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

Answer 37

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.

Answer 38

Don't overengineer

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

Answer 39

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!

Answer 40

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.

Answer 41

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.

Answer 42

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

• Launchy - So you can run apps with the keyboard.
• Command Prompt Explorer Bar - You can use BOTH Windows Explorer and Command Prompt in one window.

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.

Answer 43

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?"

Answer 44

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

Answer 45

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

Answer 46

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

1. Listen
2. Understand
3. Think

Answer 47

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?

Answer 48

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." (wikipeida)

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 dis-or-dat. "Neat," is what they say when I show them how effective I can be with TC.

Answer 49

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!

Answer 50

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.

Answer 51

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

Answer 52

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.

Answer 53

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.

Answer 54

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.

Answer 55

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.

Answer 56

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

Answer 57

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

Answer 58

• Planning
• Take notes
• Not putting things off
• Be interested
• Overdocument
• Listen to other people
• Have perspective

Answer 59

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)

Answer 60

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

Answer 61

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.

Answer 62

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

Answer 63

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

FOCUS.

Answer 64

Keep it simple ;)

Answer 65

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

Answer 66

From the wall of a corporate building in Zurich:

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.

Answer 67

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.

Answer 68

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

Answer 69

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.

Answer 70

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.

Answer 71

Eating directly before your PC.

Answer 72

Good ole hard work.. like everything in life.

Answer 73

Get the Source Control Religion - Having the flexibility to completely trash the code to try and 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, mercurial, bitkeeper, Perforce, or whatever. Just do it!

Answer 74

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

Answer 75

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

Answer 76

Understand the technology you implent solutions on top of.

Answer 77

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.

Answer 78

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.

Answer 79

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.

Answer 80

be adaptive to changes, and understand things really well.

Answer 81

I cant said for myself That I am programmer with good habits or that I am good programer at all.But thing that always help me is sabr (patience), things cant happened over the night , And I sometime say to myself easy and slowly just do the thing as its going to be best, and does you remember how looks liked "win 3.1" when its cammed out and what we got now.

Answer 82

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

Answer 83

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

Answer 84

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

Answer 85

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

Answer 86

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.

-AD.

Answer 87

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

Answer 88

Don't give up.

Answer 89

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.

Answer 90

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.

Answer 91

Going to bed early?

Answer 92

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

Answer 93

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