Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The interruptible programmer

stevestreeting.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: The interruptible programmer

#31

Post by HeyLaughingBoy »

Maintain context outside of your head at all times

I have a terrible memory and this is what I have learned to do. Long coding sessions? No; I design, then plan out a short amount of coding at a time. Especially if I'm modifying unfamiliar code, I'll make notes about what functions I need to change and what changes need to be done and in what order, and the possible side effects that may result so I can test for them. Leaving for the day, I'll just write down what I was last doing and what's next on a post it note and that removes the excuse of staying at work "just a few more minutes until I finish up this method."

In the end I find it's far more productive than sitting down for hours coding away. And a nice side effect is that it really doesn't matter if I'm interrupted because where I am and what I was doing is already documented.

Doing this forces me to think at a higher level about overall data & control flow instead of being down in the weeds all the time where it's hard to see the big picture.

Re: The interruptible programmer

#32

Post by rdtsc »

stcredzero wrote: post #28
singular wrote: post #11

The problem arises when you are focused on something very specific, for example designing a particularly complicated series of function calls, you effectively have to keep a stack in your mind, think about locals, instance variables, whatever, abstract stuff that the brain isn't so well designed at retaining, which becomes very vulnerable to disruption. If you are unlucky enough to be interrupted while in that kind o…

The problem arises when you are focused on something very specific, for example designing a particularly complicated series of function calls, you effectively have to keep a stack in your mind, think about locals, instance variables, whatever, abstract stuff that the brain isn't so well designed at retaining, which becomes very vulnerable to disruption. Let me ask this: after you've written such code, how is it for o…

Note he said "designing" not coding. When you design things, a lot of relationships and entities are in your head. If you are just fixing some unit tests or looking to do small cleanups or tweaks then yes, you can do that while chatting with your friend about the weather, and at the same time banging away at code in front of you. Your context is just 100 or so lines of code.

Re: The interruptible programmer

#33

Post by stcredzero »

peter_severin wrote: post #25

Keeping context outside of your head is a really good advice. I've been using Google Tasks for that and it works quite well for me. This way I also have the context with me on my phone and I can quickly note down ideas when I am away from my desk.While coding I progress through the list of small tasks and check them away.

This is an excellent tip. Sometimes something that I need to be careful about occurs to me on the way out the door. If I had the list accessible on my phone, I could just enter it when it occurs to me and have it at my desk when I return.

Re: The interruptible programmer

#34

Post by HeyLaughingBoy »

jacobolus wrote: post #13
gaius wrote: post #8

Earlier quoted context omitted.

It's 3 for lions. That's how lion taming works, the lion attempts to process each of the chair legs as a seperate object and has no mental capacity left to eat you.

I’m not sure how you came up with “3” (or for that matter how objects in view of a lion is comparable to “concepts” in the working memory of a programmer). As far as I know this idea was popularized by Errol Morris’s film Fast, Cheap, & Out of Control : http://www.errolmorris.com/film/fcooc_transcript.html “Dave Hoover: “The chair has four legs... Now, an animal has a one track mind, For instance, the animal is comin…

Wasn't that the film that profiled MIT's Rodney Brooks? (robotic subsumption architecture, Roomba?). I think we watched it for a graduate class in AI. It was good.

Re: The interruptible programmer

#35

Post by peter_severin »

stcredzero wrote: post #33
peter_severin wrote: post #25

Keeping context outside of your head is a really good advice. I've been using Google Tasks for that and it works quite well for me. This way I also have the context with me on my phone and I can quickly note down ideas when I am away from my desk.While coding I progress through the list of small tasks and check them away.

This is an excellent tip. Sometimes something that I need to be careful about occurs to me on the way out the door. If I had the list accessible on my phone, I could just enter it when it occurs to me and have it at my desk when I return.

Exactly! I went through a lot of setups but I think I'll stick with this one for a long time. I also use it to implement GTD for my everyday life by creating different lists for different contexts.

Re: The interruptible programmer

#36

Post by ajdecon »

Semi-related question: can anyone suggest a lightweight, easy-to-manage ticketing system that doesn't inspire hate? I've been seriously considering setting something like this up on my own server as a personal TODO tracker, but I don't know the space well.

Re: The interruptible programmer

#37

Post by epochwolf »

tel wrote: post #24
epochwolf wrote: post #22

Earlier quoted context omitted.

> I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem. Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code. It would really be nice for things to be simple but the reality is I'm dealing with…

"It is not possible to not end up in super brain mode with some of the problems I deal with." I'll argue that it is possible, just not necessarily preferable. You could rewrite the whole thing. You could also focus on building a number of small functions which brings the whole interface up to a human-digestible level. The reality of the matter is not the realm of possibility, but instead that you often just want to g…

> I'll argue that it is possible, just not necessarily preferable.

No, it's not possible. I do my best to minimize complexity but it's hard.

I don't have access to most of the systems I interface with. This is what I am talking about. The complexity is not just in legacy code but in interfaces I don't have control over. The project I mentioned was a complete rewrite and I'm able to modify most sections of it without tons of brain power. It's just the main report that's confusing as hell due to requirements.

When things external to code are complex you need brain power. You need to create abstractions and your abstractions end up being complex because you can't mask some of the requirements behind simpler code. There is also a problem of lacking tools. I have no ability to use a real debugger on any of the programs I work with. Only one application will run on my laptop, everything else is sitting in a carefully deployed minefield of interconnected dependencies on various linux servers.

Re: The interruptible programmer

#38

Post by praptak »

mattm wrote: post #15
praptak wrote: post #9

I have found the Pomodoro technique quite useful. Once I get off my ass to actually start the 25 minute work interval, the conditioning kicks in and concentration appears. Surprisingly, the first part (just starting) is harder than following through.

Interesting. I have never heard of this technique. I prefer working in 3 x 45 mins blocks. At 25 mins, I'm just getting into things.

It's a valid concern. A single 25 mins block might indeed be too short for a big task but in Pomodoro it's series of such blocks interspersed with 5 mins breaks.

YMMV, but I've found out that the 5 mins breaks do not destroy my "state", as long as I don't start anything that tends to suck in like playing games or browsing the Web. Fetching coffee, going to the toilet, etc. is OK :)

Anyway, the hardest thing is usually starting the first block.

Re: The interruptible programmer

#39

Post by gaius »

philwelch wrote: post #14
gaius wrote: post #8

Earlier quoted context omitted.

It's 3 for lions. That's how lion taming works, the lion attempts to process each of the chair legs as a seperate object and has no mental capacity left to eat you.

If you're worried about the lion eating you, you can just feed it until it's not hungry. Lions are surprisingly not vicious towards humans at all--since there's no species that can fuck with them they don't have the vicious fear response most animals have. That's the real trick to lion taming--and the reason you can tame a lion but not a jaguar. Tigers are the same way. The big danger with either of them is actually…

I'm not worried - me and Aslan get on just fine. So long as you remember he's not a tame lion.

Re: The interruptible programmer

#40

Post by LeBleu »

tel wrote: post #24
epochwolf wrote: post #22

Earlier quoted context omitted.

> I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem. Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code. It would really be nice for things to be simple but the reality is I'm dealing with…

"It is not possible to not end up in super brain mode with some of the problems I deal with." I'll argue that it is possible, just not necessarily preferable. You could rewrite the whole thing. You could also focus on building a number of small functions which brings the whole interface up to a human-digestible level. The reality of the matter is not the realm of possibility, but instead that you often just want to g…

I'm amused that you think it is possible to rewrite the whole thing without entering super brain mode. In my experience, generally the only way to reproduce such legacy reports is by reverse engineering how they currently work. (which will require super brain mode based on the above described current complexity) One would think someone in the business would know what the report is supposed to do, but I frequently encounter cases where no one does, they just want the report to work the way the old one did, whatever the heck that was.

I know of no solution not involving time travel to solve that for legacy reports and systems. Obviously going forward one can worry about documentation, etc. but with legacy stuff it is already too late to implement those rules.

Post reply on HN