The first part of the book has a really good description of the "modern" work environment and its defects, and how it valorizes superficial work over deep work. I was actually surprised by how identical this description was to my last work environment.
- Open space to promote communication and knowledge sharing (and controlling what people are doing), but at the end you are interrupted every 5 minutes by people walking and talking/screaming/laughing about anything but work.
- People expect you to have Gmail and Slack open all day and to reply in the 5 minutes.
- You are encouraged to go on Facebook/Twitter/Youtube/whatever to like and share the latest news/video/open position/whatever posted by the company. Then you start reading/watching something else that looks interesting and you lose easily 30 min / 1 hour.
- At the end, what matter is how many hours you spend in the office. Nobody cares if you spend a full week on a task because you can't never focus on what you do.
>People expect you to have Gmail and Slack open all day and to reply in the 5 minutes.
When I was looking for my last job, I explicitly queried about this:
"Will it be OK if I check my email only 3 times a day (at work)?"
In my previous job, too much work was done through email. Person wants me to do some work and return a plot. I send it to him. Within 5-30 minutes, he has a question about it. I have to respond soon. And it goes on and on - with each email interrupting whatever work I'm doing.
So I don't have "meetings through email" any more. They want to ask me stuff? Let's get in a room and at a fixed time and work through them.
"I keep my messenger app permanently off. Is that a problem?"
>but at the end you are interrupted every 5 minutes by people walking and talking/screaming/laughing about anything.
For me, this is a non-issue, and much preferred to emails and IM's. Especially IM. Also, phone calls are OK too. Why?
With IM, they start a conversation and then suddenly disappear, only to reappear 15 minutes later when I think the issue is closed and have started to work on something. No one does that in person (well, almost no one).
When they come to me in person or call me on the phone, they cannot just browse the Internet while talking. They are mindful of my time. And somehow, I feel they prepare their questions better, too.
What is it about the email that makes you think you have to respond soon? Is it the culture at the company around email?
I work at a non-technology Fortune 500 in the IT dept. (I work remote, too) and the general expectation is that we check our email 2-4 times a day. Occasionally I go a day going through my inbox once all day, and it has never been a problem.
Often when there is a response expectation, I'll explicitly say so in the subject, so that if you're scanning your E-mails it will stick out. Will also specify my default assumption should you not respond. I like to be super clear. Company culture is the product of the people who participate in company culture.
SUBJ: [Reply needed by 5PM] Deadline for project approval approaching
(somewhere in body): Blah, blah, blah. If I do not hear back, I will assume we will go forward with the project.
I think the part that is missing in your comment is the company expectation on how often people should check their emails. This is why in my interview I specified something like "Morning, after lunch, and before I head home".
If getting an email like yours, sent at 2pm where a reply is needed by 5pm, then the answer to my question should be "No, checking your email at that interval is not OK".
I'm not going to say your expectation is objectively bad or anything. Some businesses may need to work at a fast pace. Just that I would not want to work there if this is the norm. Frankly, in the places I've worked, I didn't see why it had to be through email vs coming to my office or calling me.
This. Especially the IM thing. Even if it is something unimportant, any ongoing conversation leaves this "ping" on my head, disabling my ability to focus.
With remote work, there can be a constant slew of inquiries on Slack, esp. if you're a senior team member. Trivial things take 5-10 minutes to work out on Slack because of how inefficient typing is versus being in the same room.
I guess the ideal situation is to work on something that requires little collaboration, but such positions are very rare.
EDIT: They're even more rare that they could be. In cases where a component could be reasonably written and maintained by a single person, managers will still usually impose a requirement of having at least two or three people involved with that code, which creates large and completely unnecessary communication overhead. The reason is of course they don't want to be dependent on this specific programmer, because then they would have to pay market or above market wage and generally create a developer-friendly environment. They think that it's easier and cheaper to treat developers as replaceable cogs, even if it means they have to subject them to excessive knowledge transfer, thus making them less productive.
What is wrong with a phone call (preferably scheduled) to work out such details? It seems to work pretty well for me with my remote job. I prefer more complex solutions to be worked out via a wiki-like editable document that everyone can share and discuss, but for trivial things, a phone call works well.
You are right that many more things could be done without so much collaboration with better practices. I think code reviews can help maintain a sufficient spread of knowledge across the team.
Being able to call somebody and do screensharing helps a lot in this aspect. It isn't the same as sitting together in front of the same computer but way better than solving technical or conceptual issues through text messages.
- The "Emergent Task Planner" is my daily piece of paper that I physically write out what I want to accomplish. At the end of the day I know what I've done and haven't done. (http://davidseah.com/node/the-emergent-task-planner/)
- I break my sessions of work into 2 or 4 hour blocks, and shut off all the distractions.
- If I'm really having a garbage day for productivity, I find stuff to do off my OmniFocus List that involves physical activity (cleaning the house, fixing things, going for a walk). I work from home now, but when I used to have an office cubicle I would just walk around the building.
Hard work is hard, but I wonder if it truly requires an anti-social approach.
The nice thing if you are working in isolation is that everyone involved in your work environment is probably aligned towards a goal. Or at least we hope you yourself are aligned – and yet even that is hard to manage, as we all know from our own ability to distract ourselves.
An open office, messaging, all those distractions aren't just distractions, they are external influences that aren't designed to help you get YOUR work done. Someone else has a question to help them get THEIR work done. Someone else is monitoring your productivity to help them alleviate their own anxiousness.
I'm not a big fan of pair programming, but I do like how it can lead to better focus. It's like you are focus accountability partners. I also like ad hoc meetings setup for a specific purpose, if the purpose really is important for the participants I think it's productive. And if the problem is really important, I like a meeting where we talk things through and then get quiet for a long time. We don't give up. We don't defer the problem, leave and go our separate ways. Part of doing hard work, in my experience, is loading up the tensions, piling up everything that makes it hard, and then finding the way out. It's not always easiest to do that alone.
As the poster child for this stuff from a few years back, I've lit on the simple intent on being present for a small amount of time each day. There are hundreds of ways to meditate - find one that works well for you and practice it. Work toward sitting and observing without judgement. Work toward quieting the conversations in your head.
I would also recommend not over thinking about any of this too much. Thinking about thinking has the same lowered efficiency as being distracted by gadgets/media.
If you want to get deep on this subject, I highly recommend "The Organized Mind" and "The Power of Habit".
The Organized Mind really breaks down the cost of "task switching" and explores the brain's strengths, quirks, and weaknesses, and how strategies of highly effective people exploit those traits.
The Power of Habit is good for developing a less naive approach to behavior change. It's eye opening.
i've never seen anyone actually use a pomodoro in real life, and the occasional day i've given it s a shot, I end up thinking "this is silly, I'll just focus on my work".
I guess my protest is that it seems silly, especially when I'm focused on something and the timer goes off and I'm supposed to stop. It seems like its adding structure only for the sake of structure. Has anyone actually started using pomo, and stuck with it, and seen positive results?
I've had positive results with pomodoro. I honestly think it's more likely to be useful for people who are worse off than you are and can't focus or manage time. If you can sit and focus on your work without help, you don't need it.
The pomodoro technique makes work easy to start because it's a promise to yourself that it will only be for a limited amount of time. If you break that promise to yourself by not stopping, you've lost the entire point.
I've been using Pomodoro for about 5 years now and it has been a major life changer. I don't use it at work, I use it to manage finite time pre or post for my side projects and outside learning.
Here is a writeup on my system.
http://juvoni.com/pomodoro-time-forecasting
I've developed razor sharp focus over the years, and pomodoros are like my focus shock absorbers for med/low energy periods or times when I'm most likely to be distracted.
For me the Pomodoro technique is about starting, not finishing. I normally devise ways to procrastinate but PT allows me to fool myself into starting by committing a small period of time.
I use it, although I admit not religiously. Writing down my tasks I need to get done, then 'estimating' them in 25 minute chunks really helps me get my brain around the concept of time, just how little of it I have in a workday, and just how fast it passes, which is the real issue for me.
Also, there's nothing wrong with doing 2 or 3 in a row, if you feel like it.
I imagine there's a lot of value in "I won't change from this task until the timer beeps, no matter what happens" and no value at all (or a lot of negative value) in "I will change from this task as soon as the timer beeps".
Pomodoro may be something worth adjusting. I do have to try it someday...
One value of the latter is, "I will stop for a five-minute break before the next work interval -- just to stand up and stretch and breathe." It may seem like an unwanted interruption if you are "flowing," but it can enable much longer periods of sustained work.
When I'm in a procrastinating streak -- that kind of low-grade depression that makes you dependent on having some measure of fun at all times -- I will set an e.ggtimer.com for, say, 20 minutes so I can get some work done in a day.
I usually get carried away and ignore the timer's end.
The idea is to evaluate how you're doing every 25 minutes and take a break every 50. You're "allowed" to work as much as you want; if you don't have an issue over or under working, there's not much point to the timer.
For me it's a tool of last resort. For 95% of my day-to-day work, I neither use nor need pomodoro's kick in the butt. But a few times per year these dreaded tasks come up that I just cannot get myself to do in a reasonable timeframe, and in those situations pomodoro sometimes helps, just to get going.
>Extending the length of the 25 minute pomodoro. If I’m in the deep work flow, I’ll continue past the 25 minute alarm.
Someone told me that its 25 minutes because it prevents you from building too much context in your head that prevents you from taking a break at 25 min mark. You can't do creative work if your brain is filled with lot of context. eg: TDD goes really well with pomodoro because you are only thinking about the next test and you can break on failing test so you can pick up right back. Is this a reason for 25 min for Pomodoro?
I'll be honest; I've never understood this mindset. The idea of purposefully interrupting my flow every 25 minutes, explicitly dropping my context is ghastly. If you could design an ideal hell for me it would involve hard, interesting programming problems and constant (every ~10-20 minute) seemingly random external interruptions. (Its not an accident that I don't have children.)
Most of the work I'm really proud of happens in 1-1.5 week long coding binges, during which I code ~14 hours a day, don't eat well and don't get outside much. During that time my entire being is oriented around the problem. I sleep when I'm too tired to be productive and wake up with the problem spilling out of me.
I usually need a couple of weeks recovery time afterwards during which I'm pretty useless for anything thats not light and fluffy. But that time is 100% worth it. If I could work at that intensity for 1 week out of each month I'd be more productive than I have been at any 9-5 job I've ever had. Well, for a given definition of productivity.
So I guess I like pomodoros - I just think they should be about 1 week in length.
"From a practical standpoint, our research suggests that, when faced with long tasks (such as studying before a final exam or doing your taxes), it is best to impose brief breaks on yourself. Brief mental breaks will actually help you stay focused on your task!”
I think it suits your style of programming. My guess is you work in large repositories where you need to keep many complex data structures in your head in order to reason about what the code is doing. That's quite a common way of programming, and it does necessitate large blocks of undistracted time.
The Pomodoro/25 minute approach your OP is advocating I think requires that you write software a different way. You can't write big source files that reference hundreds of data structures. You can't write modules that require other modules to be structured just-so in order for things to work. You can't throw hundreds of views, models, etc, into a big repo and let them all call each other. You have to spend time constantly creating new interfaces, shuffling responsibilities around, and generally keeping your codebase such that no particular module requires you to reason much about the modules other than its few neighbors.
Frameworks tend to discourage this way of programming, because they want to give you a small set of primitives and have you fit everything into one of those boxes.
But if you can manage it, by avoiding frameworks, learning about all of the component systems available to you, and getting comfortable writing your own middleware, the 25 minute requirement can actually help you, since if you find a problem that you can't wrap your head around in 25 minutes, you know your next task is to move some module boundaries around so that you can get a clearer view of the problem.
Many software teams choose to operate on the bleeding edge of "could a very smart, full-time programmer with a lot of coffee understand what's happening after poking around for a couple hours?" rather than "does this interface create a region of the codebase which can be independently understood?"
80% of the programming I do is the style you suggest. But ... software development has bifurcated into two skills, and we don't yet have the words to differentiate them.
- There's the technician skill, where you poke at your react elements and fiddle with CSS until it looks like the mockup the designers gave you. Every 20 minutes you need to trawl through stackoverflow to find the exact way to use flexbox to get the layout you want, or to work around a bug in safari. When you're done you do some refactoring and feel good about it and call it a day.
- And there's the engineering skill, where you scratch your head and read wikipedia & some academic papers until you know what search terms to use. And then you realise that really you want something like an invertible bloom filter, except there's some small % chance it will fail each time you query it so you need a fallback mechanism. Except then you realise that fallback mechanism will have O(n^2) - but if you use a slightly different data structure then it'll become O(nlogn + klogk). But that requires modifications to the bloom filter itself and a funky network protocol, so you write that.
If the only programming you do is the first type, thats fine. Thats where we all start. Thats the majority of work out there. 25 minute pomodoros are probably fine for that. I like pair programming, because I can stay focussed better with a friend. Sometimes I listen to excited music while I work.
But all the work I'm most proud of is the second type. I wrote a streaming incremental compiler for a 2d air pressure based language. I got 90% of the way to making an OT algorithm work for arbitrary JSON structures (including object move), only to realise that it absolutely needs conflict markers so I put it down for awhile. I wrote a nodejs server from scratch thats compatible with google's browserchannel protocol - basically reimplementing TCP in the process. I implemented a PEG parser - and I'm going to need a session like this to add the ability to pass realtime streaming text updates through the parser.
These sorts of things can't be reduced to 25 minute context increments. They just need too much mental state. Maybe once they're done they can be broken down into pieces that you could explain in 25 minute chunks. But figuring out that some particular abstraction is the right one requires fitting the entire system together in your head, so you can turn it around. And thats a spacing out in the shower followed by a day with a whiteboard kind of task.
I guess the way I see it is that large amounts of uninterrupted time doesn't simply make it easier to do hard engineering. It makes it possible. Is that what the book refers to as deep work? If so then I think pomodoros are an anathema to that.
> But all the work I'm most proud of is the second type.
I think if that's true, you should spend your time structuring a back-end such that other people in the organization can take the "technician" stuff off your hands. People who care most about those parts of the codebase. Potentially even non-engineer. Start them in a read-only front end app. It doesn't get you out of the woods, because you still have to support all of those people. But your real job is doing the hard engineering work to create a robust framework which is safe for people to build on top of.
In the long term, you'll spend part of your time basically teaching, and the other part of your time doing that gnarly researchy stuff you love.
And you could eventually opt out of teaching too, if you found someone on your team who likes that work. Then you're just the wizard deep inside the machine making magic happen. Your teammates would probably help. Good people will take as much of the responsibility as they can, since they don't want you as a bottleneck anyway.
Do you mind me asking if you are self-employed? The rhythm you describe very exciting, but impossible in most work places. What you are doing though is probably the only work pattern that surely qualifies as "a sprint".
> I just think they should be about 1 week in length.
> I usually need a couple of weeks recovery time
And exactly like a real sprint (running very fast) a period of resting is necessary after such an effort, usually longer than the execution time spent.
Yes! I couldn't agree more. I'm happy to sprint. If do it much rather than a marathon. But only if I get a break after it. Otherwise it's a marathon that you start out running like it was a sprint and fail.
I would say you should adjust the timer to whatever fits your lifestyle.
I've always understood the pomodoro timers as 25 minutes of getting down into the trenches and then taking 5-10 minute breaks to think about whatever you're doing from a high level overview.
I find that approach works best for about three days. I suppose three days of work is all my little brain can hold! Three days of crunch followed by one or two days of downtime is insanely productive for me.
I think 25 minutes (or 20, in some versions) may be the ideal time period to get you started; not to get you to stop. It's easy to convince yourself to shut down your email, not look at any distracting websites, etc., if you can tell yourself that you have to keep it up for only 25 minutes. Once you get going, you may be able to work effectively and without distraction for a full hour, but if the pomodoro period were set to an hour to begin with, you might never have started.
About context, this is from Programmers at Work by Susan Lammers, interviewing John Page, author of the PFS productivity suite, famous in the late 80s.
Lammers: Why are programmers so obsessive?
Page: You constantly try to hold the state of the entire system you're working on in your head. If you lose the mental image, it takes a long time to get back into that state. It's like being an air-traffic controller who has nine planes in his mind and knows exactly where they're all going. Distract him by asking him when his shift is over and he loses those planes--the model he had in his head. In programming, a big complicated model is very efficient once you're in the groove. If you get out of it, you've got to work on it quite a while to get back in.
I used to advise friends to stick to the 25 / 5 minute break, but more because I thought that this enabled one to sustain this rhythm for longer. However, currently I'm experimenting with longer pomodori, with the reasoning that if I'm in the flow / deeply working, the value of that flow is too great to take the risk that I might break it because of an arbitrary break.
I think a better advice now would be to experiment, and see what suits you best in terms of sustainability, output and fulfilment.
Today I my pomodori were between 25 minutes and an hour. It's home time now, but I feel great due to a large part of the day filled with flow.
> You can't do creative work if your brain is filled with lot of context.
Intuitively I'd assume that the context and information in working memory is precisely what enables one to do "deep work". Constantly requiring you to rebuild your in-memory cache feels like it would lead to sub-standard work.
> You can't do creative work if your brain is filled with lot of context
I think you can, but the big risk is that what you produce becomes incomprehensible to anyone without all that context filling their brain, including you next week.
(Not saying I'm in favour of deliberate interruptions, just that this might be an argument for them.)
I used to believe this as well, then I tried 50 minutes, 10 minutes break and I like it way better. Try it for yourself and see which one works best for you!
Been pomodor'ing for 5yrs on/off... what i like about the 25, is it makes it a challenge, like a short race. "Can I really get this done in only 25?" It makes me work harder, and its a short enough time that i know i CAN give 100% focus if i start it with the right mindset.
Also, I never realized how short 25mins actually was. And working like that helps me estimate programming tasks. It used to be that someone would ask, "how long will it take you to do X?" I would always say, "an hour or two". Then I realized how short an hour actually is... only 2 pomodoros... and wow, that went by fast.
If I'm not done with a task, the trick I use for not losing focus between Pomodoros is to leave an easy bug, or purposely break something easy and leave a "//todonext".
I can't remember who, but some famous sculptor used this technique. He would purposely mess up an easy part of his sculpture, so that the next day, he had a "softball" to fix that easily got him back into work mode. (anyone know this phenomenon?)
>Yes, even after work, he makes the case for structuring your leisure activities in a similar fashion.
I find that this attitude makes it hard for me to relax. I've always been like this, and while I do derive a certain amount of comfort from it, I find it hard to schedule time to sit and do "whatever", and therefore it's hard to relax during that time.
To put it another way: A day at the beach sounds horrifyingly boring to me, but a day at a waterpark sounds awesome. I feel the need to be doing things during my relaxation time, even if I might be more relaxed doing "nothing".
I wonder, I used to feel that way, but now nothing is better than a full day at the beach truely relaxing and doing absolutely nothing. I wonder if it's because of age or because my job is really burning me out and leaving me with no energy.
I'm the same. I find playing hockey, basketball, etc to be the most "relaxing" of all activities. The only way I can really switch off is by doing something else.
I agree that social media and internet is a great distraction. But co-workers can be a source of good distractions. However for the distractions to be good. Everyone must be on track, around the same knowledge levels and focused on what problems needs to be solved. If you don't have these kind of colleagues, you might as well stay at home. When you are at work you will have to answer questions from those who didn't get the memo...
Jokes aside, for most of us, the only person who can give you a three-year "deep think" is yourself. Save up money, schedule off distractions, plan ahead, and have that deep-think semi-vacation.
Doable? Quite probably. Easy? Well, no. You have to already have a lot of concentration and determination to give yourself that large chunk of uninterrupted concentration and determination.
How does this work if you're on a "manager schedule" and 50% or more of your job is supposed to be dealing with interruptions, having ad-hoc conversations, and the like?
I haven't read this book but in my experience, "shallow" work is also a necessity, always has been; it's just that in last decade or so we seem to have glorified it and let it replace all other forms of working.
IMHO it's not a matter of avoiding shallow work altogether, but more about blocking off time and space to really think and prioritize rather than react react react. As a manager I'd imagine you'd need less of this time than your direct reports but it'd be good to help protect their focus as much as you can, assuming they want it. (Depending on the nature of the work, some people seem to thrive on bite-size jobs.)
Heard a lot of good things about this book, but the writing is just atrocious, and after a couple of chapters I didn't actually learn anything new... don't get the hype.
- Open space to promote communication and knowledge sharing (and controlling what people are doing), but at the end you are interrupted every 5 minutes by people walking and talking/screaming/laughing about anything but work.
- People expect you to have Gmail and Slack open all day and to reply in the 5 minutes.
- You are encouraged to go on Facebook/Twitter/Youtube/whatever to like and share the latest news/video/open position/whatever posted by the company. Then you start reading/watching something else that looks interesting and you lose easily 30 min / 1 hour.
- At the end, what matter is how many hours you spend in the office. Nobody cares if you spend a full week on a task because you can't never focus on what you do.