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 wait that long, so I'll alt-tab and look at HN or whatever for "5-10secs". Problem is I find an interesting article and then come back 5minutes later.
So, I know it's not the best solution, but I keep compiling/loading time REALLY fast. I.e. hot reloading is a good example of small thing that boost productivity insanely. But even in C++, I'd just work on a separate project and stub everything so that it compiles in a few ms. I know that if I need to recompile the whole codebase everytime I'm making a change I won't get any work done.
It's also because I tend to do the code/test really fast. I know some people who code for a few minutes, then test it.. so it's less of a problem for them.
Anyway, back to my hacking.. see, that sucker took more than 5 seconds to run :-)
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.
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.
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.
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
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.
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!
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!
> 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.
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-... ), 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.
There's a writing tip that you don't quit until you know what the first sentence you're going to write the next day is.
I haven't tried this for coding, but the equivalent would be not to start running a test until you know what the next function/method/commit you're going to make is. Even if you have to screw around looking for potential problems in your code, or potential places to refactor, don't run the tests until you know what that next thing is going to be.
Here's the actual Hemingway quote:
The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.
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 ;-)
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.
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.
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.
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.
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...
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.
One day I’d had enough. Truth be told, I’d had way more than enough. I stopped and reevaluated my life, trying to figure out what was important to me, and what wasn’t.
This self-reflection and whatever series of events led to it are more valuable than any particular time management technique. I'm surprised the author did not discuss this in more depth, though I suspect this is because these realizations tend to arise largely by happenstance.
When we notice ourselves failing to direct our energy toward matters of immediate concern, this is a fine occasion to evaluate what we are doing and why. If it is procrastination, perhaps this is a result of fearing failure, or perfectionism, or low energy. Perhaps we are distracted by a thought with which we have too closely identified ourselves, thus failing to notice that we are even thinking. There are many competing forces at play in the mind, and we are seldom if ever aware of all of them at once. I think that generally the cause of low productivity is, as someone once put it, "a failure to think about thinking." Perhaps the boon of these techniques is that they direct our attention to the content of our minds by creating a sense of urgency.
I really like that the author describes work as fitting into two categories: the really focused stuff he uses the Pomodoro technique for, and all the peripheral stuff. I think it's a very important distinction and I'm keenly aware of it in my daily work.
I've found there are two advantages of Pomodoro that are under-appreciated:
1. At the end of your day you have an integer number of "Pomodoros" done. An integer number is very easy to grasp and compare with other days. So you have a very strong sense for how well you did with your day, or how well you are doing so far in the day. It's a powerful thing and it keeps you honest.
2. After you have used the technique for a while, the timer you use not only serves as a timer, but its start mechanism/button/gesture/whatever actually serves as some sort of psychological "switch" that puts your mind in work mode. On mornings when I am lacking a little motivation, I can just start the timer and I'll get into gear. It's not magic, but when I need a little extra kick the timer does it very well.
3. You get great at estimating work in 25-minute chunks. Being able to exert that level of control is cool.
4. It directly taps into several other productivity systems like the X Method.
5. Sometimes when you have just 30 seconds left on your Pomodoro you start blasting away on your keyboard like you're one of those hackers in the movies. It makes you realize how much you can do in 30 seconds.
I've actually started to do 5 minute pomodoros. It's insane, but also a lot of fun. Especially when pair programming it's great because you can start discussing an issue and suddenly you look at your timer and think, "Woah... 30 seconds just went by. Let's just try it one way. We can change it later if we want". I also write down what I've done at the end of the 5 minute pomodoro. If it is "nothing", then it's a good flag to say that I have a problem.
While I respect the Pomodoro technique, I found that its focus on 25-minute chunks is largely incompatible with the way I (and many others) program. When it takes 10-15 minutes to load everything up in your brain, that only leaves you a few minutes to actually work before you take a break.
Then start your next pomodoro immediately. That's what I do. If you can do that and not get burned out, that's ideal, especially if you're in the zone. It's also better than increasing your pomodoro time IMO. Since I don't take a break 2-3 sessions at a time sometimes, looking at 10 minutes to go is spurring; when I experimented with 40-minute sessions I hated looking at 35 minutes left on the clock.
I do a variation of this. Ten minute timers, instead of 25, and then I make sure that whatever task I set for myself is something I can do in 10 minutes. For programming tasks this is often "Finish writing method foo", or "Debug the problem with method bar".
For coding I find that 45m work with 15m breaks (and a 30m long break) work better as you have enough time to get into a problem, and just enough of a break after to send some emails / browse HN, etc.
The overall work ratio is lower (75% vs ~83%)
but it's hard to put an qualitative efficiency metric when programming anyway so I'm not so worried.
This ratio also worked super well when writing my dissertation - the 5m break never felt like enough of a reward after.
(there is also a great Pomodoro extension for Gnome if you're running Linux).
I don't think the 25 minutes matter that much. I always did 30 minutes, and then if I feel like I wanted more time, I would ignore the alarm.
The principle is to give you a small amount of time you have to focus. Then once you did that, everything else seems easier.
Pomodoro is not really a time management technique, rather a motivation/anti-procrastination technique. But OP is trying to sell his product so... buzzwords.
When I temporarily went into teaching (5 years... lol) after a career of programming, I still wanted to write software every day. The only problem was that I only had small pieces of time -- usually 20-30 minutes here or there. It was a kind of enforced pomodoro. Of course, I suffered exactly the same problem that you do, but even worse because it would be hours before I could pick up the code again.
My solution was to try to swap out that context to disk :-) I'm back in software again and I've refined my techniques a bit. It's helpful for me because as I get older, I can hold less context in my brain than I used to be able to do anyway. There are 2 main places I store context: tests and TODOs.
I'll start with TODOs. I actually use Emacs org mode for TODOs. The best part about Org mode is that it is in a text editor. That means that I interact with it the same way that I interact with any other tool. It is also hierarchical, which means that I can embed TODOs within TODOs. Finally, it is folding, which means that I can ignore large sections of the TODO list, or move sections around with just a few keystrokes.
Basically, as I'm programming, whenever I have the thought, "Oh, I have to do this", it goes in the TODO (even if I'm just about to do it). You have to be terse because you don't want it to take more than 1 or 2 seconds to jot down. But terse is OK. I actually have 2 editors open -- one that I'm programming in and one with Org mode. I switch between windows in tmux. This is the fastest way for me, but if you use Emacs normally, then Org Capture might be faster.
Every time I finish something, I go back to org mode, mark it DONE and then reorder my TODO list. It only takes about 10 seconds to reorder the TODO list and it's useful time for me to think about what I'm doing.
The easier bit for keeping context is tests. As I'm getting near the end of the pomodoro, I make sure that I have a failing test. If everything is passing at the moment, I quickly write a failing test.
When I return from the pomodoro, the first thing I do is run the tests. This shows the failing test. At that point, I only concern myself with fixing that test. If you are used to doing TDD, then it usually only takes 30 seconds or a minute to fix the failing test. This is like a bit of a boot loader to get you back into the problem. After the test is finished, I go to the TODO and reorder them. Often it doesn't have to be reordered, but the act of thinking about priorities restores the context for me.
Currently, I'm doing some experiments where I am recording myself doing a large kata where I do one pomodoro per day (the ultimate in context killing). I don't have any conclusions yet, but the techniques I describe above seem to be working well.
I'm using Asciinema to record myself and it elides portions where you are idle for a certain number of seconds (I have it set to 2 seconds). In other words it removed bits where you are doing nothing for more than 2 seconds. By comparing the actual time spend to the length of the recording, I can see how long I was idle. At the moment, it seems to be averaging about 5 minutes for every 25 minute pomodoro. That doesn't seem to be excessive to me (since I am reading documentation and thinking occasionally).
Why do all of these read like every internet scam ever? When all you do is hype and tease a specific piece of information (what is the pelko method?), only revealing it at the last second, all you do is insult the reader. Why link an entire article when quoting the last sentence would have sufficed?
How much do you sleep per night and how much caffeine do you drink?
I used to nap like that too, until I reduced my caffeine (one cup of coffee in the morning now) and started consistently getting 8-10 hours of sleep per night. I'm much happier and more productive than I ever was when I felt like I was constantly battling exhaustion with afternoon naps and coffees.
Now that I am self employed as well, I try to, but it just makes me want to sleep the whole afternoon. It's either sleep deprivation, or Italian genes :)
That's clever. I've seen websites meant to force you to write an essay that have a text box and if you aren't typing then it will start making increasingly loud and obnoxious noises.
Interesting! I never heard of that. The blogpost reads like a joke so I don't know if he's serious about it, but if he is I would like to read about people's experience on this technique compared to the Pomodoro one.
It's a joke, doublestealth is a start-up satire blog, the subhead "The blog of (probably fictional) Brad Bradstone the CEO of (possibly non-existent) Yellow Yellow. Remember, this is a parody." sort of gives it away if you aren't familiar with it.
The last paragraph pretty much sums up the entire article:
Click here to get access to my free 32-page guide that explains my simple system in detail and includes worksheets, tools, and resources that you can print out and use. Save 23.3 hours each week and get more accomplished!
Yes, that bit of self-promotion and the hyperbolic claim negated his credibility. Then again, HN readers must already be familiar with the ways of 'fastcompany' writers given the sheer number of articles we see from them.
The basic 5 step technique is useful with teenagers at revision time. Light weight, easy to remember, they seem to like the kitchen timers (I use 'pound shop' clockwork ones except you can't get them in pound shops any more).
Right now, you’re probably thinking, "Twenty-five minutes of work? That’s nothing! This is gonna be easy!"
Actually as someone who mostly formed my study/focus skills during the age of distraction (Facebook, SMS, YouTube), I don't think this is trivial at all.
If I were to go all in on the Pomodoro Technique, I'm pretty sure have to start training myself from just 10 minute undistracted work sessions.
I find the 25 mins difficult at times too; partially because of distractions, and partially because I let myself be distracted by them.
If I can't do a full one, I cut the next one down by 5-10 mins and try the shorter time period. If I CAN get that one done, I add 5 mins. Repeat until I'm down to 5 minute tasks or 25 min pomo's.
Trello + Pomello is a quite powerful combo. Not only I use it for focusing, but also tracking time that I spend on freelancing (down to specific Trello tickets).
I tried the Pomodoro Technique to avoid distractions and to stay more focused when I started freelancing. I was also trying to track my work time, so I built Tomatoes, a simple web app to do both.
I've always wondered, what's the point of those "FREE EBOOKS!" that require you to give your email? Does the author get a cut because s/he sells your email to advertisers? I always use a disposable email anyway.
I was turned off by the ebook offer as well, but I went ahead and downloaded it anyway. Even though it says 32 pages, it's incredibly short because the pages are small, the font is large, and there are lots of illustrations. It took me longer to read the article than the ebook.
Here's a Chrome extension that is useful for enforcing the Pomodoro technique. It allows you to blacklist websites and customize the work/break lengths.
Thanks, but no way to stop a timer except removing the extension, by design? O-kay. That may have been the shortest-lived extension I've added and removed.
Out of curiousity, why do you want to stop the timer? To me the point seems to commit to lay out a specific segment of time to be productive and holding to the commitment helps. I imagine you have a different perspective on this though.
Because I installed it and clicked on the new browser icon to see what it did, and it said I couldn't browse the web for the next half hour of my evening unless I uninstalled it. I understand some barrier to change of mind in a self-discipline app, but forcing me to uninstall (which the user is perfectly capable of with a different couple of clicks) does not make me want to install it yet again, because the app annoyed me on purpose the first time I did.
In pomodoro if you get interrupted to the point where you need to stop what you are working on you are supposed to stop the timer and start over when you can.
It forces you to make sure interruptions are actually worth dealing with vs putting them off till after the timer is up.
Good point, but by itself restarting the timer isn't much of a deterrent (at least to me). It makes me wonder if a better incentive might exist so that you can pause the timer but with a weightier tradeoff.
I'm not the developer, and I haven't used the extension in awhile, but I think there was a way to stop the timer somehow (possibly by closing the browser and reopening).
I don't know if there was an undocumented way, but the extension explicitly stated you had to uninstall it to stop the timer or to change any settings.
Walk around. If you have a floor that lets you slide around while socked, do a few hallway sprint-slides to get your circulation going.
Or my favourite: 60-second plank to start every break. Pomodoro six-pack plugin.
I love the Pomodoro Technique, and use the Tomighty app specificaly for it's simplicity and that it's native so I don't need to keep a pinned browser tab open just for it - love simple things like this that just sit in my system-tray.
I pair it up with Toggl, a time tracking service online to keep reports of what I'm working on, and I find it a huge boon to my productivity and ability to justify the time I spend working on things.
I used a different version in college for weekend studying. Study for 2 hrs, break 10 min. Study 1.5 hrs, break 20 min. Study 45-60 min, by then it's usually lunch time or dinner.
You know, someone has to say it. Working in 25 minute intervals with a 5 minute break is hardly a technique. It doesn't need a name, and it doesn't need an entire page to explain. A to-the-point definition followed by anecdotal commentary would have been far less insulting than the format of this blog post, which basically reads like a diet pill ad.
Pomodoro saved my butt in college one time, when simply "working hard with breaks" wouldn't have. I had to read a 200 page monograph in a single night and then write a book report on it.
With Pomodoro, I assigned each chapter one "pomodoro" (25-minute time period). At the end of that time, the chapter was done, whether I'd finished it or not. As the timer ticked down, I'd see it out of the corner of my eye and read faster, eventually just skimming the first sentence of each paragraph and maybe soaking in one or two details every couple paragraphs. When each chapter was done, I'd have a rough idea of what the main thrust was, and a fistful of details as well. I'm pretty sure I got a B+ on that book report, but I was just amazed I got it in on time at all.
So in this case, I found it useful as a way to complete a large, boring, segmented task in a quick-and-dirty-but-effective way. I wouldn't recommned it as a cure-all, but it's a good tool to have in your belt for certain kinds of tasks.
I'm doing that this semester with a Tabata timer app - I'd seen my wife workout with one and thought it would be good for textbook skimming. I have the timer ding every 60 seconds, and at that point I'm on the next page (unless I make an exception, which I do at times). It gives me a 10-second break between every page, which I use to finish a sentence, or just redirect my gaze in a new direction. With that kind of intensity you can only do so many pages at a time, so I typically set it to 15 "reps" of this before I take a break.
I find it baffling that you had to do this in the absolute last minute? At best it shows poor planning? At worst a 'I-am-heroic-startup-1-person-army' which burns out so many poor souls. Pardon me if this is incorrect.
That kind of hypothetical analysis is irrelevant in the moment though (similar to sunk costs). Regardless of how you end up finding yourself in a situation where you need to complete a herculean task in a single day, you still need to do it. It doesn't help to place blame at that moment, though of course you should do a post-mortem afterwards and figure out what you can do in the future to prevent it from recurring.
I too ended up in a similar situation in university where I needed to complete a large programming project in a single night, and I did it. Now granted, that was a fault of bad time management on my part, but using disciplined programming I was at least able to recover from it and complete the project. And I have had a few instances in the business world that had similar tight and tough deadlines that were NOT a result of time management failure on my part.
Creating deadlines for work is not revolutionary, original, or insightful even if you give it a cute name. I used to use 45 minute intervals when I used to procrastinate projects. These intervals would be split up into 15|15|15 minute goals and then again into 5|5|5 when necessary. I'm not gonna call myself a genius, give it a cool name, or write a blog post about it because organizing one's time in such a simplistic manner is just not a big deal.
If someone says Pomodoro technique, then I know what they're talking about after two words (one if they're not Italian). It's effective for people discussing it and similar practices. It gives people something concise to search for if they're looking for an app supporting the technique. It benefits people who didn't think to try it themselves (99% of the population).
If there's a problem with blog posts like this one (and especially so for ebooks) it's that they'll feel a need to justify a cost/article by rambling at length when 5-10 bullet points would suffice. Maybe that's what you're unhappy about.
But the problem is not with discussing or coining a name for a method. Countless 'cutely named' methods have been successful in part because of their names, e.g. Crossfit, 7 Minute Workout, 4 Hour Work Week, Five and Two Diet, Paleo Diet, etc.
So, I know it's not the best solution, but I keep compiling/loading time REALLY fast. I.e. hot reloading is a good example of small thing that boost productivity insanely. But even in C++, I'd just work on a separate project and stub everything so that it compiles in a few ms. I know that if I need to recompile the whole codebase everytime I'm making a change I won't get any work done.
It's also because I tend to do the code/test really fast. I know some people who code for a few minutes, then test it.. so it's less of a problem for them.
Anyway, back to my hacking.. see, that sucker took more than 5 seconds to run :-)