how to keep yourself from perfectionism when coding

Question

In personal projects I often find myself tinkering over code and keep rewriting it because there's always something that can be improved. I'm looking for ways to tell myself 'ok the code is not perfect but I need to move forward now'. How do you motivate yourself to go forward and take the imperfect code as is?

---

merged with "How to stop being a Perfectionist Programmer":

I'm a code perfectionist in the best sense of the word. I'm the total opposite of the 'cowboy coder' who doesn't care how things work, look like. I literally brood over sometimes trivial problems for hours, attempting to come up with the perfect solution. When I find it, I sometimes stare at it with a fuzzy warm feeling.

I justify the outrageous time expense in my head by telling myself that this is a one-time expense as I will then be able to reuse the gained knowledge later on how to solve a particular problem perfectly.

I need to stop this. It's turning my projects into lengthy hunts for great solutions more often than not ignoring the fact that I still didn't ship yet.

I know there are more programmers out there with this kind of 'problem'. How did you tackle it, what do you do to not fall into this trap while programming away?

Answer 1

I find deadlines are a wonderful motivator ... :-)

Answer 2

have a strict schedule for your projects , if you just got a spare time refactor your code

Answer 3

The boss, project supervisor, deadlines. Stuff has to get done and some people just want to see it work decently. If this is a personal project, then you just have complete freedom to do what you want. Personal projects are for learning and experience, so that is great coding project to write, rewrite, and optimize.

One thing I like to do is setup "stages" Stage 1 needs to have this functionality, then once that is good, move onto a second stage and so forth. Set these stage details at the beginning and write up a rough timeline of your project.

Answer 4

By reading the Cult of Done Manifesto again. Also by realizing that the goal of software is to solve problems, not be the most elegant and beautiful thing ever written.

Answer 5

By wanting to see the code actually do something. Or, if it does something, something more. Or to see it pass all the tests I write. Personally, I find this more alluring than perfect code.

Answer 6

I have this problem as well. It's common to any creative pursuit, like writing or painting. Sometimes it's hard to know when to stop.

It's especially hard when the project is something you're working on in your own time, primarily for your own benefit.

My advice is to make some goals for your project. Create milestones or criteria that can help you decide what "Done" looks like. Once you've set some goals, you can think about how to meet them and how long the project will take. Then adjust accordingly.

Answer 7

Realizing that perfection is impossible because there are mutually exclusive tradeoffs helps. For example, you can have an API with elegant simplicity, or you can have one that allows for infinite flexibility in the face of change, or you can have one that is totally bulletproof and makes it impossible to shoot yourself in the foot. Maybe you can get two of these to work, but you have virtually no chance of achieving all 3.

Answer 8

TDD. Write the tests that show that the code meets the requirements. When the tests pass, you're done.

Answer 9

I tend to take the view of asking this question, "If I spend x more hours on this, am I going to get something for it?" This does require that you value your time and have a number of other things going on that you'd rather be doing so it is a quesiton of competing priorities. The time will pass regardless of how you spend it, so why not make it count if you know that there is a very small chance of finding something to refactor in a good way.

Answer 10

Ask a fellow colleague to read through your code while you count the wtf/minutes you'll get from him/her doing this. If the ratio is reasonable for you move along otherwise refactor your code again.

Answer 11

At the root, perfectionism is motivated by one thing: fear of not being good enough.

If you understand this, you can stop being driven by it so much. Throw your work out there. Expose the fruits of your code. There's no prize in this business for being perfect. Good enough is all that counts. Once you get comfortable with knowing when your work reaches "good enough", you'll know when to move on.

Answer 12

By being pragmatic. Ask yourself, "Have I delivered enough testable code to meet the core requirement?" If yes, move on and accept that there's always room for improvement.

In addition you could consider adding, "Would I be embarrassed to review this code with my buddies?" ;-)

Answer 13

In some ways I disagree with the "get something done" / "set yourself a deadline" arguments. There's a lot to be said for taking time to explore paths that you might not be able to at work.

Tinker, meander, rewrite. Take your time. Try to find patterns and abstractions. Refactor your test code again. Wait until you *are* fairly happy with your code. You can only win from this: You'll learn things that you can apply to your other work, you'll become better at judging when to to draw a line and move on and you'll probably add a few things to your "ok, let's not go there again" list.

Obviously, your approach will vary according to what you want to get out of your personal projects.

Answer 14

Just "do the simplest thing that can possibly work". It's always a temptation to polish endlessly, but no matter how much of that you do, you always cringe when you revisit your code after some time.

Remind yourself that once a piece of code works there is more to do in other areas. You will lose time on those other areas if you hesitate around working code.

And forget optimization. Forty or more year ago Kernighan and Ritchie wrote in Elements of Programming Style: "First, make it work. Then (if it doesn't work fast enough) make it work faster". Our intuitions about what will improve execution speed are almost invariably wrong: optimization is best done after measurement and instrumentation of performance.

Answer 15

Define a goal, and when you have met that goal, stop. Or don't, but you know it's done at that point.

OTOH, I don't see anything wrong with being perfectionist on personal projects.

Answer 16

Don't treat your "art" the same as you would a job.

With a job you are rewarded to achieve a task, so it is easy to just get to the end result. But with personal projects, the reward probably isn't just the end result but the process and challenge in itself. If you ask yourself why you think you are taking on this project, you'll probably find the answer is what is dictating your behavior.

If you find yourself being a perfectionist, is it because you thoroughly enjoy eek-ing out every bit of performance from your code and formatting everything exactly so? Maybe that's where your enjoyment comes from in doing this project.

But if you think your perfectionist tendencies are interfering with your enjoyment of completing (honestly, it'll never be complete right?) the project, try giving yourself "feature versions" to shoot for. Version 1 gets the feature functional. Version 2 refines it, or just a portion of it, etc., etc.. That way you can quickly get to a functional result, but can still work on refining it if you choose to.

But just remember, don't turn your art or hobby into a job!

Answer 17

Things started to change for me when I started to feel really in charge of the product and the relationship with customers.

When you are really committed to provide something useful to somebody in a timely fashion, you just have to be more pragmatic about getting things out quicker.

It doesn't hurt either once you come to realize that you can never get things right the first time, mostly because customers don't really know what they want until you get them something they think they wanted but actually don't. All this time spent perfecting the invisible side of the app can often turn out to be a waste.

We make up for that by always using small modifications requests as a chance to get around and refactor nearby stuff along the way to fit our new quality standards. Bigger clean up efforts are engaged when it makes real business sense and we can justify to ourselves investing that much time on it.

Answer 18

The same way you keep yourself from over-perfectionism in life. By finding balance.

Answer 19

The way I finally got myself out of that rut was thinking, "what good is your perfect code if it doesn't do anything?"

You've got to realize that you won't learn anything by writing perfect code right off the bat. It's when you write the imperfect code, that you learn lessons. And then the next time you write something similar the part that you messed up on will be better, maybe not perfect, but better.

Answer 20

Sell it. You'll find that once you've been paid for your efforts you're less inspired to keep dressing it up... that, and you'll then be in support mode.

Answer 21

I've had the same tendency for my personal projects. I have found a trick which works well for me: I have two TODO lists for a project. The first one contains the features to implement, bugs to fix, refactorings to do (the "necessary" ones). The second one contains the tinkerings, rewrites, refactorings for refactoring's sake and so on.

Whenever I am working and I am feeling that I am drifting from "real" work to perfectionist work, I stop, think, and add an item to the second TODO list. This usually is enough to go back to "real" work. And whenever I am in the mood, I do one or two items from the second TODO list.

Answer 22

How about asking your manager to fire you if you don't deliver your next project on time?

Answer 23

I'd start by time boxing your tasks. Say for example that you are doing a website and you want to do a contact details page. Set yourself say 2 hours to complete this task. After the 2 hours stop and move on to the next task even if it isn't perfect. I use the pomodoro technique for this and it helps me.

Answer 24

Learn to tell the difference between what's important and what's not.

Answer 25

I think every programmer feels he/she has to write perfect code. simply put, perfect code doesn't exist. I prefer to start coding, then I perfect my code through revision.

Answer 26

If you can regard the time spent on a task as a factor affecting its perfection, then your perfectionist side will try to solve the issue faster in order to approach the perfect.

Answer 27

The reason behind the "perfectionism" is the fear of losing control. It is a symptom of a design issue, a good design should provide abstraction which is essential to have ability to isolate not-so-well code.

edit: Besides, "the perfect code" is often is also less maintainable, lack of evolution process makes it more fragile.

Answer 28

Write the best code you can in the time that you have to do it, and as soon as you have some free time to examine your old code, improve it with the lessons you have learned from the experiences you've come across between when you wrote the code and when you revisit it.

Every programmer wishes they had enough time to get it right the first time, but the fact is, you will rarely ever get it right the first time.

Programming is not an exact science, there is never one perfect answer (for the most part). The more you are exposed to, the more you'll learn and improve. Take the experience you learn and apply it

Answer 29

I have two suggestions:

1. Practice. Find programming assignments somewhere (For instance, try codekata.pragprog.com/ Link seems to be down right now though) and complete them in the shortest time possible.

2. Strike a deal with yourself that you put your perfectionism aside to make something work first, and then revisit your code and refactor it. For extra credit, try to stop refactoring when you can't justify making the code even more expressive and clean.

Answer 30

Some tips that made me escape from the "perfect world":

• Don't marry your code
• Write as if you are going to throw it away (if not today, next week)
• Iterate often
• Align your efforts and code with the reality once in a while
• Think of you code as a means to a specific end (a special case) not as a general solution to achieve world peace and produce sliced bread at the same time
• Work on a side-project to keep your perfectionism ventilated
• Appreciate the warm feeling you get when something is released (each iteration) rather than when it is "finished"
• Realize that you'll never get the time spent back (you won't find a similar problem again that is worth the time you spend on a perfect solution)

Answer 31

This one hits close to home. If you're like me, the idea of implementing a less-than perfect solution makes you cringe. The best way that I have found to deal with it is to add a comment reminding me to revisit the code at a later date. Something like:

// NOTE: find a better way to do this

Leaving that bookmark in place gives me peace of mind that I can always go back and find it again when I have the time to work on it. Once it is recorded somewhere, I can move on.

Here's the interesting part: most of the time, you never come back! You may swear up and down that finding the perfect solution to that problem is the very next thing you will do as soon as you have free time, but the truth is that your original solution works just fine, and there are more interesting / more pressing problems to solve.

Answer 32

How about make everything work as fast as possible using any means at hand, even when the code is not very 'elegant'. When everything works and has passed your tests, make sure everything is safely committed into sourcesafe or at least backed up somewhere and start then to refactor everything in a more elegant way.

Making everything work first assures you that you'll have always something to hand in when the deadline strikes, whereas you start writing prefect code from the beginning you'll never know you will finish in time.

Answer 33

This is a good habit to be in. You just need to do it faster. You get faster at programming like you get better at the piano -- practice. Keep pushing yourself to write good solutions quickly, and soon you will be able to write excellent code AND get it done on time.

Advice like "treat your code like you're going to throw it away tomorrow" is not such a good idea. If you didn't have time to get it right today, you're not going to have time to throw it away tomorrow. Once the code is written and deployed, the last thing on your mind is how to improve that working code. You'll move on to the next task, and before you know it, the parts of your program won't fit together anymore, and taking things apart will result in an explosion of little pieces that you'll have to crawl around on the floor looking for. Every tiny change will take slightly longer, costing you much more time in the long run. All because you were too strained for time to add some oil to the machine once in a while.

I've worked on applications like this before, and simple things, things that should take two people an hour to implement, started to take weeks. Technical debt is bad -- don't let it ruin your project.

Answer 34

This is a good question and one that I have trouble answering because I suffer from it myself!

However I'll give it a try...

Keep in mind that if you're any sort of decent programmer, then code you've written 6-12 months ago no longer has the "this is perfect code" badge of honour. It's either been superseded by newer code or techniques that you've learnt since it was first written mean that it could quite easily be rewritten better / cleaner / faster / etc.

Therefore, I think the benchmark to which you should measure your satisfaction should be in the following order:

1. Has the change I've just made the user experience any better?

2. Has the change I've just made my colleague's life easier?

3. Has the change I've just made my life easier?

If you're simply trying to satisfy yourself only, then you'll end up in a spiral of self doubt and perfection seeking that will never end.

---

Also, I don't quite agree with sticking "todo: make this better..." in you're code, because it drives people crazy when they see this and get frustrated that perceived "bad" code has been left around. The code is probably in a good state, but didn't quite reach your level of perfection, which is of no real help to anyone new looking at the code.

Answer 35

Negotiate regular cleanup periods with your employer or customer. Prefer employers (or, if possible, customers) who appreciate "doing it right" as well as "getting it done".

Do not "write your code to throw it away tomorrow". (See eJames's and jrockway's answers). The costs of throwing it away can be huge, because other code will depend on it. If you cannot finish a clean solution, produce and release a working version, and mark it by a "TODO" comment.

During the cleanup period, satisfy your perfectionism: First prioritize your TODO list. It may have accumulated many items. Your understanding of the problems and their relevance will have become much deeper. Some TODO items may have become irrelevant because more fundamental solutions have become possible. Use the given cleanup time well, and don't despair, if you cannot solve everything now, the next cleanup period will come.

Answer 36

Code late at night so your too tired to care, just as long as it works and safe!

your (average) clients care about that much too!

Answer 37

Redefine perfection. No seriously.

I your customer isn't happy, it ain't perfect. Admittedly it probably never will be but at least you'll be focussing on what matters.

Answer 38

I had a similar problem. I used to run many routines through the debugger, checking every code path, validating that they worked. I wrote solid code, but hated change requests - every change to a method required re-validating it.

Then I learned about Unit Testing, Test-Driven Development (TDD), and Extreme Programming (XP). These got me out of the debugger, and helped me fear change less (OK, I still don't embrace it!). When your tests match your specifications and all your tests pass, you're done. You can also go back in and revise or refactor your code with confidence, since your tests will reveal breaking changes.

The Open Closed Principle (part of S.O.L.I.D.) can also help you here.

Read some of the resources on unit testing/TDD, pick up a book or two, and start doing it. It will change your life (for the better!).

Answer 39

Start writing C solutions for Project Euler. Do not use functions or loops.

When you can do this without flinching, you've been cured.

(Hint: It corresponds to the assembly instruction jmp.)

For extra credit, use only one-letter variable names.

Answer 40

Spend more time in thought; thinking is faster than coding. That way when you actually get down to coding, your code is more likely to be something you're satisfied with on the first try.

Often this won't catch larger things that you won't notice until you're much farther along. But those things tend to be the type that actually need to be fixed.

Answer 41

Don't rewrite every piece of code you come in touch with. Learn to love legacy code. Use lots of open source. READ! lots of open source code. BREATHE!

Answer 42

You need to set limits to the time you spend on a task, i think its called time boxing, where you only allow like four hours for something you need to do so you're more in a hurry and have less time to think about making it perfect.

Answer 43

I encourage you to read Getting Real http://gettingreal.37signals.com/ by 37 signals (its free for pdf online version).

Keep reading this.

I often revert to parts of it - especially when I get to the stage where Im asking "what have I achieved this week?"

Answer 44

Become a different human being with a different philosophy on life. Seriously, I've never seen anyone change it any other way.

Answer 45

Work for a start-up. Then you'll program very imperfectly or be fired very quickly :) If you start the company then there is no better motivator to ship your product :)

Answer 46

In case you are self-employed:

Remember that the extra time you put in to go from good to perfect is not paid by anyone. Calculate the hours you spent last week for that purpose and multiply by your average hourly wage. Think what nice geek toys you could have bought if you would have been productive during that time instead.

Answer 47

Get married and have a baby.