Time and Project Management for Programmers
Programming is about getting to a minimum viable solution quickly and then refining it. That only works if the time is actually there, so this is how I account for it.
The three rules I work from
- Programming is about creating the minimum viable product or solution as quickly as possible, then refining it — adding improvements, or shaping it to a specific use.
- Treat everything as a project with a deadline. The deadline is what forces you to think through the details rather than discovering them halfway.
- Programming is about organisation and structure. That applies to the schedule as much as to the code.
Time management
Start by knowing what you actually have. There are 24 hours in a day, and for most people they split roughly three ways:
- Work — around 8 hours
- Sleep — around 8 hours
- Everything else — the remaining 8, which covers hygiene, meals, and the rest of a life
That last eight is what you are really budgeting. Being honest about its size is the whole exercise, because a plan that quietly assumes twelve free hours fails on the first day and takes your confidence with it.
Building a routine that holds
The simplest advice I have found, in order:
- Use a calendar app. This is not optional. A schedule you are holding in your head is one you are also negotiating with.
- Fill in everything you already have to do — work, sleep, meals. The fixed things first.
- Build the routine around those constants rather than around what you wish the week looked like.
- Fill the empty space with project steps, and guess how long each will take.
- Compare the guess with what it actually took. This is the part that pays off: it keeps you accountable to a timetable, and after a few weeks you have a real sense of how long a given kind of task takes you.
It is about finding the balance that works, and the only way to find it is to write down the estimate and then check it.
Project management
The same idea, applied to the work itself:
- Outline the whole project first, start to finish. Not in detail — in stages, so you can see the shape of it.
- Break it into steps and schedule them. A step that is not on the calendar is a step you are hoping to get to.
- Work to the minimum viable version first. Get something that runs, then improve it. A half-finished perfect version does nothing; a rough complete one can be refined.
Why the estimate matters more than the plan
The plan will be wrong. That is fine — the point of writing the estimate down is not to be right, it is to find out how wrong you are and by how much, so that the next estimate is better. After a few projects you stop guessing and start knowing, and that is the difference between a deadline you set and a deadline you meet.