How to become emotionally distant from your code or project?

Question

This question comes as a realization I gained after I worked for the first time in a 8 months long project with 4 other members (3rd year university project). Needless to say the project was a bust ... a car crash mixed with a plane crash bust . I had an inkling of why it happened like:

• Didn't focus on details
• Didn't define and control scope creep
• so on....

But today after reading this article I realized one of the biggest problem I had as a individual in the team was I became to emotionally attached to the project. Although this realization is a little late ( the project finish in April ) I would like to learn from it. So how DOES one become unattached emotionally to their code? or moreover what do you think makes a person attached to their project in such a way that they lose their head and objectivity?

Answer 1

I think some personal pride in doing what you do is beneficial, otherwise what motivates you to improve your code and do a better job rather than meeting the bare minimum requirements? Why become completely unattached to your projects?

Answer 2

Seriously the only thing that seems to work is taking lots of free time to yourself to enjoy whats really important in life. Don't stay that extra half-hour. Go home, see your wife or friends, or go on a vacation. You'd be surprised how much getting your mind off of it and having fun will remove your emotional attachment and help you remain objective. With a fresh mind you can make the best decisions and work smarter, not harder.

Working more will only make you more obsessed, attached, and grumpier. You'll start making bad decisions, and won't want to hear different points of view. You may start to feel possessive and start resenting those lashing out at your baby :)

Answer 3

Set yourself some real boundaries. When you are not at work, don't think about things at work. Find yourself a new hobby or passion to take away those free cpu cycles in your brain so that you don't spend so much time worrying about your project(s).

Answer 4

Two advices:

i) learn how to manage yourself and your team, read Steve McConnell's Rapid Software Development, Edward Yourdon's Surviving Deathmarch Projects and Tom De Marco's Peopleware.

ii) NEVER lose the capacity to involve emotionally in your projects, believe me, it's a gift from the gods, it gives sense to all your work.

Answer 5

I am afraid that until you get kicked in the *** a few times by various projects, you will not be able to distance yourself from software projects on demand...

Answer 6

Humility.

Just like the samurai, there is always someone better. If you realize this, you will always be striving to improve and always looking to learn. I can tell you anything I wrote a year ago is garbage compared to what I write now. But that will be true again in a year. Keep learning, and realize that just like hardware changes, so does software, so expect it to be out of date in a year.

The rate of change may vary, but the principle remains the same. There will be a better way to do it in the future, so don't expect anything you write to be the best forever.

Answer 7

I'd say you've already accomplished step 1: try to figure out your main points of failure on the project. Now move on to step 2: start a new project where you learn from your mistakes. Taking some time off is a good idea, but the sooner you immerse yourself in the next project, the sooner you'll put the first project out of your mind (temporarily at least).

Also, the more projects you have under your belt, the less likely you are to remember too much about any single project.

Answer 8

Stay 2/3 hours late every day for 6 months. You'll be quite glad to see the back of it...

Answer 9

Somehow, lack of focus on details doesn't seem to be attributable to too much emotional attachment. Control scope creep can, however. Globally, what you describe doesn't seem to me to be too much attachment, but poor management.

Nevertheless, one of my tricks is to launch early and iterate. It is not "my project", but the "user's project". Focus on the end user and every other stakeholder, not on what you'd like the code to do. Prioritize, prioritize. It is OK to consider every single feature. It is even OK to architect in a way to support all those features in the future and even more. It is not OK to implement everything on V1, however. As you can see, these are not techniques to become detached, but to manage the attachment, which, up to a certain point is a very healthy thing.

Answer 10

Focus on what your doing now, now is important.

I learned the hard way to let my code go, after doing so many project that went directly into the trash can without even be used once.

Again, focus on now and have fun coding and be ready to let the code from yesterday go away.

For me, I like to see the result of my coding, I'm not really interested on how it will be really used. I have a problem X, I find solution Y, I do it, I see it, I'm happy.

It's all about challenge, for me.

In any case, after a while you will learn how.

Because when you start writing code, it become automatically "Ephemeral"

Answer 11

Folks often overlook the fact that coding is creative. As a creative endeavor it is only natural that you, as the creator, feel a certain sense of ownership and attachment to your code. Indeed, looking at your code (and projects as a whole) objectively is what can separate a seasoned developer from a newbie.

In addition to the work-family balance and substance abuse answers already given, I would add the following:

• Have other, potentially more experienced developers review your code often.

• Like film directors, we sometimes need to cut our favorite clips from the finished product. Remember that the finished program as a whole is what you are producing, not the individual class, function or module.

• When your code is inevitably removed from a project, save a copy of it in another folder in case you need it again. That will help you cope with the loss of your creation and over time, you will watch that folder grow and realize that you never really go back there to get code.

• Maintain a side project as a test bed for your ideas. Having another outlet for your more creative code helps keep you sane when your work project throws out that far superior implementation of the String class you spent all weekend on.

Eventually professionalism will win out and you will become less emotionally attached to the actual code.

Answer 12

A few ideas come to mind:

1) Think of it as "our code" rather than your code, is one point. Pair programming can help give some distance here as it isn't like one person did all of anything.

2) Find a bunch of little changes to do and after doing one, undo the change. Yes this is time consuming and almost pointless, but it may help give you some distance from the code. By bunch I mean like 50 for a starting point as after about 20 you'll get the hang of it and by 50, you just want it to stop.

3) Be aware of how much responsibility you are taking on in the project. Is the whole project's success on your shoulders? Is any success of the project on your shoulders? Perspective here is key.

Answer 13

The way to attain detachment is by practising it. Start small. Delete that bit of code that doesn't feel quite right. Oops, I said delete, not comment out in case you need it later. Then write it better. Repeat.

When you're comfortable with that, move on to larger bits. Attachment is a habit.

PS: Don't forget to test.