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
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.
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.
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.
I'm a full-stack web developer who loves to garden, cook, read, and dance. I enjoy the ritual of making coffee, and sometimes I crave cheese and other times I crave fish sauce.
Location
Orange County
Work
Software Engineer at Blizzard - My thoughts and opinions are my own.
@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
I'm a full-stack web developer who loves to garden, cook, read, and dance. I enjoy the ritual of making coffee, and sometimes I crave cheese and other times I crave fish sauce.
Location
Orange County
Work
Software Engineer at Blizzard - My thoughts and opinions are my own.
@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!
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.
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'
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.
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 😅
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.
I'm a full-stack web developer who loves to garden, cook, read, and dance. I enjoy the ritual of making coffee, and sometimes I crave cheese and other times I crave fish sauce.
Location
Orange County
Work
Software Engineer at Blizzard - My thoughts and opinions are my own.
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.
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.
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.
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.
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.
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.
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.
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.
I am a huge proponent of visibility and issue tracking, so first choice is typically to update the ticket. I love it when I am able to finish the day with a feature complete commit, but that doesn't typically happen. I still try to commit at the end of the day and use a descriptive message which I reference in the morning to pick up from there. Worse case scenario I leave everything in place with an error on the screen or a broken test, something that will yell at me when I try to go in the wrong direction. Post-its are another fun tool for reminders.
Typically at work and certainly for my own projects I use Jira for bugs, planning and tasks.
On top of this, particularly for planning and remembering what I need to do next, I use Structure. It's super fast to add new tasks and sub-tasks and move them around in a tree like structure.
Each task, even small ones, all you have to do is press Enter, type a description, press Enter. Then you can use Ctrl-arrows to move things around.
Because it's on top of Jira you can then assign tasks out, mark them in-progress, make notes in them, etc.
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.
I mostly use plain txt files. Usually I put there current tasks and its' steps. At the end of each day I make a small report on what I've worked.
For really large tasks I create a separate txt file.
We have an issue tracker, but text files for personal planning are a different story :)
Not the most technical, but I usually jot down a quick handwritten note to myself. I have a notebook that is always with me, or at my last job I would use a post-it stuck to my desk.
Emacs, org-mode, and my notes file opens on startup. At the end of the day, I just coredump my brain, think of a few simple tasks to start with in the morning, and go home.
🇫🇷 iOS Crafter depuis 2010, maniaque de la livraison continue. Zelda fan, papa d’un p’ti gars, cuisto à mes heures perdues (batch cooking le samedi matin !).
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:
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
exitor areturnstatement 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
//TODOcomment.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.
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.
@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
This is me. I always write it down and never refer to it but always remember
@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!
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.
Taskwarrior. Timewarrior. And some environment variables and aliases:
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.
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 😅
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.
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.
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.
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.
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.
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.
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.
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.
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.
I have a OneNote page where I outline the things I need to do before I start coding, like this (it's usually much longer):
Modify feature X
Then delete the page when I'm done.
I am a huge proponent of visibility and issue tracking, so first choice is typically to update the ticket. I love it when I am able to finish the day with a feature complete commit, but that doesn't typically happen. I still try to commit at the end of the day and use a descriptive message which I reference in the morning to pick up from there. Worse case scenario I leave everything in place with an error on the screen or a broken test, something that will yell at me when I try to go in the wrong direction. Post-its are another fun tool for reminders.
Typically at work and certainly for my own projects I use Jira for bugs, planning and tasks.
On top of this, particularly for planning and remembering what I need to do next, I use Structure. It's super fast to add new tasks and sub-tasks and move them around in a tree like structure.
Each task, even small ones, all you have to do is press Enter, type a description, press Enter. Then you can use Ctrl-arrows to move things around.
Because it's on top of Jira you can then assign tasks out, mark them in-progress, make notes in them, etc.
For personal use these are both only $10 each.
For the big picture I used workflowy but switched to bullet journal on a notebook.
For projects use issues (with checklists) and hopefully a Kanban view.
Try to avoid 'left in middle of coding' but then rubbish text to cause build or runtime error.
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:
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.
I mostly use plain txt files. Usually I put there current tasks and its' steps. At the end of each day I make a small report on what I've worked.
For really large tasks I create a separate txt file.
We have an issue tracker, but text files for personal planning are a different story :)
I have a commit named [Work in progress] with the number if the ticket I'm working with.
Not the most technical, but I usually jot down a quick handwritten note to myself. I have a notebook that is always with me, or at my last job I would use a post-it stuck to my desk.
I mostly rely on memory but I also make notes in the code using comments.
Emacs, org-mode, and my notes file opens on startup. At the end of the day, I just coredump my brain, think of a few simple tasks to start with in the morning, and go home.
At a macro level, a physical kanban board.
At a task level, pieces of paper and pencil.
If I need to move location when picking up where I left off, I'll email myself a reminder.
I would go for leaving a failing unit test.
Sticky Notes. As in, the application included in Windows since Vista, IIRC.
If it's really in the middle of something, I'll put a (compile-time) error on the line I left off.
Otherwise, a paper note on my desk, if it's not something that's tracked in Jira.
Emacs Desktop
With a failing unit test 😜