Comment by calineczka | Hacker News Reader

Comment by calineczka | Hacker News Reader

Once upon a time I was working with a very challenging legacy code and I was building similar constructions in my mind. The office was sometimes noisy and chance of interruption was not that small. So I established a habit of writing kind of stack trace of my own thoughts so that I could easily come back to my state of mind after such thing. It looked like:

  There is a bug in module X
    Module is X is calling module Y when user is not yet activated
    We are creating user subscription
      We are using current subscription in subscription creation
        Current subscription is A when user is not activated
        Current subscription is B when user is activated
          Probably bug in method c()
            Think what is going to happen in situation M when changed the implementation to d().

The list sometimes had 12 elements that I was trying to fit in my head to find the solution to the problem. I now work remotely from home (quiet and all that) and most of the code that I work on is of much better quality (another company, better practices) but I still sometimes resort to this method when working on a complicated piece of code that is unfamiliar to me.

This is a common technique in engineering troubleshooting http://en.wikipedia.org/wiki/Ishikawa_diagram http://en.wikipedia.org/wiki/5_Whys

I never thought about it as something that can have such fancy name and such broad engineering application. I think my technique is like 1% of what Wikipedia describes.

This is the kind of revelation that brings me back to hacker news!

The old "So you want to be a success at selling?" training video starring John Cleese has a wonderful example of (roughly) the Five Whys applied to sales.

(It can be seen at http://www.videoarts.com/sales-and-negotiation/so-you-want-t... at 15:15 , but alas only after registration now.)

Wasn't the latter inspired by kids? https://www.youtube.com/watch?v=BJlV49RDlLE

Ishikawa diagrams and the 5 whys are quality control tools, specifically root cause analysis tools.

What OP mentions is taking notes of his though process as he goes along, so he can jump back in after an interruption.

Yup! Same thing here.. the fact that I've got terrible ADD doesn't help - I keep such a "stack" open on stickies on the corner of my screen open so I can avoid drifting and stay on task.

It also provides a visual level of how deep you are into "shaving the yak" - once you're 10 levels into a problem, it becomes easy to forget what the original problem was.

http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gs...

I do similar to manage my stack — without it, more often than not, I find myself with a "blown stack." But these days, I'm actually using physical index cards. I've given up on todo apps — even ones that provide arbitrary nesting/trees (e.g. org-mode, Worfklowy, etc.).

I've considered using a simple stickies app, but there's something about pencil and paper that I find beneficial — or at the least, comforting — and I haven't quite put my finger on it. Not sure if it's the ability to do free-form sketching, or that I can quickly physically shuffle/order/arrange the cards, or that I can jot things down without needing to be at my computer/on a mobile device — or just being able to step/look away from a screen for a bit.

I'm thinking most likely it's that whatever added functionality or benefits I would get from using an app to manage this stuff would be offset by me fiddling around with features, settings, tweaks, etc., and screwing around "evaluating" different tools.

That's the same thing I've run into. It's a never ending cycle of trying an app (I love Omnifocus, it's just too much to deal with at times), reverting to something simpler (stickies app), yearning for some extra piece of functionality that doesn't exist (gee it would be nice if...), and then repeating the whole cycle over again.

I think meta-productivity is just too much damn fun to leave alone.

I'm the exact same way: I need a physical medium when it comes to notes, etc.

I discussed it with a another friend of mine (a business guy) who similarly prefers notes/notebooks and we seemed to hone in on the fact that its superiority over non-physical mediums comes from its freeform nature. The freeform nature allows you to record things in a format that more accurately models the way your mind works. This makes it easier to come back to and have your brain go "Aha yes I have a memory stored for this data because I created this note". With a physical medium, you're never (or at least, much less so) forced into any format that was created by another person (to-do apps, etc.).

"A problem well stated is a problem half solved"

Also see the Kepner-Tregoe method. Doing the "is, is-not" step really helps narrow it down.

Programmers have been doing this from more than half a century. Its called debugging.

Its basically to learn to localize the problem to a specific part in the code/system. Study the inputs and outputs to that system. Establish single responsibility to that part of the code. Now study the input and expected output from that part of the code. If they mismatch, correct the code and test it out for all possible values of the input.

Additionally automate it/check list it such that those mistakes are not made in the future.

When you are dealing with multiple systems and sub-systems, it's not so easy.

I have endless TextEdit files strewn around my hard disk with very similar contents, I need to hoover them up every now and again. It's really useful to type something out like this, even just to map the problem out in your mind.

I have one file - currently 12,000 lines long :)

I found it useful to start writing an email to some people concerned. I usually start with "it don't work", then because I don't want to look stupid I explain a bit what doesn't work, I feel the need to explain my thought about why do I don't look like unimaginative, and then I write down how I would check if I'm right, because I don't want to look like I'm not scientific, then I just try the test because I'm not supposed to be lazy, and then usually I trash the email because I found the bug.

sort of the equivalent of rubber duck programming? I've been known to do that a few times.

This is one of the reasons I like to provide detailed commit messages, and encourage my team members to do the same. I treat the commit message like a short email to the team (even if that's only future me) about why and how I made the change. Summarizing the change in writing often uncovers logical flaws or missing edge cases. I've aborted my commit (after copying the notes for reference) more times than I'd like to admit when I've realized that I've not thoroughly tested something or missed updating that admin report that would be affected, etc. The act of 'telling someone' exercises different pathways in the brain and helps you think about the problem differently. As someone already pointed out - it's a flavour of rubber duck programming. It also works really well in a team environment where your CI system emails the whole team the commit notes. You get a low ceremony quick design review. "Did you update the X system/form/report when you changed Y?" replies happen more often than you think, and junior devs can actually learn a lot about an existing system just by seeing the approach used by other team members.

It's also a miniature version of literate programming. You can go through all the commits and get an explanation of how the program evolved -- not just the actual lines changed.

You might find Notational Velocity helpful - http://notational.net/

It becomes even more helpful when you realise that you can plug Notational Velocity into SimpleNote and sync across ALL THE DEVICES!!

I use NV on MacOS, the SimpleNote app on iPhone and iPad, and the SimpleNote website on Windows.

I do this same thing, but in a variety of circumstances. I find it not only helps me to keep my place, but the act of writing out or diagramming ideas helps me think and reason through problems better than if I just try to work them out in my head.

This is an interesting technique that I hadn't considered before. I can see that it would be useful when traversing unfamiliar code. Will try it out next time.

I was doing this in an open plan office using workflowy — surprisingly effective. It's almost as if you're doing a human equivalent of a context switch.

Never seen workflowy before ... love it!

I find it really helpful to write little notes and diagrams to help visualise the problem and as a basic mnemonic technique. There's not much space in your short term memory so it's better to offload some of the work if you can. I've started reading Your Brain at Work. It explains how your brain operates in laymans terms and offers some workarounds for common problems.

Reply on news.ycombinator.com