8 ms·
The Interruptible Programmer (2010)
- chrisbuc 6y agoWith "Stop trying to make hard work easy" [1] on the HN front page, it reminded me of this that I refer people back to regularly. [1] https://news.ycombinator.com/item?id=23154519 https://news.ycombinator.com/item?id=23154519
- partyboat1586 6y agoThis guy's strongman "I've got news for you" philosophy is productivity porn. I do like the idea of the focus crown if you've got kids though, that's a good one.
- julius_set 6y agoI have the opposite problem I can sit and focus for hours and hours this causes me health issues as sometimes I forget to take care of myself
- 7thaccount 6y agoI know you're serious, but if taken in good humor, this almost sounds like Dilbert's response to the interview question of what do you do badly. He gets nervous and says something like "I work so hard that I forget human hygeine and start to rot in my cube" or something along those lines. I've been up against some rough deadlines where that comic really came to mind :).
- julius_set 6y agoHa funny you mention this I actually said something similar though not as descriptive as what you stated in an interview before. I’m arguing this is not such a great thing because I’ve noticed a few things that have occurred due to me being like this: The gf will complain, a lot, that you don’t spend enough time with her. You disregard eating sometimes (and I try to stay as fit as possible, sometimes I will just forgo gym because work > everything) I have almost 0 balance for personal life, most of time from waking up is straight to
- 7thaccount 6y agoI know it's difficult, but do take care of yourself. I'm not sure where you live, but we prioritize work over life too much in many places (America, Japan, probably several others). A healthy job in my opinion allows you to make enough money to not worry about your finances too much and enough time to enjoy the truly important things in life (family, friends, excercise, hobbies). Everyone is different though and some people seem to really enjoy the stress of a high profile position (Ex: Musk) and many scientists that live to work. To each his own. If you're feeling burned out, consider trying a new job. If you're in Silicon Valley, you can likely find a good IT job in much of America that pays well in a probably much cheaper area and that allows you more time to pursue a better work life balance. Personally, everything changed for me when I became a Father. I still love my job and put in a lot of hours, but I take time to spend with my family too. Don't feel guilty about it.
- teddyh 6y agoHere is the strip in question: https://dilbert.com/strip/1995-04-16 https://dilbert.com/strip/1995-04-16
- Izkata 6y agoWow, Dilbert really slimmed down since then. I guess it wasn't an interview lie, only exaggeration.
- MattGaiser 6y agoI love this phase though. It is a period of enormous creation. Just make sure to take a shower after.
- valuearb 6y agoSome good thoughts in this.
- RangerScience 6y agoAll of this is a huge part of the reason I love TDD. It's a checklist, and I've always got my next item, and my working state is by and large in the code. I can even code while VERY distracted (meetings, cough cough) and succeed (albeit slowly). It can help with the tangential issues; maybe I whip out a (failing) test, or maybe I just mantra "only fix this one test".
- taneq 6y agoThese are all great points in favour of TDD. They're a ratchet on your code that lets you crank it out in small increments without losing much progress. I feel like this only helps with distractions and interruptions, though, if you're doing routine work that you already fully understand and can code 'off the top of your head'. Admittedly this is the entirety of many software jobs and the bulk of even the most challenging, but there's still sometimes a need for time to think unimpeded.
- RangerScience 6y agoMore or less the case here; wrote this project, now refactoring and adding tests. Not every part of it could be done while 'distracted'. Good testing still helps with distractions because good testing enforces a code style that's very bite-sized; so if your 'tasks' are 20-40m, you can fit a lot of distractions. Also, each task (generally) by virtue of being so small takes up less mental RAM, so you don't have to page out as much when a distraction happens. Also makes it easy to work "around" the hard part, and come back to it when you know you'll have that uninterrupted time. Or late that night when inspiration strikes and now it's easy :)
- thesz 6y agoI wonder, what kind of problem domain would allow such small and local programming?
- RangerScience 6y agoChat bot. brian.bot The hard / complex part is (first) parsing parts of a Slack conversation to the do the AI part, and (second) the Slack interactive messages, which get weird when you try to use them as a form. a lot of just "if these messages happen in this order, this correct thing still happens", where the difference between different message types is, well, not minimal, but simple and straightforward. This has definitely led to waaay to much copy pasta, but it's well encapsulated within the test fixtures.
- thadk 6y agoI read this back in the day, added some tool which bugged me every 30 minutes and remember enjoying it. Not sure how I didn't carry it forward onto my subsequent computer, but have definitely pondered re-instituting over the years. Thanks for the re-share of the original justification!
- teddyh 6y agoSee also the Durr wristband, which vibrated every 5 minutes: https://www.wired.com/2014/01/a-vibrating-watch-that-messes-with-your-perception-of-time/ https://www.wired.com/2014/01/a-vibrating-watch-that-messes-... Discussed here: https://news.ycombinator.com/item?id=7007731 https://news.ycombinator.com/item?id=7007731
- viburnum 6y agoMaking little notes (instead of trying to keep it all in my head) has helped me tremendously. Simply writing stuff down helps clear away the fog.
- kuharich 6y agoPrior comments: http://news.ycombinator.com/item?id=1790365 http://news.ycombinator.com/item?id=1790365
- axguscbklp 6y ago>I think the style in which I practiced my craft for the first 15 years of my career was much the same as every other enthusiastic developer: you put a ton of hours in. 12-16+ hour days, evening and weekend coding marathons, pizza in the keyboard, crunch times, 3am debugging sessions where you just can’t go to bed because you can feel the source of that bug just beyond your fingertips, dammit, desperate last-minute sprints to deadlines where you manage to slot that last piece in, Jack Bauer-like, just before the world goes to hell. Uhh... does anyone other than maybe 1 in 100 developers actually do this? I think that many more than 1 in 100 developers are enthusiastic... but I doubt, whether they are enthusiastic or not, that significantly more than 1 in 100 developers or so act like the above. If I'm going to work 12-16+ hour days, I'd better either be in love with the company or have a good reason to expect that I could cash out and be rich as fuck at some point.
- wickerman 6y agoI agree... I've never ever seen anyone actually act like this. Even the most fanatical of my friends in university would never ever pull a 12h day by their own volition (mostly because they were all working full time jobs while still in college, so any free time you get is really really welcome). I also don't think it's productive or good for your product. As a side thing I paint, I've studied art and illustration since I was 14 and the one thing you learn as a pro in that industry is to never, ever finish a painting in one sitting. It's easy to obsess and lose yourself in the details and completely miss the glaring errors, and these you can find only by stepping away and coming back with a fresh set of eyes. And this is just as true for programming.
- yetihehe 6y ago> never, ever finish a painting in one sitting. I've found the same for designing circuit boards. When you are done, save it and look at it tomorrow, errors will be obvious.
- partyboat1586 6y agoWeird because I've seen loads of people act like this. It's very common among uni students studying almost any subject from my experience. I guess you associated with different people than I did. I don't think it's a good idea or healthy but it definitely happens, especially at universities and startups. I used to do it on client projects too until I wised up. Though looking back on my code from back then I still achieved some pretty crazy stuff in that time. Pushing the boundaries of what I was capable of. There is an upside to being completely immersed even though I wouldn't do it these days because I value my health.
- xyzal 6y agoOh my, I empathize a lot with the author. In january, long periods of sitting brought me a slip of the L5-S1 disc, and now I have to exercise every hour or so in the office for several minutes to be able to walk home with manageable amounts of pain at the end of the day. It takes a surprising amount of willpower to stick to the exercise schedule. Call of the zone is alluring. In case anyone here is in a similar situation and has any tips, please share ...
- redis_mlc 6y agoI'm knowledgeable about upper back/neck problems and stretches, and do them for 4 minutes daily. I'll prolly do a youtube video on it. Since you're a lower back case, I'd say learn all you can. Find a talented Palmer graduate. Research if leg raises are right for you, or sitting on a ball. Get and stay thin. If you're in the Bay Area, go to Walkrite Shoes and get expert orthopedic insoles to stabilize your hips: http://walkriteforlife.com/ http://walkriteforlife.com/
- Jtsummers 6y agoI was in an accident that resulted in the same L5-S1 area being injured, and spent several months recovering. Honestly, the thing that got me back on track was losing weight (I weighed around 220-230 at the time, and dropped to 180-190 and stayed there for several years). The pain periodically recurred, but nothing like the initial period. I took up walking, which turned into running (I played rec soccer, but that was the extent of my exercise prior to the accident). That may be out of reach depending on the extent of your issues (or other physical issues), but cycling, swimming, and rowing are great alternatives. I later took up BJJ, wrestling, and a conditioning course (meant to help with endurance in those other two). That did a ton to eliminate the pain. I learned what I couldn't do in BJJ and wrestling because of my back, but the gym I was at was great (a lot of 30+ participants, and a fair number over 40 and even 50) so I just partnered with people who understood my issues and we worked around it. The main thing for me, with getting into running, was that I did it 3 days a week and it was in the US south, so I was able to go out almost all year. There were a couple ponds I'd run by so it was a great way to get out of the work zone and clear my head. When I started having knee problems I'd take my bike to the same area and make three laps (15k) a few times a week (low traffic, only had one near-accident when an asshole passed me while I was about to make a left turn). I've moved, the weather was bad, and I didn't have access to a gym (and now I don't have access to a gym) so the weight started coming back and so did the back pain. I've got the bike fixed up now and the weather is better, so once I find some good routes here (I hate riding on roads with lots of traffic) I hope to shed this weight and get back on track.
- marcus_holmes 6y agoThe "power of breaks" really resonated. I, too, have learned that sitting at the computer is often the worst way of solving a coding problem. I go for walks, or a run if I'm in the mood. No music. Just my brain and fresh air. It's about 95% certain that I'll come up with a solution to the problem while walking. Often I have to turn around and head straight back to the desk to start working on the solution. But I try to resist this, as I often come up with clarifications to the solution if I continue walking. It's like my brain doesn't work properly unless my legs are moving.
- Animats 6y ago"Maintain context outside of your head at all times" Yes. I currently keep a text document, "NOTES.md", open for whatever project I'm working on. This isn't a bug list; it's just things that I'll need to come back to and deal with. If there's something that has to be dealt with, and it's not in comments in the code, it goes here. This is in the code directory and is checked in with Git, but it's just for my own use. Some excerpts for a large C++ program: Added logging to viewer. Turn off FSEnableLogThrottle debug switch when in use to catch all log messages. Logged a short road trip and a short boat trip. Huge Z velocity noise on road, low noise on water. 2020-03-24 Trying various forms of filtering. Current approach: - Low-pass filter linear velocity and angular velocity. - Difference with instantaneous velocity and angular velocity - Get magnitudes of differences. - Time limit for each is allowed error / magnitude of difference - Use lowest time limit to limit extrapolation time Simple analysis of the data indicates this might work Problems: - Filtering data with varying time deltas needs work. Test uses the assumption that updates come in at a rougly uniform rate. - Need to convert linear velocity to object coords before filtering so smooth turns work. 2020-03-31 Adding files to Firestorm: Add .cpp and .h files to appropriate sections of indra/newview/CMakeLists.txt New files go in indra/newview Then ? Run autobuild again? Script sh installnewfiles.sh copies the new files to the newview directory. Our version is maintained with git in the firestorm-mods repository 2020-04-02 Extrapolator is running. Results not too good: - Seems to be be overrunning extrapolation limit. Not sure. - Extrapolation limit is calculated before the last object updates have arrived. So last-second changes in the velocity are not caught. - Working. Good tuning values are filter, 10 secs, angle err, 20 degrees, position error, 0.25m.
- Kinrany 6y agoA similar interesting approach is to write notes in Git commit messages. The author of the Spiral language does it: https://github.com/mrakgr/The-Spiral-Language/commits/master https://github.com/mrakgr/The-Spiral-Language/commits/master
- letientai299 6y ago
- ojnabieoot 6y agoUnfortunately the real way to be an "interruptible programmer" is a) be self-employed, i.e. be your own boss b) have the kind of good work hygiene This advice is worthless for 95% of programmers contending with interruptions, which are urgent (or putatively urgent) things from the people who pay us and cannot be ignored.
- thrower123 6y agoMaybe we could just not interrupt programmers. The current demise of offices has done wonders for engineer productivity. One of the problems is that it really requires that people think a little harder and actually write things down, rather than just blundering through things in real-time.
- evanwise 6y agoI find that I can tolerate distractions like getting up to get a cup of coffee or stretch or do a few push-ups without much issue. I am able to maintain complex state and jump back into the flow. Maybe this is just a young brain thing and will go way, but in any case, this advice seems to be more tuned to those sorts of distractions. What happens in an office is entirely different. Your working memory is finite and social interactions are complex. Moreover, most people become personally offended (whether they will admit it or not) if you do not appear to be paying full attention. This was a particularly bad case but I once had a boss who would become visibly angry if you even stopped to write some notes when he showed up to interrupt you. Many of these interruptions are totally irrelevant too. Your boss does not need to stop by 4 times a day to get a detailed progress report. Your chatty coworker does not need to talk about his weekend at the lake. It's perfectly natural to feel some annoyance in a situation like this and it seems kind of absurd and subservient to me to ask devs to bend over backwards to accommodate the personality flaws of their bosses and coworkers. Sure, you shouldn't let this annoyance derail you, but that doesn't mean you also shouldn't tell your chatty coworker to shut up occasionally. Okay, maybe you shouldn't be so rude about it, but you need to set healthy boundaries and be allowed to block off time for the work you need to do. If you aren't, you are probably working for a shitty boss or organization. No amount of distraction management is going to help you there. Beyond that, I think that there is a limit to the complexity of problems that can be tackled without periods of extreme focus. Some problem domains are full of deep and irreducible complexity. It's probably true that we often mistake accidental complexity for irreducible complexity or fail to break down problems, but, and this may come off as arrogant, I find that it is generally people that have never had to deal with a problem domain with such irreducible complexities who think that we can solve all of our problems by breaking up work into smaller chunks. Sometimes you also have to deal with business requirements that effectively turn accidental complexity into irreducible complexity. Like, yes, technically things like regulatory compliance are accidental complexity but we also can't just simplify them away without facing serious repercussions. It's also much much easier to maintain context and state in problem domains you have worked in extensively for years, and you tend to be able to write more concise yet still complete descriptions of things within that problem domain. I suspect that has something to do with why the author only adopted this working approach later in life, in addition to the health problems he mentions. For instance, I find that I can pick up physics and math problems with minimal friction because I spent the better part of a decade studying those subjects intensely, but ask me to debug a SQL script (an area where I have minimal domain knowledge) and I will need probably 30 minutes before I can even think a useful thought about it. Most devs do not have the luxury of only working on problems they are domain experts on. Business requirements and capacity are fluid things.
- swah 6y agoI have been trying http://roamresearch.com/ http://roamresearch.com/ (or Dynalist) to keep a daily log of my findings, projects and (some) tasks.. - its going quite well.
- nkingsy 6y agoDay to day work at at $largetechco requires such an enormous amount of context that even a simple task can cause my working memory to overflow, triggering my “this must be fixed, too complex” instinct, and paralyzing my ability to work for long stretches of time. I find that I have to make a practice of ignoring my refactor instincts, because there usually just isn’t anything I can do. Externalized context definitely helps, but 1 year in, I’m finding my brain has not adapted to this reality. I use playgrounds and design documents to do most of my thinking because I simply cannot reason about the real application without my head exploding. This has improved my thinking tremendously, as I was never someone capable of outlining thoughts before coding them. I still can’t do that, but when I encounter a challenge, I can draw up the simplest possible version of it in a playground, write a document about it, discuss with stakeholders, formulate a plan, then return to the real code where I can put my full focus on managing the background complexity, having already worked out the feature complexity elsewhere.
- overgard 6y agoI honestly don't know if this is because I'm dumb or I'm smart, or maybe the work context I developed in, but personally interruptions don't really screw up my flow much. The only time it really causes me to lose focus is if the interruption has a high emotional reaction. I don't like interrupting others but at some point I wonder if some just don't do anything if they're not in "flow". I think it's important to be able to make progress when you're not in a flow state. Its a skill.