Notes on getting things done from Gergely Orosz’s book “The Software Engineer’s Guidebook”
Different chapters of “Part II: The Competent Software Developer”
Plus personal experience
Overview
Getting things done reliably: good at breaking down work, estimation, autonomous unblocking, deliver quality work
Reliable developers:
Focus on the most important piece of work
Unblock themselves
Break down the work
Estimate the duration of work
Seek out mentors
Keep “goodwill balance” topped up
Take the initiative
Focus on the most important piece of work
It’s easy to get overwhelmed and feel like you’re not making progress
Simplify your work life
Ask what is the most important work; the single most important task on your list?
If you could only do one thing this week, what would it be?
Your answer is your #1 priority
When you identify it, ame sure to definitely, absolutely deliver that piece of work within the agreed timeframe
Make a habit of always completing your #1 priority
Make sure it always gets done, event if it means turning down other tasks, skipping meetings, and pushing back on other matters
If you consistently deliver the most important work as expected by your manager and team, you’ll be seen as a reliable developer who gets things done
Saying no is sometimes necessary
Decline requests respectfully
You don’t need to turn down ecerything, but when you’re at risk of not completing your #1 priority task, then do say “no” / “yes, I’d love to help, BUT …”
Unblock yourself
Building software often has unforeseen obstacles
Thousands of things you stumble upon that must be solved before progressing further
Blockers are more often than not not technology problems
Reliable software engineers are able to solve blockers faster than colleagues
How can you get better at unblocking yourself?
Know when you’re blocked: productive engineers catch themselves and admit they’re stuck
Rule of thumb for catching yourself being blocked: if you go more than 30 minutes without meaningful progress (an hour at most) admit you’re blocked
Try different unblocking approaches:
Rubber-ducking (explain your problem and the approaches already tried out loud)
Draw out the problem on a pieace of paper (visualize it)
Read documentation and references (there could be a solution for the problem)
Search online for similar problems (describe your problem in various ways, others mught have used different terms for the same issue)
Post a question, check sites like StackOverflow or other relevant forums (explaining the problem you have can also give you additional ideas on how to solve it)
Take a break (go for a walk, switch to an unrelated task; you come back with fresh eyes, might notic something you missed earlier)
Start from scratch, or undo all changes (go back to the last point at which the code worked and restart by making small changes, one at a time)
Get support to unblock yourself
Cheatsheet to unblocking yourself
Break down the work
Think about high-level, tasks, and subtasks
What are the main pieces of work (chunks)?
Once you have identified chunks, break them down again into tasks which are straightforward
If needed, divide complex tasks into subtasks
The easier it is to understand what needs to be done, the easier it is to estimate how long it will take
Break down the work into small parts, and then challenge yourself to make them even smaller
A good time to stop breaking things down is when the tasks are clear enough to you
Prioritize work which gets you closer to shipping something
Focus on an order of work (tasks) that gets you closer to working functionality
The sooner you have something you can test end-to-end, the sooner you can get feedback on whether you’re on the right path
Once you have a basic case in working order, decide the next priority, and which tasks you need to solve to achieve it
Add, remove and change tasks
Remember your goal (build software that solves problems, not to close tasks)
Tasks are just a tool for organizing work
Use this tool, be ruthless in changing and adding tasks as needed, or removing redundant ones