GTD Contexts for Developers: Beyond @Computer

When David Allen created Getting Things Done in 2001, @computer was a meaningful context. You could only check email at your desk. You couldn’t review pull requests from your phone. Location-based contexts made sense.

Fast forward to 2026: you’re a remote developer. Your work happens on a laptop. Your calendar? Computer. Your code reviews? Computer. Your deep focus architecture work? Also computer. When nearly all your tasks share the same context, that context becomes useless for filtering.

The good news: contexts aren’t broken – they just need adaptation. The key is shifting from where you are to what state you’re in. This article shows you how to build developer-specific contexts based on energy, environment setup, and interruption tolerance. For the complete GTD methodology and how contexts fit into the bigger picture, see our Getting Things Done Guide.

The @Computer Problem

Traditional GTD contexts were designed for mixed physical and digital work. Allen’s original examples – @home, @office, @phone, @errands, @agenda – assume you’re moving between different locations and tools throughout your day.

For remote developers, this model collapses. Your morning standup? @computer. The architecture refactoring you’re planning? @computer. That bug fix that needs 15 minutes of focus? @computer. Code review while waiting for CI/CD? Still @computer.

When every task has the same context, the context filter provides zero value. You’re back to scanning an undifferentiated list, which is exactly what contexts are supposed to prevent.

What Developers Actually Need

The real filters developers need aren’t about location. They’re about:

• Energy level: Can I handle complex debugging right now, or should I stick to routine tasks?
• Mental state: Do I have deep focus available, or am I in interrupt-driven mode?
• Environment setup: Do I have the local servers running? The right terminal tabs open?
• Time available: Do I have 90 minutes, or just 10 minutes before my next meeting?

These factors change throughout your day, often multiple times. The right context system helps you match tasks to your current capacity.

Energy-Based Contexts for Developers

Here are five developer-specific contexts that actually help you choose the right task. You don’t need to use all five – start with the ones that match your work patterns.

1. #deep-focus (High Energy, Zero Interruptions)

When to use: You have 60-90 minutes of uninterrupted time and high cognitive energy.

What belongs here:

• Complex architecture decisions or design work
• Debugging race conditions or tricky performance issues
• Learning new frameworks or technologies
• Refactoring that requires holding system state in your head

Requirements:

• Do Not Disturb mode enabled
• Meetings cleared from calendar
• Fresh mental state (not after 3 hours of meetings)

In Super Productivity: Tag these tasks with #deep-focus and filter to this view when you have protected focus blocks.

Pro tip: Most developers can only sustain 2-3 deep-focus blocks per day. If your entire task list is tagged #deep-focus, you’re setting yourself up for failure. Be realistic about cognitive capacity.

2. #review (Medium Energy, Interruptible)

When to use: You have mental energy but expect interruptions, or you’re in “communication mode” between meetings.

What belongs here:

• Code reviews and PR feedback
• Documentation reading
• Planning next steps for projects
• Organizing your backlog
• Responding to technical questions in async channels

Requirements:

• Medium focus – you can context-switch if needed
• Can work in 15-30 minute chunks

Why this matters: Many developers try to do code reviews during their peak focus hours. This is backwards. Code review is important but interruptible work. Save your deep focus for deep work.

3. #blocked-waiting (Low Energy, Any Time)

When to use: You’re waiting for something external – CI/CD pipelines, PR approvals, API responses, clarification from stakeholders.

What belongs here:

• Following up on blocked PRs
• Checking on deployment status
• Nudging reviewers who haven’t responded
• Researching solutions while waiting for access/permissions

Requirements:

• Just need to check status or send reminders
• Can be done in 2-5 minute bursts

In Super Productivity: This is essentially your GTD “Waiting For” list with a developer spin. Add these tasks with a follow-up date so they surface during your weekly review.

4. #low-energy (Tired But Available)

When to use: End of day, post-meeting slump, or mentally drained but still at your desk.

What belongs here:

• Routine maintenance (updating dependencies, cleaning TODOs)
• Filing bug reports you discovered earlier
• Updating documentation for work you’ve already completed
• Organizing your task list or project notes
• Clearing your inbox

Requirements:

• Minimal decision-making
• Can’t really break anything if you’re not sharp

Reality check: If you never have low-energy time, you’re either superhuman or lying to yourself. Build this context for when you’re mentally spent but still need to be productive.

5. #setup-heavy (Environment Preparation Required)

When to use: Tasks that require specific development environment setup – local servers, database connections, multiple terminal windows, VPNs, or specific branches checked out.

What belongs here:

• Database migrations or data imports
• Integration testing that requires multiple services running
• Performance profiling with specific tools
• Local environment troubleshooting

Why this matters: Batching setup-heavy tasks saves time. If you need to spin up three Docker containers and connect to a VPN, do all the tasks that need that environment at once instead of paying the setup cost multiple times.

Implementation in Super Productivity

Here’s how to put these contexts into practice:

Creating Tags

In Super Productivity, create tags for each context you want to use:

• #deep-focus
• #review
• #blocked
• #low-energy
• #setup-heavy

Using Short Syntax

When adding tasks, include the context tag:

Fix auth bug with race condition 2h #deep-focus
Review Sarah's API refactor PR 30m #review
Check if CI pipeline passed for deployment #blocked
Update README with new installation steps 15m #low-energy
Run database migration on staging 1h #setup-heavy

Color Coding by Energy

Assign colors to your context tags to make energy levels visual:

• Red = #deep-focus (highest energy required)
• Yellow = #review (medium energy)
• Blue = #blocked (waiting, passive)
• Green = #low-energy (lowest cognitive load)
• Purple = #setup-heavy (environment-dependent)

Filtering Your View

When deciding what to work on, filter by your current state:

• Have 90 minutes before lunch and feeling sharp? Filter to #deep-focus
• Between meetings with 20 minutes? Filter to #review
• End of day and mentally done? Filter to #low-energy
• Just finished a meeting and waiting for someone’s response? Filter to #blocked

This replaces the decision paralysis of “what should I work on?” with a pre-filtered list that matches your capacity right now.

Context Hygiene: Weekly Review Check

During your weekly review, audit your contexts. This prevents context inflation and keeps your system trustworthy.

Questions to Ask

Are tasks in the right context?

• Did you tag something as #low-energy that actually requires deep thought? Move it.
• Is that “quick bug fix” really #deep-focus, or are you avoiding it?

Context distribution reality check:

• Do you have 10 tasks tagged #deep-focus for this week? That’s unrealistic. You probably have 6-10 deep-focus blocks in a typical week, max.
• Zero #low-energy tasks? You’re either not being honest about energy levels, or you’re missing opportunities for low-stakes productivity.

Are you using too many contexts?

• If you created 8 different context tags and only use 2 of them, delete the unused ones. More contexts = more overhead.

Common Mistakes

Everything is high-energy: If your entire task list requires peak performance, you’re setting yourself up to feel like a failure on normal-energy days. Balance contexts across the energy spectrum.

Never updating contexts: A task that was #review when you added it might have become #deep-focus after you realized it’s more complex than expected. Contexts aren’t static – update them as you learn.

Overthinking it: Start with 3 contexts. You can always add more. Don’t spend 45 minutes of your weekly review debating whether something is #review or #low-energy. Make a call and move on.

Adapting to Your Work Patterns

These five contexts are a starting point, not a prescription. The best context system is the one you’ll actually use.

Experiment and Iterate

Try the energy-based contexts for 2-3 weeks. During your weekly reviews, notice:

• Which contexts do you use most often?
• Which ones feel unnecessary?
• What’s missing from the system?

Adapt accordingly. Maybe you need #meeting-prep for tasks that need to be done before specific meetings. Maybe #blocked isn’t useful because you rarely wait on others. That’s fine – build the system that serves your workflow.

Time-Specific Contexts

Some developers add time contexts on top of energy contexts:

• #2min – fits in tiny gaps
• #quick – 15 minutes or less
• #session – needs a full focus block

This works if you’re frequently asking “I have 10 minutes before my next meeting – what can I do?” If you rarely have those gaps, skip it.

Integration with Other Systems

Contexts aren’t a replacement for priorities or deadlines. A task can be:

• Priority: High (it’s urgent and important)
• Deadline: Friday
• Context: #deep-focus (it requires peak mental energy)

Priority tells you what to work on. Context tells you when you’re capable of doing it well.

Conclusion

When everything is @computer, location contexts become meaningless. But the underlying principle – filtering tasks by what’s accessible to you right now – is still valuable. The adaptation is shifting from “where am I?” to “what state am I in?”

Energy-based contexts give you a realistic view of what you can accomplish in your current mental state. They turn “I should work on something” into “here are the 4 tasks I can actually handle right now.”

Start Simple

1. Pick 3 contexts that match your work patterns (e.g., #deep-focus, #review, #low-energy)
2. Tag tasks as you add them using Super Productivity’s short syntax
3. Use context filters when deciding what to work on
4. Review during your weekly review and adjust

Don’t overthink it. The goal isn’t the perfect context system. The goal is spending less time deciding what to work on and more time actually working.

For the complete GTD system including how contexts fit with projects, next actions, and the weekly review ritual, read our full Getting Things Done Guide.

Related Resources

• Getting Things Done Guide – The complete GTD methodology
• GTD Weekly Review Guide – Keep your system trusted
• GTD Inbox Capture System – Close open loops and reduce mental clutter