Hello! I am a software developer and over the years I found that I am extremely unproductive when it comes to finishing one task and then starting another right away. It is best noticeable when I complete something that took me more than one day and then I am guaranteed to not do anything productive for the rest of the last day(doing something for 3.5 days - unproductive for the half of the last day). Same applies to working on side projects. I am focused when I research one problem, implement it, but I have no willpower to continue to the next problem. This affects my career in a bad way and I am sure I am not unique and there are ways to fight it.
I've found that starting a new problem when my mind was previously focused on finishing a different big project is difficult but doable. First thing is take a 5 or 10 minute break away from the computer to clear your mind a bit. When you get back, open the issue or requirements for the next project and keep it on the screen with nothing else then sit on your hands and stare at it until your mind starts to wonder about whats possible and how you can do things. I do recommend physically sitting on your hands if you have a habit of browsing the internet when unmotivated.<p>It's like you need to repeatedly and unintentionally expose your mind to information that pertains to the project before you get into the flow of working on it. Just staring at it with no other outlets for activity or inlets of information forces the issue and speeds up how your brain is loaded with necessary information so that solving the problem becomes easy.<p>So another way to say it is remapping your working memory has a high cost until the previous information naturally falls out and your motivation and desires depend on that. So make it easy to move information into your working memory by making it the only information available. Instead of hackernews/reddit, put up the issue and reqs.<p>Also, for everyone else saying that you're not a robot, screw that. With the right techniques you can be a robot like the rest of us.
One step is to acknowledge that you're not <i>supposed</i> to be good at task switching. It takes a negative toll on everybody. Our brains just aren't very good at it. Because of this, your employer, if you have one, should take steps to minimize the amount of task switching required, or at least try to give you blocks of time you can dedicate to focused tasks.<p>That said, task switching is a practical reality, so coping strategies are important, too.<p>For help with that, check out Cal Newport's "Deep Work: Rules for Focused Success in a Distracted World" (<a href="https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692" rel="nofollow">https://www.amazon.com/Deep-Work-Focused-Success-Distracted/...</a>). Full disclosure: He and I share a literary agent.
I’m cursed with some kind of attention disorder and can’t keep track of what the heck is going on when I context switch. So over the years I developed this system:<p>I keep notes of what I’m doing and what I’ve learned as I do my work. I keep a separate note document for each task/project. I do this in One Note so that it syncs to my phone and I can attach clean processed images of whiteboards. But I used to do this with plain text files and vi. Either way I indent sub tasks.<p>In this document I break out and list all the things I’m going to do, with either a checkbox in one note or a [ ] if I’m using text. When I have done the task I change it to [x], and when I start the task I change it to [.]<p>When I get interrupted, I switch to the other file and keep track of what I’m doing there. When I switch back to the original task I scan the file and look for the [.] and that’s where I need to resume working. This step is crucial and helps me avoid the situation where it takes me 20 minutes to re-aclimate and remember what I need to do next.<p>Each day I do work I make an entry in the text file that tells me things below this line are in this date. As I complete projects I put the documents into a history folder keyed by date. This also lets me go back and see what I was doing on a particular date. This helps me avoid that “blank stare” feeling I get when management inevitably asks me why the task took so long or what the hell I’ve been doing all week. I’m not a slacker, I just need systems to help me overcome my memory and attention deficiencies.<p>You mentioned having trouble finding the willpower to go back and resume a project. A big cause of procrastination is not having faith that you’ll be productive with the project in the time you have available to work. Having the work broken down into achievable measurable chunks is key to fixing this problem. And that’s the major part of what this note system is all about fixing.
You aren’t a robot, ride the waves and stop trying to optimise everything. There is nothing wrong here - it sounds like most of the time you are productive and then find you need a break to begin something new. I always look at this as being a time for communication and “soft” work or learning something new. It’s a positive for everyone if you make use of this time to develop yourself and learn and communicate. Good luck.
This used to happen to me until I found why I lack the willpower to start (at least in my case). <i>The tasks were too big</i>. I started using GTD (with a tool called Nirvana) and slicing all my "tasks" into units small enough to be executed in five minutes.<p>E.g. rather than "Research using Foobar in the next mobile project", the first task is "Write a Foobar Hello World". Rather than "Write proposal for project X", the first task is "Draw logical architecture diagram for X".<p>I find the inertia against getting started is a lot less when the task is a five-minute, self-contained unit. It also helps task switch because you don't treat them like links in an unbroken chain of tasks, but individual units.<p>Only downside: you have to spend some work up front slicing your projects into smaller units. It's kind of analogous to story slicing...
I personally see it as a skill, and one that should be self trained.<p>Trick 1: Improve your cardio health.<p>Generally a balanced meal gives you a lot of willpower. Cardio exercise specifically seems to improve recover rate a lot, not just physical but mental.<p>Trick 2: Develop a trigger.<p>Find a routine, a kind of trigger that puts you in the mood to work. There's a trigger already built into all of us, a moment of serenity that we see as taking a break.<p>This is the kind of productive thing that makes you work late at night, or weekends, or continue nonstop for 20 hours straight. It might not even be work - it could be a game, book, or some tedious hobby like woodworking.<p>I use Linkin Park songs because my productive moments were making games in school. I also saw Chester Bennington as a role model, because of his emotional drive and his success as a VC. Some of his songs also resonate with me on a spiritual level. His suicide got to me, and I find his songs as a sudden reminder of why I do what I do.<p>It doesn't have to be a song. It can be something like flipping a coin between your fingers, taking a deep breath, pumping your fist, a 5 minute meditation. The more portable the better - you don't want it to be something like eating a can of spinach.<p>You also need to associate the trigger with positive things. One of my mistakes was poisoning an old trigger with death marches.<p>Whenever you hit a moment of pure joy, try to associate that with your trigger. It could be the completion of a tough patch of work, playing with kids, breathing fresh morning air.<p>There's a lot of principles that go into this, but I would recommend the books The Power of Habit and The Art of Learning if you want more details.
For me it comes down to inertia. When I'm working on a project, I can barely get myself to stop, but when I do stop, it takes some time to get started again.
My trick is: as soon as I finish one project, I open up everything I need for the next project, then start my break. When I open up my computer next time, seeing everything there ready to go makes it much easier to jump right back in. This task switching problem was actually a big motivator behind why we built Workona.
A few ideas:<p>- Don't do large tasks. Spending more time up-front breaking down a large task into smaller, more-manageable tasks might help. This is something that many engineers struggle with, but there are huge advantages to this kind of discipline that go beyond taming your concentration issues, so this could be valuable in more ways than one.<p>- As others have said, go for a walk. There's something about activating our peripheral vision and looking from side to side that activates different parts of our brains and makes us more creative. It's even used as a therapeutic technique (EMDR) for dealing with PTSD.<p>- Find non-project tasks that you can do to fill less productive gaps. Do code reviews, go back to old projects and fill-in additional test coverage, play with some new technology/tool...a lot of teams neglect hygiene tasks anyways, so you may benefit from acknowledging your weaknesses and trying to make the best of it.<p>- Offer to pair with engineers for the rest of the day. If you know you can't be productive for that time period on your own, perhaps you can add value as an extra set of eyes.<p>- Don't fight it, embrace it. There's a mantra in startups to embrace your limitations. As engineers, we're not nearly as good at problem solving when we have no constraints. But when there's some real-world concern that points us in a particular direction, it's often easier to find the right solution. So look at this the same way. Don't beat yourself up about it. Be kind to yourself and accept that it's just a reality. Once you do that, put on your engineering hat and think of how best to deal with an unideal situation. Because situations are never ideal in the real world.<p>- Learn to meditate, particularly anapana meditation where you train yourself to concentrate on nothing but the breath. Concentration is a skill that can be practiced. It may be that you're not able to concentrate on something new because you're still concentrating on your previous task. Learning to clear your mind may help you move on to something new after a short break.<p>Best of luck!
Always park all of your projects downhill by noting down the next concrete actions before putting it away. When you then switch into a project there will be a clear and immediate todo to perform, that serves as the hook for retrieving the context from your brain.<p>I find that a 10 minute break followed by a clearly defined action item is usually enough to get me going.
Personally, I embrace the downtime that I get after finishing a large task. I see it as a way to force myself to take healthy breaks, which are easy to forget when I'm "in the zone."<p>When I finish a large task, I take a few minutes to think about how I should spend the rest of the day, grab a coffee or snack, use the restroom, check the news, then jump back in.<p>I even find that, when I forget to take breaks, I'm more easily fatigued and discouraged by what can otherwise feel like an endless amount of work.
Some people naturally fit for jobs that require frequent task switching, others don't. It's about reward system in our brain, once you finish a task you need time to take your reward. If a time off is a reward to you then you need a time off. That's kind of natural thing, evolved in us during school times. If a reward means that you can start a new task - then you will happily proceed to it.
> This affects my career in a bad way<p>Can you enumerate this further? Are you getting measurable and actionable feedback from a superior, or do you just feel like you should have accomplished something with the additional half of a day?<p>I'm going to reaching a little as I don't know you're specifics, but I've found myself in this situation before and as a manager I've had to help my reports with the same issues. Typically when I hear this from my reports, their behavior falls into one of three categories:<p>1. They're still working on things, but they don't contribute to what they see as their primary goal. I.e. I ask them to rework something, they have to dig through documentation/emails/etc to answer someone's question, or they have some HR function they have to complete. In the first example it's often times expressed as "This took me all month!"<p>My suggestion in these situations is to realize you're being "alternatively productive." My ask that someone rework something or performing duties for another team is still part of being productive. Not all managers manage that way so if you're running into trouble here, I'd bring it up and discuss it further.<p>2. They're not being productive and legitimately are just taking some downtime and feel bad about it.<p>Assuming I've gotten 3.5 days of good productivity out of someone, I ask them to embrace their downtime. Take a walk, chat with folks, read some blogs, or just simply go home early. I'd rather someone come back refreshed the next day than waste four hours feeling bad at their desks and contribute to a future episode of burn out.<p>Some managers are driven to make sure butts are in seat coding 40+ hours per week. Thankfully my company doesn't work that way.<p>3. There is a performance issue. Sometimes that's on me (poor direction giving, unclear instruction or goals, being too busy doing my other duties, etc) and sometimes it's on them. For example their 3.5 days of productivity and I need to help mentor or drive them. That's where immediate, specific, actionable, and measurable feedback comes into play.<p>That's something a lot of managers are bad at. I'm aware that feedback itself has a quality component that should be met and still do a bad job at times.<p>I hope something here is helpful for your situation.
You are a human being, not a machine. Some down time after you complete something is perfectly ok, the only thing that you will end up achieving if you want to perform at 100% all the time is an early brush with burn-out.<p><i>Nobody</i>, not even the most vocal proponents of maximizing productivity can be productive all the time.
I wouldn't bother too much. This may affect you into thinking you lost 10% of your time, but you don't. If you try to be 100% all the time, you'll end up with a burnout. Appreciate this time, do some reading, finish loose ends. Focus on quality, not on quantity.<p>Tell your boss that this is you. You need that time to recover, so you can focus on the new project. It's like with sporting - a professional sporter plans his recovery time. What you do is professional sport as well. Take care of yourself. It's long term vision.
1. Take a walk for 5-10 minutes<p>2. Reward yourself for a job well done (buy a coffee or a chocolate)<p>3. Force yourself to think of some other aspect of your life for a few minutes<p>4. As soon as you're able to let go of the emotions associated with the project, you'll be able to get back to work, but not a moment before
I think there's something to be said that if you REALLY enjoy what you're doing you'll immerse yourself into it with infinite willpower, and most importantly, you'll be ridiculously happy doing it. There simply aren't enough hours in the day when you're highly engaged in something.<p>If you find yourself fighting doing what you think you like doing, and get distracted easily then maybe you're not really doing what you should be doing.<p>That doesn't mean you should stop being a software developer, but you should be aware of that.<p>Maybe it's different for everyone but back in the day I was really into gaming. I don't mean casual gaming either.<p>I mean playing 12 hours a day, and min / maxing the shit out of every game I played. Basically playing for maximum efficiency, constantly improving and focusing 100% of my attention to it, for literally 10 hours straight without moving -- but then doing that with various games for like 4 years straight. Needless to say I got very little sleep in HS and my early 20s haha.<p>Think about that tho. While you may think "oh it's gaming", it was really high intensity thinking and unlike programming, it also required very good reaction times (at least in the games I played, such as Diablo II, Quake 3, etc.).<p>When I lapse into inactivity periods in software development I always think back to those gaming days. Why didn't I burn out gaming, when mentally it was even more draining than programming?<p>The only conclusion I can think of is, if I reach to check email, reddit, HN or youtube instead of working on software developer related tasks, then I must not enjoy it as much as I think I do (which I've accepted). Deep down I do enjoy it, but I don't enjoy it enough to sit there for 5 years straight working on things 12 hours a day.
Can you share a little more about how you plan your time and projects now (or don't)?<p>Planning and revisiting a project plan regularly to weak it that has work laid out in small enough steps is really important. It helps create good stopping points, and easy starting points.<p>I'm not sure if you use a simple kanban like Trello but it's important. In the beginning using a smartphone to curate the list constantly helps you build a habit of knowing what's currently on stage, up next, etc.<p>If the goals are too big or too vague it's hard to conceptualize them. A good rule of thumb is to try to get major tasks down to 4-8 hours each, and let them be a larger part of the really big solution you're after.<p>There's other legitimate issues too like dealing with interruptions, or emergency issues.
I am curious if anyone is cheering you on. If someone completes a task, a manager (project or product) should get excited and congratulate you. Even just a thumbs up or a hi five on slack and cheer a bit with public recognition. This will give you a shot of dopamine and create an addiction cycle. If this isn't happening, you finish something and no one cares (bad management) your brain will not connect finishing something to good -- thus the struggle to care about the next task.
Here’s one idea that works for me. I am crash coursing several Khan Academy maths to prepare for a grad levelML/AI course in the fall. I also work full time. I have found that see-sawing between writing software and studying math makes me focus on both more intensely than if I did either on its own. I have work to do and I need to learn a lot of math in a small amount of time. So I have to focus hard on both or I won’t get much of either done.
I am currently half way through the original Getting Things Done book (GTD). I find the approach to be a possible solution this context switching if you know in advance what some of the other projects are. The idea that you have a plan for each project and the next action available, greatly reduces the stress of switching contexts.
I have to task switch _a lot_ in my job. My day consists of writing code, supporting content creators with their tools issues (which often leads to switching to a different piece of code to fix a blocker), and supporting my team as they work on their tasks. Often I don't have the luxury of <i>choosing</i> when to switch tasks, but when I do or when I'm being hit with a ton of things at once it helps to take a short coffee break, re-prioritise things in your mind (or on paper via a list), and then get back to it.<p>Days when I can just work on one thing without interruptions are extremely appreciated but so rare. When I do have the luxury of finishing a big task that took several days and not being immediately pulled away by someone else to another task I take advantage of the downtime and maybe try to go home early, do some reading, or have a longer "fika" with a coworker.
I take a small break (15 mins) and then either find the motivation to continue onto another big task or work on polishing the "small things" that always pile up.<p>While the break does it for me, the important part is that you reward yourself in some way immediately after to engage the "work-reward" cycle.
Seems like you work strictly sequentially. What would help is to bring in more dynamism based on your mood & time of the day.<p>Dynamism = mixing of subtasks from various tasks in a way that optimizes your energy spend and work satisfaction.<p>Let's run with your example of 3.5 days worth of task-1 followed by task-2. So at the start of day 4 you have a sense that only half a day or so work is left on task-1 that might be mostly testing, addressing review comments and deployment. On the bright sunny morning of Day 4, I would keep that grudge work on hold and put my energy into designing a solution for task-2 (deep work that I would enjoy, requires more R&D, thinking, research etc.). Then you could pick up remaining task-1, the known stuff requiring less energy in the latter half of the day and finish it.
For me it's not a problem, it rather makes problem solving easier and faster.<p>When I'm stuck at one bigger problem, I cycle to the next open problem which is most similar, and work on that (max 1-2 weeks), and switch back then. Sometimes this cycling can last for 1-2 years, until I can solve the first problem where I got stuck. Walking around also does help, but solving something similar as like attacking the problem from a different angle.
Nowadays managers call that agile.<p>For shorter times, e.g. waiting for long test runs, I can easily switch to another task, in a 2nd git branch and workdir, and work on that until I know if the first testrun passed or failed.<p>Max parallel tasks is 3, but they should be related. Wife interrupting is forbidden. This does not count, and destroys the concept.
I keep a stack of blank todo lists and use one per work day. I separate each large item into actions that I rank by difficulty. After finishing a particularly demanding action I'll do several lower hanging fruit before attempting another action that I know will be more draining. Also, I once or twice daily leave my office with my laptop and go to a coffee shop and log off Slack and e-mail and let my coworkers know that I'm gone (I just post an Oasis music video at this point on a Slack channel) and bang out whatever thing is frustrating over a small coffee.<p>Another thing that I've found particularly helpful is beginning work around 7 am so I have about 2 hours before I need to deal with any human interaction that will pull me away from my actual work.
I suggest, on completion of a major task, you switch to cleaning up after the task. If possible, get up out of your chair to do this -- I find that the transition to physical movement helps this along. It's easier if it's a hardware task -- then there's shelving instruments, putting tried-and-discarded parts back into lab inventory, sweeping / vaccing up metal shavings etc -- but there's also polishing up documentation, tidying up journal / wiki entries, capping off histories, doing a grammar/detail edit pass on comments in code, snapshotting process files, etc. For me, psychologically, it's bundling up the job's result and closing off commitment to it which frees me up to face the next task.
Lots of good ones on here.<p>I'm not particularly good at this either, but one thing that has helped occasionally is keeping multiple tasks running concurrently. With software, among other things, it's very easy to settle into a grove where I find myself getting too comfortable in solving particular problem. So to temper this effect, I switch tasks and work on something else every once in a while, kind of like skipping on a lily pads.<p>A machine learning equivalent is over-fitting. To not overfit is to not feed the brain too much of the same data or otherwise you end up needing to retrain / remove old memory from slots, depending on which metaphor you tend.
I don't bother much with trying to make my work rhythms other than what they are. It's natural for most people, I think. I concern myself with what I accomplished in a year, not what I did last Friday afternoon.
> I am focused when I research one problem, implement it, but I have no willpower to continue to the next problem.<p>It's because you probably lack of feedbacks. I'm now avid of that and it helps me a lot in pursuing my project's goals.<p>It's also one of the reason I'm building a community of programmers with some folks. I feel more comfortable since I'm working with them.<p>PS: You can join us if you wish (check my profile).
Reflecting on my personal experience, I too have trouble switching from one task to the next when the next task is vague. I have brought down the 'down time' by planning next task ahead in time. Somehow that makes the switching easier for me, as I know what to expect from it and what struggles I might have.
I am unproductive if I am given a task where I can't switch to something else. If I have to work on a task for longer than 2 hours then I become unproductive. This is why I am always jumping on helping other people with their tasks and get pushed into leadership roles when its just really me coping with ADD.
Make a list of what's coming up, the next 3 or 4 tasks if you can. Just this simple task of knowing what you have coming will let your subconscious start to think it over a bit so by the time you are putting the finishing touches on one task you already have a toe-hold on the new one.
I usually keep a small backlog of tasks that can be fit around the bigger ones and then fit them to suit my mood. This can be learning, doing code reviews for other developers, testing, documentation, etc.