Dealing with "phobia" of ruining (your own) code?

Question

I know this sounds weird, but bear with me..

Sometimes when I've coded for some time (days) I suddenly become "scared" of continuing. I come up with all kinds of diversions to not have to deal with the code, which is really annoying and, needless to say, unproductive.

It's like I've reached some point where I subconsciously feel that I could potentially destroy everything, and now I dare not touch it. Or maybe it's because I'm starting to realize that a lot of the work I've done up to here have been "bad" and I now need to remake most of it. Or maybe I'm just scared because I've run into a problem I don't really know how to solve, and I hate to have to come to that realization. I don't know.

Have you ever experienced anything like this? How do you deal with it?

Just to not turn this into a discussion about version control: I am using version control. That's not it.

(I can certainly understand if this question is outside of SO. In that case then please just close it or whatever it is you do :)

cheers!

PS. I guess this should be community wiki.. right?

Update: Just wanna thank everyone right away for a lot of good and inspiring posts! Thanks! (I don't really feel that I can choose a "correct" answer for this question, so I'm just gonna leave it "hanging"..)

Answer 1

Get some sort of source control system up and running. I recommend Vault. Change your code to your heart's content, and roll back if you mess things up.

Answer 2

I have continually felt that what I code is made up of duct tape, wishes, dreams, and unicorns. The day that you aren't critical of your code is the day you stop becoming a decent programmer. (Not to say I'm a decent programmer...but most of my stuff works most of the time...)

I don't dwell on it too much, though. Usually what I do when I feel that way is take one part that I know isn't up to par and refactor that. After that, I've got somewhat of a fix and continue on developing other parts. Iterations, my friend, iterations.

Answer 3

I think you should try out TDD. When the code is covered with tests you might find it easier to make changes.

Answer 4

You know, I can kind of relate. Whenever, I do work on a language or environment I'm not too familiar with, I get anxious beyond a certain point in fear that I'll make a catastrophic goofup and be unable to repair it. But, those were the days before I discovered source control. I'm a fan on SVN as are many other people, but there are plenty of source control systems out there... use one, and commit (backup, whatever) often, then regardless of how big a screwup you perform, you have a place to pick back up from...

Answer 5

I felt this way perpetually my first year working as a .NET contractor for the Army. The way I got over it was founded entirely in one word: Communication.

Talk through the risks with your supervisor, get a mentor and vet your solutions through him/her, and make sure to document your unknowns. You'll get mad respect for your diligence, and you'll mitigate more risks than you think.

In the end, your fears can either petrify you, or cause you to be precise and think through the implications of what you're doing. Communication will help you fall into the later of those two outcomes.

Answer 6

I think about these issues quite a bit and welcome this sort of discussion of personal and professional development, whether others think it fits on SO.

I have certainly gotten into the fix you describe.

I'd go beyond the source control suggestions and say that you not only need source control but probably should err on the side of committing more frequently, rather than less. Also make sure that you are using meaningful comments in your commits so if you do need to diff or even rollback, you have some insight into what you were trying to accomplish at that point in time.

I'd also agree with the suggestion of looking at TDD. Good unit test coverage not only gives you some confidence on what is working but if you decide you need to make some substantial changes to improve your code, the simplest definition of re-factoring, then you'll have a good idea when you do indeed break something.

Often, the exercise of writing test code can also help clarify your own thinking and help you address your concerns about the quality of your code and the questions for which you still need answers.

Let me ask a question in return: what happens if you don't finish your code or you change it and in so doing it breaks? Think about what you can do to mitigate those risks, like source control and unit testing. If your concerns cannot be mitigated, then ignore them and push on.

Answer 7

A tool that greatly helps to deal with these situations is to have a set of automated unit tests that run quickly. Every time you do a change, you can rerun these tests to see if you have broken something, and then apply appropriate fixes.

Ideally, the tests and code should be written in a Test Driven Development (TDD) approach, but since you probably have existing code, a very useful reference is the book "Working Effectively with Legacy Code" by Michael Feathers, which introduces goods ideas for adding tests to existing code (which is not always designed with testability in mind)

Another tool is to use a source control repository (SVN, Mercurial, git...) to help "undoing" sets of changes.

Answer 8

Don't be afraid to refactor. Just do it. If you understand what the code does, you will get the code working again if you break it. More often than not, choosing to not refactor out of fear will result in more work and poorer quality code in the end.

As long as you understand what your code is supposed to do, you've already accomplished much of your task. Rewriting your code is always easier than the first time, because you usually understand the problem better.

Its natural to fear breaking your code... once you realize you can fix whatever breaks, you should stop fearing and start doing.

Answer 9

I, too, would say version control and commit often.

Also, I've been writing my own specs recently (mostly for practice as I'm a one person team). This has helped me avoid getting well into a project or feature, realizing that I failed to account for something and having to start over.

Perhaps if you do a little more designing and planning, you would have more confidence and direction while coding.

Answer 10

I had the exact problem as you other day. I was looking at some code and either it was brilliant, written to a standard much better than I usually achieve and beyond my understanding that day, or it was a terrible brittle spaghetti mess. Either way I didn't want to touch it in case I broke it.

In the end I decided the only solution was to dive in all but break it on purpose. I knew as long as I tested the final result I'd be OK and I'd learn/remember more about the code by breaking and piecing it back together.

That's the great thing about our job. An engineer can't build a bridge by driving bigger and bigger trucks over it until it breaks, but we do have that luxury.

Answer 11

The best way is to have a collection of tests that will probably break if you break something. TDD is a great way to get those tests, but the most important thing is to have those tests, preferably a layer of unit tests and a layer of integration and/or acceptance tests.

Once you are paralyzed, you might want to look at the book Working Effectively with Legacy Code. This will help add tests and/or add features while keeping the odds of breaking everything very low. If its only a few days of coding, it should be much easier to add tests than some of the examples in the book.

Answer 12

In my experience, overcoming things like this involves becoming more aware of when you are doing it and what you are thinking when it happens. It sounds like you're already starting to do this.

If you ever find yourself avoiding coding / procrastinating, stop and think about why. For example, you think about it and realize that you feel afraid. Now try to think of what you might be afraid of. One example you gave was "destroying everything."

Now you've got to deconstruct that notion: You're using source control, so there's no chance you'll "destroy everything". The worst you can do is lose a little work.

If you frequently criticize yourself (mentally or verbally), deconstruct those criticisms as well. You might, for example, tell yourself "I hit a dead end, I'm a horrible programmer". You've got to correct yourself with more realistic thoughts, such as "I hit a dead end. It happens to everyone eventually. I even learned a few things along the way! This will make me a better programmer, not a worse one."

Answer 13

I get this way consistently - it's an anxiety problem for me, and a persistent thorn in my side. I get a burst of creative energy and some massive thing done, and then I stagnate. Meditative breathing when you find yourself getting distracted. Focus on the code in such a way that you're not thinking about features you have yet to implement, or how many bugs you introduced with the last bit. Just look at the code, unravel it, understand it. Start to see where your the tendrils of your fixes and improvements fit into what's already there. Get rid of distractions (like firefox and it's 180+ tabs of rabbit-holes of research).

And for god's sake, get some decent headphones and mood music.

Answer 14

As others have said: source control and comprehensive unit tests, to give you a safety net while changing code. But, more than that: comfort, confidence in those tools. And the way to get that is to use them. Take some code, get it under version control and well-tested - and edit the hell out of it. Delete methods and run your tests. Broken? Good: use version control to roll back. Run your tests again. Green, now? Cool: you know that you can count on version control. Hack at your code. Are your tests passing? Cool. Check it in. Hack some more. Still passing? No? Roll back. Repeat until comfortable. Repeat until you know you can count on the tests and the version control system; repeat until the fear is gone. Now you're cookin'.

Answer 15

Related to your query I want to write "To err is human"

So, no one is the perfect. Please be confident what you did? If you found any mistake or any other one alarmed you regarding the same. Take it as a challenge and I am sure the same will never be repeat in the future.

So, try to keep in mind you gave your best effort and lets wait for the best from the other hand.

Wish you a good luck!

Answer 16

Being sceptical about your code and questioning your approach is a healthy thing to do. It shows that you genuinely care and invest in what your doing which makes takes you closer towards the craftsman end of the continuum (and away from the hacker end!).

I have 3 suggestions:

• Keep it simple. If its not simple then its probably not structured correctly
• Break things out. Its better to have more classes with single responsibility than few complex routines (and give them good names)
• Talk it through. There is nothing better than talking through a problem with a colleague. We used to have joke about having a cardboard cut-out of each other next to our desks, because as soon as you start explaining a problem, a solution often comes to mind without any intervention from the person listening!

Answer 17

This recording from RubyConf 2008 may be helpful:

Fear of Programming (by Nathaniel Talbott)
http://rubyconf2008.confreaks.com/fear-of-programming.html

Answer 18

I think we all go through that one form or another.. It is quite natural. The more you realize that, the less it will bother you and the better you'll feel.. which will mean better code! I'd just focus on relaxing and moving forward.

Answer 19

In my experience, this happens once the code reaches a size where you start forgetting some details. As long as the program is small, you remember every block, every variable etc., but at some point, you can't do that any longer.

Solution: Learn to read your own code. Adhere to coding standards that make the effect of modifications assessable (avoid side-effects, hidden coupling and the like). Use methods like design-by-contract and unit tests.

Answer 20

Do not get emotionally attached to the code. It's just a tool to do stuff. It will always be crap, humans are not compatible with programming languages (that's why we write SO questions in English, not in C++) and will always produce crappy code because the whole idea is so foreign to us.

Try to do your job as best as you can. If you get the feeling "my code is crap", think "it always is, so why bother?". If you get the feeling "I should rewrite it, because it is crap", the next version will be crap too, so ask yourself the question "is it the time expense for rewriting this code justified by some other factor than my feeling that it is crap?". If no, just don't bother...

Answer 21

I know the feeling - I find that initially my code is simple so it's easy to keep everything in my mind at the same time, but as the complexity increases it's no longer possible to keep track of everything at the same time and I feel like I'm losing control.

The solution is to try and forget that this is your code and treat it how you would any other code - remember that code is only new as you write it, as soon as you come back (maybe 10 miniutes later) you are essentially maintaining that code and all the standard code maintenance tips can help you out.

For example I find that having a simple issue / bug tracking system helps me keep track of things. I'm not saying you should go out and install a fully fledged bug tracking application - a simple list in a text file will do the job.

Also it sounds like one of the most important things you could do with is a more rigerous testing plan - just keep a list of things to test and then every now and then go through and mark them all off as working / not working. That way you can be sure in your mind that it still works! (Unit tests are good, but theyre no substitute to actually seeing your app do the job you coded it to do)

Answer 22

What no one else has said is that if a phobia gets in the way of someone's work or your life, they may need professional help.

I'm not saying that's true of you in particular--it's probably not, but some people suffer from debilitating phobias.

If there's something practical you can do to alleviate the phobia, do that. But if the phobia is truly a phobia and doesn't seem to go away no matter what you do to modify the situation, then treat the phobia of ruining your code as you would any other phobia.

Answer 23

I'd highly recommend reading Working Effectively with Legacy Code. The definition of "legacy code" is "code that has no unit tests", which sounds like what you're dealing with.

This leads to the exact problem you're facing: having code that you're afraid to change because you don't know what problems that change will cause. It's too late for you to adopt TDD for the code you have (by definition TDD requires a test-first process). However, it's definitely beneficial to get into the habit of getting code under test when making changes to it. Usually "testing sprees" are counter-productive because there's usually no way to test your code without changing it. Therefore, a "test as you go philosophy works best.

Answer 24

This sounds sort of like "impostor syndrome" (not a disorder, but common problem in certain groups). It could also be anxiety. There are actually "patterns" for cognition -- refactor your head!

I am not a psychologist. But therapy (maybe only a session or two) can really help with some stuff. There may be simple steps you can take to help you get "unstuck" when you recognize that you're in that situation -- two visits with a psychologist might give you the strategies you need to get back in control. There are even computerized behavioural therapy systems in development, wikipedia tells me.

Answer 25

Have a good laugh at someone else's bad code. It can be humbling and sobering but for the most part it teaches you what not to do (anti-patterns/you don't have to repeat history if you know what to look for) and improves your self esteem (at least my code's not THAT bad).

Also, remember that you miss 100% of the shots you don't take. If doctors never operated for fear of the knife slipping, the patients would all die anyway. Take reasonable precautions (you've already got SCM) and let 'er rip--you only live once.