7 ms·
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 chanc
by calineczka 13y ago
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.
- civild 13y agoI 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.
- aidos 13y agoI have one file - currently 12,000 lines long :)
- gbog 13y agoI 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.
- penguat 13y agosort of the equivalent of rubber duck programming? I've been known to do that a few times.
- allannienhuis 13y agoThis 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.
- tanzam75 13y agoIt'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.
- gyaresu 13y agoYou might find Notational Velocity helpful - http://notational.net/ http://notational.net/
- jackgavigan 13y agoIt 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.
- Maxious 13y agoThis is a common technique in engineering troubleshooting http://en.wikipedia.org/wiki/Ishikawa_diagram http://en.wikipedia.org/wiki/Ishikawa_diagram http://en.wikipedia.org/wiki/5_Whys http://en.wikipedia.org/wiki/5_Whys
- calineczka 13y agoI 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.
- gmt2027 13y agoThis is the kind of revelation that brings me back to hacker news!
- leoc 13y agoThe 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-to-be-a-success-at-selling/ http://www.videoarts.com/sales-and-negotiation/so-you-want-t... at 15:15 , but alas only after registration now.)
- rikibro 13y agoWasn't the latter inspired by kids? https://www.youtube.com/watch?v=BJlV49RDlLE https://www.youtube.com/watch?v=BJlV49RDlLE
- MortenK 13y agoIshikawa 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.
- alexfarran 13y agoI 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.
- aidos 13y agoThis 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.
- jpswade 13y ago"A problem well stated is a problem half solved"
- gaius 13y agoAlso see the Kepner-Tregoe method. Doing the "is, is-not" step really helps narrow it down.
- kamaal 13y agoProgrammers 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.
- Swannie 13y agoWhen you are dealing with multiple systems and sub-systems, it's not so easy.
- socksy 13y agoI 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.
- philjr 13y agoNever seen workflowy before ... love it!
- jbl 13y agoI 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.
- Karunamon 13y agoYup! 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/gsb2000-02-11.html http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gs...
- wavetable 13y agoI 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.
- Karunamon 13y agoThat'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.
- khalilravanna 13y agoI'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.).