How do you keep track of what you’re working on so you remember where to start next time?

Comments

[Adrian B.G.]

We all know what is used for bigger and projects that involve a team, but I'm creative when it comes to small side projects where I'm the only contributor:

• leave unit test failing (TDD style)
• a txt file in the project root with the Change log + TODO list
• trello if the project is medium/big in production

[Andreas Renberg]

Simple: I don't quit while in the middle of working on a piece of code.

It's more of an obsession, really. If there is a part that is incomplete, I can't focus on anything else, or even sleep unless it's been resolved.

By the time I do give up, the code is either complete to a point that the bare essentials are in place, or if I'm working on a really long script, there is a exit or a return statement that marks "everything in the script is working up to this point".

Any "non-essential functions" that are incomplete but can be ignored while testing and prototyping (such as special character escaping, allowing for arguments instead of hard-coded testing values) are left empty and marked with a //TODO comment.

• Does this mean that I'm sometimes up until 4 a.m. getting a non-essential piece of code to a stable point? Yes.
• Is it healthy behavior that I recommend for other developers? Probably not. But it works for me.

[Flavius Aspra]

Taskwarrior. Timewarrior. And some environment variables and aliases:

export TASKRC=(pwd)/docs/taskrc
export TIMEWARRIORDB=(pwd)/docs/var/timewarrior
alias backlog='task project:backlog'
alias sprint='task +sprint'
alias upcoming='task +upcomingsprint'

[Adam Brandizzi]

That depends on the situation but I have two indispensable tools:

• Issues. I really like issue trackers and I always write an issue before starting anything. It is great to clean up the pending tasks from the mind, to clear the requirements and, of course, for documentation.

• A notebook. My favorite ones are legal pads, but they are quite hard to find here... Anyway, any one will do. If it is somewhat larger than a pocket, I like to split each page in two columns. The first column is an immediate to-do list, and the second one is reserved for any kind of annotation I want to do. Of course, there are many other approaches.

Sometimes, a task goes into my personal Wunderlist to-dos, but it is rare. The two tools above are the ones that save my day.

[Ben Halpern]

I think the notebook is key. Right now my personal system is slightly disorganized, but the act of physically using your hand to write something down really helps lock it into memory. If I write something down, I usually don't even have to refer back to it. If I don't write it down, or simply type it, the effect is totally lost.

This is definitely my personal experience, but there is plenty of research to back this up as well.

[Theresa Luu]

@adam and @ben , also for handwriting, my fav new thing from this past year has been writing w erasable Japanese pens and markers: jetpens.com/blog/pilot-frixion-era... I buy them at Japanese stationary stores.

The erasers don't produce debris like normal erasers. I love them. Just fair warning, don't leave your notebook in high heat because it will fade the pen/marker marks

[Kwaku Eshun]

This is me. I always write it down and never refer to it but always remember

[Theresa Luu]

@adam do you then transfer your ongoing to do list somewhere? I think this is a cool idea but your short term task column would outpace your long-term column. I LOVE talking about task systems!

[Adam Brandizzi]

The first column is the short term one, the second column is the yet-shorter-term one :) There I write any note I need. It may be subtasks or any debugging information, or even a phone number I'll have to call! The second column is deeply unstructured, so I can keep the first one tidy.

Yet, it is true that the second column outpaces the first. When it happens, I go to another page and restart thed process, copying any pending task.

This method works for tasks that I'll handle in the current day or, at most, in the next day. If a task is not going to be handled in this interval, I have different "buckets" for different contexts:

• Tasks at work usually become a JIRA issue. I am upfront when it comes to create tickets, especially technical subtasks. But those are only half of my tasks; the other half are emails and pull requests. Regarding those, I use my inbox and my PR listing as my to-do list.

• Tasks on personal projects become tickets in my personal repositories. Even if the project is deeply personal, I create issues for that. I find it quite instructive and calming!

• This is how I handle my programming-related tasks. Any other thing I have to do goes to Wunderlist or, ideally, become an event on Google Calendar. But I guess it is beyond the topic :)

So, I handle the long term with digital tools and the short term with paper, basically.

[Melissa Martinez]

I mainly use Trello, there's other similar tools out there. I like that I can have 'boards' for each project, and 'cards' for each task. When I'm working on a task, I'll make a card on Trello and put it in a 'in progress' list. And while I'm working on the task, I'll jot down notes inside the card as I'm working, kind of like you would if you were taking down 'minutes' in a meeting. I'll also include links to github issues, todo lists etc... That way if I get distracted and abandon the project for a while, I just refer to the 'card in progress' and read all my notes to get right back into it.

I'll also have a collection of notepads and stickie notes while I'm working, but I makesure to copy those notes onto Trello before I close a project because I tend to misplace tangible objects 😅

[Brian Dean Jennings]

When I'm in the middle of something, but have to leave for the day, I will type a bunch of jibberish on the line I was working on (and don't check it in). Then, when I come back the next day, my IDE immediately shows me a highly offensive big red compile error. Fixing the compile error pulls me right back to where I left off.

For longer-term todos, Ilike to use user-friendly task tracking apps that I can access from anywhere (PC and phone). I've used Trello and Asana in the past, but my current favorite is Favro.

[Josh Cheek]

For something I'm actively working on: a text file with a todo list inside it, usually added to .gitignore so that I can burn through a bunch of them quickly.

For something more long-term, ie I periodically work on it: Github issues, their primary role is to summarize the issue and include a code sample that either reproduces the bug or demonstrates what it would look like to use the feature. Their secondary role is to aggregate information, ie if I've done a bunch of research into a bug, they walk through everything I did and summarize what my conclusions were, that way I can re-read it instead of having to reinvest the effort to figure out the issue.

I also use tests for this, eg if I'm starting a project, I'll write out the names of all the tests I want it to pass, here is an example: github.com/JoshCheek/an-editor/blo... Sometimes I start by writing out all the tests, but usually 3-5 tests is enough, and then I can begin. The advantage of writing the test names is I left myself a description of the path I expect to go down. The advantage of writing the tests is that there is a series of existing tests that show me what I need to do to successfully go down that path. For me, writing the test names is often synonymous with figuring out what I'm doing, and if I still can't quite tell, then writing the tests takes that role. If I still can't tell what I'm doing, then I should either be testing at a higher level so that I can specify an outcome while knowing fewer details, or I should be prototyping, not testing, ie figuring out what I want.

Reading my last several commits is also a frequently useful way to get myself back into context.

[Ernest]

I have two ways to track my progress

I use Evernote when I'm out of the office and I need to remember something for either the next day or a task for the future: eg documenting some new feature.

I use a paper notebook for bugs and issues I can resolve in the current work day. Stuff I don't need to return to.

[Jon Calhoun]

I prefer to keep things simple. I have a notebook with larger todos for the week, and then when I am about to end for the day I leave myself a quick summary that I can read first thing in the morning. Sometimes this is in code where I need to start, other times it is somewhere else (new editor tab usually). It usually says something like:

I fixed but X by doing Y, but Z still seems to persist. I think it might be blah blah, so I think the next best place to start digging it .

After that I was thinking it would be a good idea to start on ."

It sounds a little crazy to talk to yourself, but it is really helpful when you are groggy and waking up to quickly recap what you were thinking the night before and evaluate what to do next.

[Theresa Luu]

For general tracking, I use Issues. For bookmarking something I am debugging or for building some kind of complicated logic, I leave comments in my code for myself. This comes in handy when it's 11:30pm and my eyes have started to cross. =) My future-7am-self generally appreciates it.