I don't have much experience in working in software industry, being self-taught and having participated in open source before deciding to take a job. Now that I work for money, I also have to deal with some unpleasant stuff, which is normal of course.

Recently I was assigned to add logging to a large SharePoint project which is written by some programmer who obviously was learning to code on the job. After 2 years of collaboration, the client switched to our company, but the damage was done, and now somehow I need to maintain this code.

Not that the code was too hard to read. Despite problems—each project has one class with several copy-pasted methods, enormous if nestings, Systems Hungarian, undisposed connections—it's still readable.

However, I found myself absolutely unproductive despite working on something as simple as adding logging. Basically, I just need to go through the code step by step and add some trace calls. However, the idiocy of the code is so annoying that I get tired within 10 minutes of starting. In the beginning, I used to add using constructs, reduce nesting by reversing if's, rename the variables to readable names—but the project is large, and eventually I gave up. I know this is not the task I should be doing, but at least reducing the mess gave me some kind of psychological reward so I could keep going. Now the trick stopped working, and I still have 60% of my work to do.

I started having headaches after work, and I no longer get the feeling of satisfaction I used to get—which would usually allow me to code for 10 hours straight and still feel fresh.

This is not just one big rant, for I really do have an actual question:

Is there a way to stay productive and not to fight the windmills?

Is there some kind of psychological trick to stay focused on the task, instead of thinking “How stupid is that?” each time I see another clever trick by the previous programmer? The problem with adding logging is that I actually have to understand what the code does, and doing so hurts my brain in an unpleasant fashion.


11 Answers 11


I'm sorry to tell you, but not all jobs are full of sunshine and glamor. The majority of development tasks involve drudge work like this. Sad, but true.

You are tasked with an important job, even if it's boring to the point of watching paint dry. It's important for two reasons: 1. It add much needed logging to a large system so that when something goes wrong you'll have a tool to help you find it. and 2. It gets you familiar with the code base so that if and when something goes wrong you can jump in and fix it.

You are basically creating your own safety net here. Glamors, no, but important yes!

So, that being said how should you motivate yourself? When I have a mind numbing task at work, I set goals for myself. Finish doing task x by the end of the week. If I make my goal, I reward myself. New restaurant I want to try? Go Friday night if I finish. New movie just came out? See it on the weekend if I finish.

I find talking with my supervisor and letting him/her know where I'm at and how I'm progressing keeps me accountable. If I tell them I'll be done by Friday, I feel more inclined to get it done by Friday b/c I told them I would have it done.

Keep faith that once you complete this task and you've done it well, on time and on budget that people will notice and when that shinny new project comes along, your name might just be suggested as the one who gets it. :)

  • I especially like the point about Friday motivation. It's funny that current release is also scheduled to Friday. I think it's worth adding that gratitude motivation is a moving one. You need to ensure someone's going to be grateful for your work, or else change what you're working on. Sincere ‘thank you’ often rolls back restless hours.
    – Dan
    Commented Feb 22, 2011 at 17:53
  • 1
    @gaearon - I'm glad that the suggestions are helpful to you. Getting through the drudge work with a good level of motivation will pay off in the end. Last year at my current job, I had to do something similar to what you're doing. This year I was given a brand new app to write from scratch. People will notice what you do and how well you work.
    – Tyanna
    Commented Feb 22, 2011 at 18:54
  • 5
    -1 Why link your work life and personal life? This sounds similar to staying overtime consistently - I didn't finish my under-estimated task by Friday - so I need to stay at home and feel bad.
    – Vorac
    Commented Jan 3, 2014 at 16:56
  • @Vorac ~ I said that's what I do to motivate myself. Everyone is different. And I can assure you, I don't work OT consistently. Find something that motivates you and use it. I find a material reward works best when I have a task I don't want to do.
    – Tyanna
    Commented Jan 7, 2014 at 18:21
  • 1
    @IntegrityFirst ~ For me, yes. I will stay late to finish my todo list. I will budget my time to make sure I hit it. It's my integrity to myself and to my coworkers to complete something when I say I'll complete it. But, if I discover something can't be done in the time I've said, I change the plan and let my supervisor know. And if I finish a bit late, the movie/restaurant will be there next week. :)
    – Tyanna
    Commented Nov 10, 2014 at 14:59

Keep a file of candidate code snippets for submission to thedailywtf.com. Even if you don't really intend to submit them, it gives you a bright side to finding some code that's even worse than average.

  • I wish I could upvote it one more time. It turned out to be a really great suggestion, now that I found that these guys store their changelogs in application configuration files, right before actual settings.
    – Dan
    Commented Feb 22, 2011 at 21:33
  • Lest someone out there take this joke seriously, beware that companies can be very sensitive to developers sharing code, especially on the public internet, even if it's meaningless on its own or without context. You might get yourself fired.
    – Alain
    Commented Jan 3, 2023 at 20:37

I was in a similar situation, tasked with cleaning up a large body of poorly written, massively copied-and-pasted code.

To maintain my motivation and my sanity, I wrote a script called current_score that counted the LOC in the project (which steadily decreased, as I eliminated duplication and switched to better algorithms) and compared it against the LOC when I started. Whenever I got discouraged or frustrated with the mountain of code I was facing, running current_score would give me a sense of tangible progress and would remind me of how much I'd already accomplished. And it was fun to see just how high of a score I could rack up when tackling a particularly bad section of code.

I'd look for similar metrics that you could easily script to give yourself a sense of progress and to turn it into a game of sorts. Lines of code (just run wc -l), cyclomatic complexity (which should go down as you clean up those nasty nested "ifs"), lines of code which have been touched by you instead of your predecessor (I think that FishEye can tell you this for $10), etc. You could even write a Perl script without much trouble to count the number of code blocks that don't yet have logging statements.

  • I use SourceMonitor
    – UmNyobe
    Commented Jan 7, 2016 at 13:41

I've seen this book recommended: Working Effectively With Legacy Code, but luckily haven't had a need to read it.

Like you are doing, refactor what you need to so that you can understand the code and just remember that you are resuscitating a system, which will pay off when you're maintaining it.
That should hopefully put a spring in your step on the way home.

  • 2
    This book is about refactoring existing code to make it testable; I don't think it's going to help much in the way of motivation. Commented Feb 23, 2011 at 17:14
  • 2
    Good point @Billy ONeal, but having testable code and the associated metrics can show progress which could be motivating.
    – StuperUser
    Commented Feb 23, 2011 at 17:23
  • 1
    I've read this book. Definitely worth reading. I actually did find WEWLC motivating just because it was nice to know there was someone out there who understood the exact sorts of frustrations I was having and had devised effective ways to mitigate those frustrations. Commented Oct 3, 2014 at 14:24
  • 1
    That book is kinda old and outdated. If you didn't read it, why do you recommend it? Commented Jan 22, 2016 at 7:48
  • 1
    @StuperUser As I read it, I can say it is outdated, and can provide some useful advices for novice users. Commented Jan 25, 2016 at 8:18

Try to break the project up into chunks. Each day learn how a specific chunk works. Trying to understand it all at once is probably what is stressing you out.

Take pride in making the project better. Are there other coders you can talk to? It helps to stand around the water cooler discussing/laughing at the latest logic you found. I try to do this to keep a jovial atmosphere at work.

  • Yes, I'm working by chunks, and I already have been working on it for some time so I have a rough idea about each component. Still, it doesn't help much because it's the tiny pieces of logic that usually take time to understand—and I get angry when I realize that 30 line method I spent 10 minutes on can actually be re-written in 2 lines. As for the company, unfortunately, I'm the only developer on this project, and I'm currently working in client's office so there's no one I could really talk to.
    – Dan
    Commented Feb 22, 2011 at 17:04
  • @gaearon - What prevents you from implementing your 2 line solution? You need to figure out how to do what you were tasked to do, the problem with the code can be solved later, when you are not in the client's office. You should keep your notes on what you did, how something works, so you can go back later in the future and implement your changes so code review(s) and integration testing can be done.
    – Ramhound
    Commented Feb 22, 2011 at 17:16
  • @gaearon ah-ha! You're the only coder. So the guy before you was the only coder. You can get away with a lot when you are the only coder (as you've noticed from your predecessor). Keep this in mind when you look for your next job. ;) Commented Feb 22, 2011 at 17:43
  • @Ramhound I'm betting there won't be any code reviews. I bet there won't be any formal integration testing. I've worked in these positions a few times. Generally people only want code that works good enough, and they want it as quickly as possible. Explaining "best practices" is like talking to a wall, IMHO. Commented Feb 22, 2011 at 17:44
  • @Ramhound, there are no tests for this project, and I don't want to be responsible for ruining the system for the sake of cleaner code. There are many cases when current code implies exceptions being swallowed, or else relies on other kinds of bad behavior which is not obvious. This is one of the reasons I'm adding logging, by the way.
    – Dan
    Commented Feb 22, 2011 at 17:56

Take extensive notes to organize your questions, thoughts, and understanding of the system. This has worked wonders for me when dealing with large legacy systems. It helps crystalize your understanding, helps put the open questions into words, and because your thoughts are already put together it makes it easier to communicate spontaneously with others about problems/questions/ideas/etc.

As an example, as I'm going through a piece of the code, I'll be taking notes to myself constantly. This is my conversation with myself. The mere act of writing helps more thoughts come out and helps me understand things better. After a while I may have a Eureka and need to draw out a little diagram with the "bigger picture" on paper to illustrate what I just thought of or what pieces I just put together. I always do this on paper only, getting rid of all the distractions of the computer. This lets me be more methodical and thoughtful about what I'm doing.

This is basically a convenient way to have a perpetual conversation with a domain expert :)


I know you may feel unproductive because you're looking at it from the perspective of 'I'm only adding logging' when in fact, you're adding logging and doing a lot of refactoring. Your supervisor is probably aware of the code situation. Everyone may not appreciate it now, but when you get a request to add a really interesting and challenging feature, you'll be glad you cleaned up the code.

  • I'm afraid I'm going to end up rewriting the project, we already talked about that. Although I like this option better, it doesn't add productivity in working on throwaway code. I know logging is required in next release, and then I can go with my stuff, but it's just having-to-run-this-code-through-my-head that makes me crazy. I feel like I'm getting dumber after understanding it :-)
    – Dan
    Commented Feb 22, 2011 at 17:28
  • 1
    "it doesn't add productivity in working on throwaway code" Suuure it does. You get to go through large portions of the code working on your understanding of it, while performing a low risk task (logging). This knowledge you are gaining will help immensely if it comes to a rewrite. If there's not a rewrite try to look forward to the reward you will feel when you've cleaned up large amounts of the app, how much better the code base will be due to your consistent and persistent efforts. Commented Feb 23, 2011 at 7:36

Gamify your work. For example, give yourself 5 points each time you ask a good question about the code, and 10 points each time you answer it. Give yourself a badge each time you refactor a method or add a new feature. Once you accrue enough points you get privileges like coffee breaks or biscuits. Once you complete the whole project you get the privilege to treat yourself to something you really want.


In these Cases I tend to rewrite a section of code. To make one area suck less and then I just add logging some where else. Then clean up some more code. Bad code is only bad if you leave it there.

  • System heavily relies on bad practices so to rewrite a method properly I would have to rewrite the whole project (which I probably will do eventually but I have some deadlines for current release).
    – Dan
    Commented Feb 22, 2011 at 17:19
  • Ya I understand believe me. I just pick off a section I can clean up with out making my life to painful and clean it up and then the next area. Fixing code is a process that you never get time for but should always make time for.
    – Erin
    Commented Feb 22, 2011 at 18:15

The trick to not getting bored or angry so you stay productive is to accept that the code is poorly designed. Accepting your position to having to understand and update the code will allow you to not keep commenting on "how stupid that is" and instead quietly accept it and move on.

Another trick is having a good homelife to look forward to at the end of the day. Girlfriend, friends, games anything will work, to give you a goal to get through the day and make the trudging though bad code all worth while.


"Working Effectively with Legacy Code" by Michael Feathers may help.

If you're worried about breaking things when you change them, write some tests first, make sure they pass before and after you make your changes. Writing the test should help you to summarise and understand what a given piece of code does and will allow you to edit with confidence.

  • Unfortunately, it's SharePoint project, meaning it's almost untestable. I've written some cool sandboxing for SharePoint in the past using Microsoft Moles but it requires a lot of additional work.
    – Dan
    Commented Feb 23, 2011 at 16:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.