6 ms·

Personally, what kills my productivity is when it takes more than 5secs to compile/load/whatever. I don't have ADHD in real life, but when I'm hacking, I can't

• DrScump 11y ago
  what kills my productivity is when it takes more than 5secs to compile/load/whatever. Sigh. These kids today have no idea what it was like to dial in to work at midnight so you could fire off another build that could finish by morning, if you were lucky. Or, to be limited to off-hours for running builds at all.
  • artifaxx 11y ago
    The two are not totally incompatible. If you can decouple segments of huge projects, you can mock input and get quick feedback on the specific segment you are developing. Insanely long builds still exist today, I know of and have worked on software that ranges from 1 hr to 1 day to build quite recently...you just have to find ways to avoid that huge cost :p
  • jernfrost 11y ago
    Yeah but you didn't have internet to waste your time back then. I fucking hate internet at times. It has conditioned me to read everything in little digestible tidbits. Before I spent much more time reading actual books, staying concentrated on reading one topic for you know at least 1 hour at a time.
    • DrScump 11y ago
      Sure we did. I was very active in several Usenet newsgroups from 1987 on. Of course, at that time, few companies were connected 24x7. My employer, for example, dialed in for mail and Usenet traffic exchanges a handful of times a day. The debates over the first ANSI C spec in comp.lang.c were most entertaining.
  • duggan 11y ago
    Some of us have an idea, if only because a full build and integration test cycle for clusters of virtual machines can take hours depending on how the pipeline is organized!
  • InclinedPlane 11y ago
    Pffft. They have no idea what it's like to work on really big software projects.
  • JoachimS 11y ago
    You lucky bastard! I remember the joy when we got Cadence BuildGates to start running parallel synthesis and optimization runs. This allowed us to go from one build per week to two. If we were lucky!
  • PeterisP 11y ago
    You still get that in machine learning projects - you make some change, launch the re-training of the models and see the result next day, or in an hour, or in a week; and only then you know if the change was actually beneficial.
• creullin 11y ago
  Yep, same boat here. Even in Web dev if the page takes too long to load, or an API call is slow...off to HN
• m_fayer 11y ago
  Same here, one thing that sometimes works for me is making sure I have no browsers open at all. Then the inevitable speedbump of opening a browser and waiting for my machine to recover from the 50 tabs all suddenly coming to life keeps me from doing it, and instead I stare into space and think deep thoughts for 10 seconds. It sure is hard to close that browser once it's all warmed up and full of interesting things though...
• burkemw3 11y ago
  This used to be a bigger timesuck for me because I didn't always have a good interrupt to tell me that whatever process (e.g. compile) had finished. I've since added a bash alias that helps: `alias beep="echo -e '\a'"` `burkemw3@laptop$ compile ; beep` makes sure I don't have that excuse anymore.
  • cpeterso 11y ago
    On OS X, you can use `say` to shout at you when your build is finished. :)
  • m_mueller 11y ago
    On OSX you can also let the terminal bounce until you open it again in foreground. Edit: need to use `printf '\a'` for that
    • JoachimS 11y ago
      Those bounces by iTunes for example are soo annoying and distracting. Is there any way to kill them system wide?
      • m_mueller 11y ago
        It annoys me too, but in case of the terminal bouncing this is deliberate so I get back to work ;-). To disable it: `defaults write com.apple.dock no-bouncing -bool TRUE && killall Dock`
    • mkopinsky 11y ago
      I have alias foo='bar;tput bel' in my .bash_profile which does the same thing.
  • marvelous 11y ago
    With gnome-terminal, I get a notification when a command finishes in a terminal that isn't on the foreground. It's very useful.
• dugmartin 11y ago
  My solution has been to block all my "time suck" sites in my host file and then only browse them on my phone. If I pick up my phone during some 10-20 second pause I'm more likely to put it down than if I just open a new tab and start browsing.
• trevor-e 11y ago
  It takes my Android project 2+ minutes to compile each time. I'm going insane. Since we've been burned a few times already, we made the decision as a team to always compile with Proguard turned on. Trying to find some middle ground right now.
  • jklp 11y ago
    Why not disable proguard on dev and then let CI compile with proguard on?
• db48x 11y ago
  I agree 100%; compile times must be fast or I get distracted. Right now I'm waiting for tests to run which takes ages and ages; it's the same problem. I've found that I'm extra productive in lisp because I'm evaluating and compiling a single function at a time, usually. I can cycle between testing that one function and fixing/finishing it very rapidly since it never has to build or reload the whole thing. A lot of the time it doesn't even require leaving the editor. Too bad I've so far only been able to use lisp on personal projects. 3/61 tests passed...
• intrasight 11y ago
  What I don't understand is why, with Moore's Law and all, my builds take just as long today as they did 20 years ago.
• saurik 11y ago
  > I don't have ADHD in real life, but when I'm hacking, I can't wait that long, so I'll alt-tab and look at HN or whatever for "5-10secs" You have created a problem for yourself that should not exist: do not task switch to Hacker News, task switch back to your text editor to re-read the code you just added or to work on the next part of the problem; or you could be working on two parts of the project at once and keep rapidly flipping back and forth between them. Your issue is not that you don't have the patience to wait for five seconds: it is that during those five seconds you are doing something useless instead of something else important. In all seriousness, once you stop thinking of "patience" as "I need to be able to sit on my hands and wait" and instead think of it as "I now have the opportunity to do something else for the next period of time that I should try to make as productive as I can", I don't think ADHD is the problem anymore: the issue is making sure you always have a fun productive side task. You might find yourself accidentally doing things you realize later had low value for the time, but at least you got something done, right? Put another way, you should embrace ADHD, not fight it: once you get into the habit of distracting yourself with just another task, the 5-10 seconds of compile time no longer matters, as you routinely switch to another task for five minutes every time you compile and it doesn't matter how long the compile took. You can do this with everything: I deal with delays in my web page e-mail client by having two or more clients open at the same time where I am working on two different search and reply tasks.
  • Trill-I-Am 11y ago
    I don't think this method can work for me because I hate cognitively switching from one task to another.
    • CydeWeys 11y ago
      Even if the tasks are related, in that they both involve writing code in the same project? I find that I can handle that pretty well, and I'm distracted a lot less by coding on two different parts of a project simultaneously than by trying to simultaneously do coding and also doing a task of a different type, like reading/writing documentation or email. If you think about it, some really complicated coding sessions require keeping the state of many pieces of the program in your mind simultaneously (see, e.g., this: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-... ), including code in many different files. This is actually more difficult cognitively than simply working on two separate simple and well-contained coding tasks simultaneously.
• mikekchar 11y ago
  I wish I had a reference for you, but I recall reading some UI guidelines that discussed how long you have before you need to give feedback to your users. IIRC 2 seconds was the longest amount of time that didn't feel like you were waiting forever. Once you got past 6 seconds, basically people think it is broken. I have the same experience as you do, and these numbers of 2 seconds and 6 seconds really seem about right. If the test runs in less than 2 seconds, I can stay focussed on what I'm doing. By 6 seconds, I'm already thinking about something else. My personal experience has been that if the tests takes longer than 2 seconds, it is virtually impossible to do TDD. Instead you have to write large chunks of code -- or at the very least write several tests in one go. I'm fairly well known in my current group for the 2 second rule :-) 2 seconds is really a long time for a modern computer, so my feeling is that if you can't build and run a large section of tests in 2 seconds, you've got a serious problem somewhere. When pairing with people who don't mind longer test runs, I've noticed that they never actually TDD. Instead they right large pieces of code (entire functions at the very least), or they write 5-10 tests all in one go. When I show people the normal rhythm of TDD, they suddenly understand why you need to have incredibly fast tests. I also preach a 2 minute limit for the entire test suite. Kent Beck has talked about that previously (although I can't remember what number he used -- something like 2-4 minutes). He has even advocated simply throwing away long tests. Test coverage is less important than being able to run your tests quickly. I have found that if the test suite creeps up to about 10 minutes, the frequency of running that test suite is reduced to about once per day -- meaning that you have totally lost the context of the problem when you discover it. Whatever you need to do to keep those tests running quickly is what you should do. Whether that means only running a subset, hot loading modules, stubbing out slow moving pieces (even the database), etc. I could write for quite a long time on testing strategy... This needs to go on my queue for a blog post ;-)
  • CydeWeys 11y ago
    Cloud development and testing help a lot too. I can kick off a run of the entire test suite in the cloud, and get right back to coding, all while keeping tabs on the tests' output in a tmux terminal. I'm typically editing in parallel with tests running. This can frequently result in no down time whatsoever owing to tests, even during a large refactor. Let's say I make a big refactor and 90 different test classes break (this is not theoretical). I modify some code that might make one of those test classes past, kick of a test run, and immediately go edit another failing test class. By the time I think I've got that figured out, the test run on the first has completed, and I can either move on, or try something else to fix it if it's failed again. This requires keeping the state of multiple test classes in your head simultaneously, but fortunately I'm good at that.
• larrywright 11y ago
  This became a bad habit for me too, and there are limits to how fast I can make things. My solution was to install an app (Focusapp in my case) that blocks distracting websites. And I mean blocks them hard - reboot won't stop it. And it's on a schedule, so it blocks from 7am-5pm, every day. It sounds a little heavy handed, but it made a huge difference.