How do you deal with Brain Buffer Overflow?

Question

This is probably an old topic, but I just ran into it again, and it sounds like a good area to look for other ideas.

The library I am working on has a bug that I am having difficulty isolating. In fact one of the things that happened in the last day or two, was the size got too big. The amount of detail is so large, I can't keep the whole thing in my head.

I call this Brain Buffer Overflow.

There are many techniques available to help reduce the size of the stuff you need to fit into your head, so there is room for more important stuff.

• Breaking things into functions, so you deal with the interface, rather than the internal details.
• Same thing for classes. Hide the dirty implementation behind a class interface, so you don't have to think about the details.
• I print source listings and tape them up on the wall, so I have a more global view than what is available, though my 22 inch lcd monitor.

What techniques do you use to help keep unneeded stuff out of your brain buffer, so you can deal with larger problems?

Answer 1

I like to make notes to myself on a notepad documenting which pieces of the code work and which don't. This helps me to put the working pieces out of my mind.

I like to think of writing to a notepad as "writing to a hard drive". It's out of my short-term memory, but I can still pull it back up if needed.

Answer 2

I find that writing things down means I don't have to keep them in my head, and lets me focus on the part of the problem that needs my attention.

It's also a great idea in your situation to talk the issue through with somebody else. It's amazing how new ideas can come up very quickly from just talking out load about the problem.

Answer 3

I keep a running list in a note taking application of working parts and not working parts.

Answer 4

What are you referring to as too big?

If it's a particular class/method, you might want to reconsider the design of your classes/methods.

Answer 5

I stopped trying to fit things into memory, I try remembering the causes alone. This helps in reconstructing the problem with some analysis. The symptoms just go into notepad. Same applies for 'todos'. Cann't afford the cost of failure , so have a back up plan.

Answer 6

I whiteboard the big ideas - nothing fancy, just bubbles and lines.

I don't even attempt to keep all that stuff in my head. Instead, I take advantage of technology and throw my thoughts and notes into something that can be easily searched and tagged. I will Tiddlywiki notes with a limited set of tags so I can free my brain from needing to hold it all.

In the end, I don't think there's a really compelling argument for filling your head full of your program libraries. You're going to remember some of it, of course, for the rest, use the PC in front of you, the white board on the wall, and paper for quick notes. Long term stuff can get stored in a wiki, like I do, or simply on a drive that can be searched quickly.

Works for me.

Answer 7

Write thing down, I keep a list of line of code that have issues on a pad next to me, or in a notepad on the computer.

score them out at they are solved.

As far as issues with a huge codebase are concerned, refactor refactor refactor.

I sometimes print out code that is hard to grok and annotate it, but usually it's a waste of paper.

Answer 8

I suggest to do less effort in trying to solve the problem using your analytical side of the brain and let the creative side do the work. Go for a walk and don't think in your problem, luckily the answer will appear magically.

I recommend you to read "Pragmatic Thinking and Learning"

Answer 9

You should read Code Complete 2 by Steve McConnell, he talks about this problem.

He suggests using functions and classes to help overcome the inherent complexity by utilizing them as tools to accomplish several layers or levels of abstraction (besides hiding the dirty implementation). That way you would only have to deal with one level of abstraction at the same time.

EDIT: Joel Spolsky has some interesting thoughts on the subject, he talks about leaky abstractions

Answer 10

I do all of the following:

• whiteboard
• write notes
• explain it to someone else
• use multiple monitors
• take a break
• use a higher-level language (when appropriate/possible)
• refactor
• delegate coding/design/whathaveyou to others