3

I recently failed three projects with a similar pattern:

  • I had to work on each of them alone
  • With time I started to take the project too personally, like it is my spiritual child, and I tried to make it perfect
  • Soon my progress slowed to a halt, and effected everyone, which in turn made me feel more guilty and desired to make things even more perfect!
  • Eventually I had to drop it in shame.

I want to ask if there's anyone who have suffered the same:

  • How do you overcome it?
  • If you absolutely cannot work on a solo project then how do you explain it to your boss so that it doesn't seem like you're incompetent?
gnat
  • 21,442
  • 29
  • 112
  • 288
  • I don't think this is a duplicate of the referenced question at all. One is asking how to let go of the code and that feeling of ownership, the other is how to get stuff done despite wanting to be a perfectionist. – Dunk Nov 03 '14 at 16:54
  • @Dunk http://meta.stackexchange.com/a/194495/165773 – gnat Nov 04 '14 at 13:53

4 Answers4

10

As Churchill famously remarked, "the maxim 'nothing avails but perfection' may be spelt shorter: p-a-r-a-l-y-s-i-s".

You need to internalize the notion that this approach is unprofessional.

Or, as Jamie Zawinski put it (in "Coders at Work", recommended by Joel Spolsky once), "At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products."

And that contains an important observation. The job of a programmer is not to write code! It is to solve problems. If a problem can be solved by not writing a line of code, or even by deleting code - all the better.

See your job as one of a problem-solver, who only happens to be a coder. Not the other way round. A shift in priorities follows organically.

I am suffering from the same syndrome, but I cope with it by doing hobby projects, in which I have no deadline and I have my own little perfect world. (And yes, they typically end up paralysed by perfectionism). But at least thanks to that I'm venting off from all the rotten compromises I have to make at work, and everybody's happy :)

Thus my advice would be: try to write perfect programs in your spare time. You will learn that you're chasing a mirage and it's not worth it. Or you may get addicted to the thrill of chasing this mirage, but since it's your spare time, your professional reputation won't be exposed to risk, and you won't feel so perfection-hungry at your pragmatic, day-to-day work. Or perhaps you'll actually learn to write perfect programs in finite time. Either outcome is good!

If you absolutely cannot work on a solo project then how do you explain it to your boss so that it doesn't seem like you're incompetent?

Sorry to say that, but it wouldn't only seem so. It is a form of incompetence, fortunately one that can be dealt with fairly easily.

Konrad Morawski
  • 9,721
  • 4
  • 37
  • 58
  • 2
    While some may view your inability to work alone as incompentence, I would counter that any dev working in isolation is not a good solution. You need someone else to not ounly bounce ideas off of and to correct you when your wrong, but to push your boundarys and to offer a new viewpoint. Developers in isolation can tend to stop growth in skills without someone to help push them along. I don't feel it's ever good to be the sole dev on a project. – Matt Klinker Oct 31 '14 at 20:40
  • @mklinker I agree that working on your own is not beneficial in long run, but these specific traits that make the OP unable to be efficient on their own are likely to harm his productivity as a team member as well. – Konrad Morawski Nov 01 '14 at 14:47
  • Or, instead of changing, you can find a company that allows you to write code where your perfectionism isn't an issue. – Filip Dupanović Nov 02 '14 at 22:52
  • @FilipDupanović I wholeheartedly support the idea of finding an employer that doesn't force you to cut corners under time pressure. But I can't imagine any commercial environment that would be fine with your development crawling to a halt, and that's the OP's case. Obligatory xkcd: http://xkcd.com/974/ :) – Konrad Morawski Nov 02 '14 at 23:23
8

One thing I could suggest from my own experience is to have a clear "definition of done" for every task you are working on. Although this term comes mainly from the scrum environment (see a description here) it could also be helpful to adopt it when working alone on a project.

The main idea is that you define clear, measurable criteria that describe when a given task is completed. But the important thing is that it also works the other way round: As soon as the criteria are reached, the task is considered done and no more work should be spent on this specific task. If you still think you could polish or tweak things a bit more up, define a new task (maybe with a lower priority) and define exactly what and how you want to polish this (again with clear acceptance criteria). But start this new task only after you have finished all other tasks with a higher priority.

In that way you could ensure that you do only the work which needs to be done to get the program to work. Sure this might even mean that the software is not yet perfect but it doesn't matter, at least it does what it should, and improvements can be done after that.

If your project has at least a product owner (or a person with an equivalent role) you both could sit together and define the DODs for every tasks together.

pgenfer
  • 286
  • 1
  • 4
1

How do you overcome it?

I see (intentionally seeking) other people making mistakes and being fine with that. That tones down my fear of mistakes.

If you absolutely cannot work on a solo project then how do you explain it to your boss so that it doesn't seem like you're incompetent?

I don't know how it looks from the eyes of my boss. I can't read others' minds. If I think I look incompetent, that's just my fear of looking incompetent comes into play. And if I'm really incompetent and try to pretend I'm not, I screw up in the end anyway, so I better confess.

scriptin
  • 4,432
  • 21
  • 32
0

It is not clear from the question if the projects were actually released at some point or were they abandoned before the first release.

In the latter case it's clear that a change in mindset is needed. We engineers would always like to perfect our product and feel uneasy when we need to release something that still has lots to improve. But this is exactly what needs to be done. You need to release early and release often and accept the fact that the first version will be painfully bad. This is the only way to write quality software that actually solves the problems your users wan't to get solved.

It might also be beneficial for you to familiriaze yourself with the concept of Minimum viable product and perhaps even read the Lean Startup book from Eric Ries.

Muton
  • 617
  • 4
  • 11