Is it normal that I can't keep in my head more than three bugs assigned to me, nor can I understand a thousand lines of spaghetti code?

Question

I'm working on an old codebase which is... not perfect, in an environment which isn't either. It's not the worst codebase I've seen in my life, but there are still lots of issues: zero unit tests; methods with thousand+ lines of code; misunderstanding of basic object oriented principles; etc.

It hurts to maintain the code.

1. Every time I have to debug a thousand lines of a badly written method with variables reused all over, I'm totally lost.
2. Some modifications or refactoring I've done introduced bugs in other places of the application.
3. Lacking any documentation, tests, or an observable architecture and combined with badly named methods, I feel that I fill up all of my available working memory. There is no room left over for all the other things I have to remember in order to understand the code I should modify.
4. Constant interruptions at the workplace disturb me and slow me down.
5. I can't remember more than two or three tasks at a time without a bug tracking system, and I forget all of them over the weekend.

My colleagues don't seem to have similar issues.

1. They manage to debug badly written methods much faster than me.
2. They introduce fewer bugs than I do when changing the codebase.
3. They seem to remember very well all they need to in order to change the code, even when it requires reading thousands of lines of code in twenty different files.
4. They don't appear to be disturbed by emails, ringing phones, people talking all around, and other people asking them questions.
5. They don't want to use the bug tracking system that we already have since we use TFS. They prefer to just remember every task they should do.

Why does this happen? Is it a particular skill developers acquire when working with badly written code for a long time? Does my relative lack of experience with bad code contribute to these problems / feelings? Do I have issues with my memory?

Answer 1

Yes, it is normal for structured people to be affected by unstructured code/environments. Your colleagues probably are better filtering out all the background noise. As a migraine sufferer I know my ability to filter out my environment greatly drops when a migraine is coming on. People vary.

The same is true for the code, your colleagues have probably learned to filter out the "code noise" that comes from multiple levels of abstraction in a single method and have become adept at "chunking" the code into larger areas of functionality.

It simply takes time to adapt to a code base such as the one you describe. Your colleagues probably have had much more time to grow into it and possibly have picked up on conventions, patterns and constructs that don't jump out on "code base novices". There may be more structure to the chaos than you can imagine. Talk to your colleagues, ask them to pair with you some time and pick their brains on how they approach solving one of the bugs assigned to you. When they ask you to open unit X, Y or Z, ask them why that one, what about it is telling them it may be relevant, etc.

Being lost in a thousand-lines method is normal. Attack it with a good folding editor and adding comments to chunk the various parts into functions and/or procedures without actually doing so. Printing the stuff and using an old fashioned highlighter can also help.

Refactoring without the safety net of unit tests is shooting yourself in the foot. Don't. Just don't.

Nobody is requiring you to keep everything in memory. If your colleagues don't want or need a bug system, just write the task assigned to you in your own todo list and write notes when/after talking with someone about the details of your tasks.

Answer 2

there are 3 main points that I see:

points 1, 2 and 3 stem from the fact that your colleagues are simply more experienced with the codebase which means they know its quirks. This means that they use their long-term memory for the debug process and can remember that doXYZ actually does UVW but was never renamed for historic reasons. however should they ever take a few months of from coding on it then they will start to feel your pain.

for point 4 resist interruptions, don't let non-urgent business take you out of the zone, it takes a long time to get back into it after an interruption; set the company's IM to busy, try to schedule in long blocks (full afternoons) of just coding

for point 5 second create an excel sheet with the bugs you are currently working on as your personal todo list, (or use the task management capabilities in your IDE), I'm willing to bet that some of your colleagues are doing the same

Answer 3

Doesn't sound like memory issues to me. It sounds like you your work habits/tendencies aren't a good fit for what you are encountering, and you're doing too much thinking about your colleagues and not yourself.

1. Thousand line method--everybody is going to be lost on that unless they just worked on it. They may be quicker at picking it up or getting it back. You can't change that except through experience, and maybe not even then.

2. Refactoring introducing bugs, well, that's always a risk. You can try to develop unit test to cover what you're changing before doing so, but that may not be allowed by management (probably not, or it would already be done). And unit test aren't magic they can still miss things, you can still introduce bugs. Chances are they just aren't refactoring. This goes back to (1), they probably try to focus on just what needs to be fixed, meaning they get to the point faster, but miss the bigger picture, and will take longer to fix the next thing in that thousand line mess.

3. Create what you need to get the job done. If that means creating a flow chart or some other documentation, then do so. Whether they need it or not, and whether they use it or not after you have created it, is irrelevant.

4. Interruptions slow everyone down. Focusing on that will just slow you down more. Accept it and try to get back in the groove as quickly as you can.

5. Keeping two or three bugs in mind ain't bad, three or four would be better, but instead of trying to improve that, give up and write it down. Piece of paper, whiteboard, tfs, excel, word or notepad -- just write it down. I bet that's what your colleagues are doing. Either that or fixing things at random.

Programming isn't about a perfect memory, and it's not about being able to ignore distractions -- focusing on this are just distractions that you are creating.

Answer 4

CAVEAT/UPDATE: After reading the below answer, I felt it might be feel a little too harsh. Not my intention, the environment you describe is terrible and it would affect most people (probably even the better programmers suffer it, but they are "better" by comparation with others in the same environment). My answer is just a point-by-point reflection in your questions, assuming that the environment won't change (even if it should).

Totally opinable answer:

1) That depends of experience in the technology, in maintaining the application(more if it is bad designed) and even in specific parts of the application. Also depends of your concentration problems (number 4)

2) It is the same than number 1, but using a different metric. Same answer.

3) noteblock and pen. Or a word/excel document. Not that hard to solve.

4) that is a personal issue of concentration. Not sure if it is viable to improve it by yourself, though.

5) using a ticket system or not should not be decided by the programmers but by the project manager. Ask his opinion/present your points. If he is against it, noteblock and pen again.

Answer 5

I have been through a situation like that before and based on that experience I can say that your problem is not memory related and that there is something on your mind (most certainly not work related) that is making you stressful and keeping you from focusing 100% on the task at hand.

So the first step is to clear your mind from that stuff when you are in your desk.

That stress might also be increased because you feel like you are getting behind in terms of productivity, so try talking with your coworkers and ask them for tips on their approaches to the refactoring.

Finally don't feel embarassed if you have to write down the issues you have solved and/or are working right now (it desn't have to be a sophisticated bug tracking system) it's better to be certain of something because you read it from your notes than stating it off the top of your head while not being 100% certain of it