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.

[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.

[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'

[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.

[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.

[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.

[Christopher McClellan]

For pet projects, I keep a simple web page running. Just some plain HTML with lots of li's and strikes. I've yet to need much more and I can access my VPS from any terminal. Bonus: It feels really old school to edit some HTML with vi over an ssh session.

[CS]

I use a combination of Trello and readme notes like I imagine a lot of other people do, but on big projects I also tend to draw out overview mockups with something like draw.io (free online tool).

Having notes, cards, and a good wireframe really helps me keep on task.

E.g. Here's a mockup for a talk I did last year on vue.js. I built out a simple app to explore idea of the tool.

Before I started working I built out this wireframe and then between that and my notes I was able to build the app over the course of two (or so) weeks of 30 minute breakfast coding sessions.

[Brian Dean Jennings]

If I'm in the middle of something, I'll type gibberish into the place where I was working so my IDE shows a giant red compile error. The next day, I fix that and I'm right where I left off. I can even target a specific part of a line of code with it.

For tracking todos, I use user-friendly task tracking apps that I can access from my phone as well as the PC. I've previously used Trello and Asana, but I'm a big fan of Favro these days.

[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.

[Paul Lefebvre]

I keep a small spiral-bound notebook in front of me during the work day. I write immediate tasks in it and anything new that comes up.

I also use the Apple Notes app for ideas and longer-form thoughts.

I has have an issue tracker for keeping tabs on specific project-item details that others need to know about.

[Tune]

most of the time, when working in a team, I use issues through redmine within the team, so that everyone in my team knows who is doing what and if someone is getting ill, someone else can seamlessly finalize the tasks.
If I'm working alone on something, I track all things that should be done, are done or need to be reworked, within my mind. I never forgot something, really helpful to train your memory.

[Sean M. Collins]

My work is tracked in Gerrit.

I make a lot of work-in-progress patches, so I push them up to Gerrit (even if they are nowhere near completion) and mark them as WIP. That way, when I log back into Gerrit I have all the patches I have in progress right on my dashboard.

I write pretty good commit messages with detailed info so it's pretty easy to pick up where I left off.