Pratham naik
Posted on
2
1
2
2
2
Remote work is great, but it comes with challenges—communication gaps, time zone issues, and distractions. How can developers stay productive? This blog dives into key issues developers face and practical solutions to overcome them.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
Based on my own software engineering experience with remote work, I think these are the most important practices for me to stay productive for remote work.
Also, these really are the same practices that I use to stay productive when working in-the-office as well.
Plan the work. Work the plan.
Plan the work that you need to get done for the next sprint.
My team uses two week sprints.
Regardless if you use Scrum or not: plan your short term goals for what to get done.
I find that two weeks is about the right short term goal horizon to have enough work in the pipeline to focus on, without being overwhelmed by the amount of work to get done in the cycle.
("What's a cycle?" We used to have a ship cycle of eighteen months. That eventually became twelves months. Now we have three different ship cycles — a twice a week cycle, an every six weeks cycle, and a twelve month cycle. Corporate level strategic planning is on that twelve month cycle.)
Sidebar: we use a heavily modified version of Scrum. More akin to Scrum/Kanban hybrid. We do not use by-the-book Scrum. I have been using Scrum for twenty years, but I have never used by-the-book Scrum. I'd like to try by-the-book Scrum someday, but I don't think I will ever have the opportunity. I do not consider by-the-book Scrum to be an agile software development methodology; I consider by-the-book Scrum to be a lightweight management process that is completely devoid of agile development methodologies. It would be up to the development team — as a team driven enhancement — to decide upon and institute their own agile engineer practices in addition to Scrum's lightweight management process.
Work the plan. Daily.
Every day, the first things I do is:
I close email for the rest of the day because it is a distraction. I reduce my distractions. If something is critically urgent, I can be contacted by phone. I read Slack messages when I have a pause, such as during incremental build of the application.
If something is on fire, that can pre-empt whatever task I'm working on.
Corporately, Mondays and Fridays are designated as "golden days". No meetings are allowed to be scheduled on those days. I am grateful that my company has institutionalized these days as development focus days.
Drive a task to completion. Done-done.
A lot of people can multitask. I am impressed by those folks, and I admire them. A bit envious of them, as well.
I cannot. I am a hyperfocused monotasker. I cannot actively work on two tasks simultaneously. I have tried. Two bad things happen when I work on two tasks simultaneously: they take longer, and one of them might fall in the cracks.
They take longer — for example, if I have tasks A and B, and each task is nominally a 4 day task for me to complete, I can get A done on day 4, and B done on day 8. But if I work on them simultaneously, I can get A done on day 16 and B done on day 16. Context switching for me has an enormous x2.0 drag coefficient.
Fall in the cracks — because I may forget a small thing I was supposed to do next, and that small thing was vital. Like taking out some temporary diagnostic code that has a terrible performance impact. Or remembering to validate a tricky change on all six of our target platforms.
So I work on one task at a time. Until that task is done. Done-done. Driving that task all the through the gauntlet, to completion.
If I have a high priority task that interrupts my work-in-progress task, the task I am setting aside is practically a sunk cost. My brain loses all the context; my mental model of the problem space is wiped. It will take me time to recover and get back up to speed with it.
Interrupting tasks incur a penalty. When possible, I prioritize an interrupting task after the task that I have in-flight. If not possible, I work on what has to be worked on.