Ask HN: What do you use to track your tasks and accomplishments at work? | Hacker News Reader

Ask HN: What do you use to track your tasks and accomplishments at work?

6 points600frogs29 comments

Currently I'm using one text doc per day, titled with the date. Today's doc has all my outstanding tasks, and listed below is everything I've done for the day. As the day progresses, I move items from the TODO section to the DONE section, then at the end of the day I'll move all the leftover TODO items to tomorrow's doc, leaving only the DONE section for each day.

It works okay-ish, but it's a bit arduous, and the tracking isn't great: I can find out what I was doing on a given date, but that's not particularly useful information.

What systems does HN use? I'm sure my system can be improved tenfold, I'm open to any suggestions.

View on HN

I like low tech, but I also like agility.

Every morning I write a list of 5 things I want to accomplish in an index card. Any appointments I have are also written down. This allows me to easily figure out what I need to and what I have to do.

5 is a good number of tasks for me as long as some tasks take 30 minutes or less. This is not only work tasks, but life tasks as well, it's kind of what I feel I need to accomplish today.

Then I have a day.md file open for work. I prefer markdown because it's easy to render anywhere, email, wiki pages, gitlab etc. My day.md is a single file that expands for a year. Each year I start a new one.

day.md has all my meeting notes and all work projects worked on. The reason why I prefer an electronic document for this is speed. It's fast to write things in, it's a single place so I don't have to figure out where I put my notes or whatever. Most importantly being a file I can search for things, re-arrange projects, current project being worked on is always on top.

This helps with my planning as well. I feel that a lot of times as a dev we tend to get overwhelmed with all the things we have to do to solve a project. So I break things down, usually it starts abstract and as I get a better understanding it becomes more in depth.

My index card gets ripped up at the end of the day. It makes me feel good for completing all the tasks on it. :)

Agreed on low-tech, low-tech can be great! My personal calendar is just a huge whiteboard I scribble on, and redraw at the end of every month. Physically crossing out tasks/appointments is rewarding in the way that a phone-tap or CTRL-X CTRL-V can never be.

That being said - do you not find the duplication of tasks from the index card to day.md to be annoying/unnecessary? I know if I was rewriting the tasks from the index card to the .md file every day I'd get irritated and eventually just resort to the .md file, but maybe I need to learn to be a little more patient :)

Perhaps I was not clear. My day.md file does not contain the 5 tasks I write in my index card.

For a real example, my index card says "Abstraction Tweaks".

My day.md looks like this:

    # <story-id> - SPIKE: Investigate the best way to abstract common Jenkinsfiles
    * Look at current Jenkinsfile types
    * Identify commonalities
    * If workflows had to change, what would that look like in a code change
    * Write a less abstract version, how does that change future code change approach and readability
    * Test
    * Write a more abstract version, how does that change future code change approach and readability
    * Test
    * How easy is it to read current code vs your new abstraction

So my index card is more like a pointer to the day.md story I am working on. Right now, perhaps it's obvious, I just started working this story. My breakdown of the work to be done is rather generic. As I start working on the first part "Look at current Jenkinsfile types", I will see the types, and then update that section with the different types as a note. This help me downstream when I am ready to make changes, I can make sure my abstractions in this case would work for all cases.

Here is an example of a done task, including my thoughts, verbatim from my day.md. It's the worst case scenario when I get stuck. By convention, "" means action, ">" means thought. Markdown renders it nicely.

    * DONE Test `withEnv` removal - it fails
       * If it breaks move it into the rhel7-gradle Dockerfile
       * Test change - it fails
       * Test w/o gradle opts - success
       * Test w/o gradle user home - failure
       * Test w/o gradle home - success
       > how is this possible? Empty gradle user home or defined works, removing it fails...
       * Test no GRADLE_USER_HOME in Dockerfile ENV withEnv GRADLE_USER_HOME= - success
       * Test no GRADLE_USER_HOME in Dockerfile ENV no withEnv GRADLE_USER_HOME= - failure
       * Test GRADLE_USER_HOME in Dockerfile ENV no withEnv GRADLE_USER_HOME= - failure...container env points to /app/jenkins/.gradle...w/ Dockerfile ENV defined... 
       * Test GRADLE_USER_HOME in Dockerfile ENV withEnv GRADLE_USER_HOME= - success...container env points to /home/gradle/.gradle which matches Dockerfile
       > Looks like the witEnv is shielding the ENV Dockefile definition from an override, where is it coming from?
       > Still need to test withEnv only surrounding gradleWorkflow, I don't think the docker workflow needs it
       * Jenkins Globals overwrite ENV variables. Removed them from test and everything works

Thanks for the concrete example, that's super interesting. Do you find this level of granularity helps, both short-term and long-term? I tend to find in a busy day that I've completely neglected to update my DONE list, and my suspicion is that if I stopped every 20 mins to update it I'd break my flow.

Long-term, I can see once in a blue moon going back to the exact thought process during an issue would be invaluable if something similar crops up, but 99 times out of 100 is this not over-documenting? I'm not trying to criticise here, I want to understand what value you get from it.

I am a firm believer that different personality types work differently. I can only speak about myself here, for me having a list of 5 priorities helps me immensely. It works so well that I do it on non work days as well. I find it easier to plan. Also I tend to gauge time wrong, I always estimate time on best case scenarios, so having 5 things that take an hour or less means I have a full day in reality.

As of the day.md stuff. If I am super busy doing non code work, I will neglect to update it. However that's fine, because I don't need a lot of structure for meetings etc.

If I am writing code and neglect my day.md because I am in the zone, I don't mind at all. I rather stay in the zone than make up tasks to complete.

Where day.md signs is when I am in overwhelm or I am unmotivated...which usually comes from overwhelm and I don't know it, or the thing I am working on is just plain boring.

There are two types of overwhelm. Strategic overwhelm, aka I don't know what I need to do, what exactly I am solving? The other time is implementation overwhelm, aka there are like 50 things I need to account for, I know what I need to solve but there are so many things I need to consider for a good solution.

Both of these lead to me not wanting to write code. So instead I will just create an outline of a plan. By doing that I can figure out what I need to solve, or ping someone to figure out what the story is meant to solve. However it also allows my brain to go to brainstorm mode and just think about what the implications of the change are. So out of the 50 things I might have to care about, I might realize it's really 10 things. Now at least I don't to do that mental work later. While writing code I might realize I need to consider 2 more side effects, or perhaps realize that it wasn't 10 dependencies but 7, for whatever reason. The cool thing is though, if I write it down I have something to work with. Mental pointers of what I need to consider.

If I am unmotivated to write code, day.md helps in a similar fashion. It allows me to do work, without writing code. Then I will try to trick myself, hey, this step is like 5 minutes, do that so you can at least make some progress today....and boom 2 hours later I have done the thing. I know I am tricking myself, but I also know that I get paid to write code, so tricks are OK. If however I do the thing for 5 minutes and don't feel like it, I will task switch. Sometimes just going for a walk, grabbing a cup of coffee is all you need.

As a continuation of this actual thing I am working on, here is my actual update for the story

* Look at current Jenkinsfile types > Currently our workflows are abstract because we don't want to change Jenkinsfiles per application > If we have remote Jenkinsfiles, do we still need the same level of abstraction > They will act more like a catalog, where people select the Jenkinsfile they want > This means from the catalog side you need to be able to see what each Jenkinsfile offers, so visibility is good > It also means code complexity will confuse the hell out of people * DONE Identify commonalities * DONE If workflows had to change, what would that look like in a code change * idea #1: add | add a new line, modify | no change needed * idea #2: add | no change, modify | no change needed * idea #3: add | no change, modify | no change needed * DONE Write a less abstract version, how does that change future code change approach and readability * Test * DONE Write a more abstract version, how does that change future code change approach and readability * Test * How easy is it to read current code vs your new abstraction

Note that I skipped around, and I didn't test. It's because ultimately I realized I don't have to test the code just yet, because I care about readability, addition and modification of code. I know I can get the new code to work because it's abstracting existing code that I am intimately familiar with.

Now, I am going to be busy with meetings for 2 hours, however when I get back I can quickly figure out what my thoughts were, that I have 3 main ideas, which are written in mostly real code and I have to figure out which one of my three ideas are worth it. I thought about add / modify, but my concern is readability. Specifically developers understanding what each steps are since abstraction can obfuscate things...but good method / class names make it easier to understand ...

I don't use anything separate from what we use for tracking the dev work. In the current job, Jira. I can report on what I did at the end of the year (for performance reviews) by querying the data, and check old release notes for a delivered feature list.

Outside of that, I have no need for a permanent list of my "done" items. I'm not saying it is a bad idea, I'm just not sure what goal is behind it. I'm genuinely curious why one would keep such a thing?

In an ideal world using whatever ticketing system your company uses would be great, but I find in practice a significant amount of the work I do is untracked - attending/scheduling meetings, catching up with X about Y, etc. In theory all work should be trackable, but I find it doesn't make sense to keep these smaller, "personal" tasks logged company-wide.

RE: keeping the DONE list, for me it's not about knowing exactly what I did at 11am on date XX/YY, but it's more about proving both to myself and the company (if asked) what I've provided/achieved, and to hopefully be able to better understand my rate of work (this one is still a WIP - I haven't done any analysis yet and doubt I ever will, but it's nice to know I could!)

I like trello a lot for tasks but I'm not using a paid plan so nothing fancy like automatic tasks or integrations but it does the work. It must be useful in team, as sharing txt docs is not practical. I was sending myself emails of things to do in the past

I used Trello for a period of time, and the manoeuvrability (if that's the right word) of it was great - shuffling priorities around in a list, the satisfaction of dragging to a DONE column - so for tracking current tasks it was great. However, it was unusable for tracking and saving previously done tasks - they'd just pile up in a big DONE column, and eventually I'd have to archive it, losing all tracking. Have you solved this particular issue, or does accomplishment tracking not rank high in your priorities?

That's what changelogs are for - keep a polished changelog for important stakeholders, and a rough one for team mates.

I do the same for building in public - changelog on my website, and a super long twitter thread (https://twitter.com/RozenMD/status/1364881512500404224?s=20 for example)

I love the idea of a changelog, but that only works well if you're working on a single system for a long period of time - the nature of my work means I'm hopping between systems fairly frequently, so a changelog doesn't quite fit the bill for me. Sounds ideal for your work though - and I really appreciate that twitter thread, great work!

Do you have any suggestions for Column headings? I've tried one column for each day of the week. Now I'm using things like 'Priority', 'Batch', 'Backlog', etc. I don't have a satisfying solution for this though.

Textfiles, undated. Normally 1 master todo list, and 1 DONE file. Every time I check an item off, I go through the following ritual: put DONE before the todo item. Save the file. Cut that todo item out and put it in the DONE file. Save both files. It's a great feeling. This is my way of celebrating each win. For larger wins, and major todos I'll do some other form of celebrating.

I'll also reorganize and reorder the todo list as priorities change. I indent sub todos under their logical parent task.

Sometimes I'll break whole sections of todos out into a smaller %task_name%.todo file when they're no longer critical and can be somehow grouped together.

Interesting - it sounds fairly similar in terms of cutting plaintext TODOs into a DONE list, but with greater visibility on a macro scale. Do you never date anything in the DONE list though? I might have a hard time remembering when I achieved big milestone X, or how long problem Y took to solve, which is part of why I want to track my work.

I don't date it but the files are in the repo I'm working on, so they're automatically versioned and dated. But I never go back and check them. After I've solved a problem I don't care.

But when people ask me, "Describe a bug you recently solved" I can't remember. So maybe I could have a "greatest hits" file and copy some of those todos into there.

Sometimes I also put the todos into GitHub issues, either as separate issues, or as check lists in a single issue.

And sometimes for multiple projects and tasks across work, life, etc, I'll make a todo list in my Gmail, then leave it at the top of my inbox, and reply with DONE %todo desc% when I complete one.

I guess another idea I came up with now is have a master todo repo, that only contains todo lists, and can organize them by project, etc. Then all todos and dones are in one place and in a github repo. But I need email as well sometimes. Meh...;P ;) xx

Ah if the files are in version control you're golden, but for personal tracking using a git repo seems a bit overkill and not frictionless enough. The email idea isn't bad though, simple and effective!

Oh, I didn't mean it for personal tracking. Just if I had a lot of projects running, put all todos in a github repo, and I wouldn't put personal in there, because it would feel too "worky". I haven't really done that centralized todo repo. Just an idea for you. Email is good for personal todos for me. Or just a notebook...pen and paper :p :) xx

Oh, you'll love https://orgmode.org/ then.

Interesting. I've always been a vim person (well since I discovered it when using an Ubuntu laptop back in 2011 after being a notepad person, before that an edit.com person). I've always regarded emacs users with a sort half-fearful half-snobbish "wtf". I'm a little scared I can't be both a vim person and an emacs person. Like I'd be betrayin' something or somebody or other ;p ;) xx

Why do you want track your tasks and accomplishments? Do you do this for yourself or for somebody else (e.g. a manager)?

How do you measure accomplishments and results? Those often are different from the tasks required to achieve them.

I use Remember the Milk for keeping track of personal todos that need to be done by a specific date. When I collaborate with others, it's whatever tool fits the work and the workflow. This could mean GitHub Issues, Jira, or Trello, for example.

Otherwise, I use Bear for noting down particular achievements I consider, well, noteworthy.

RE: Why track, I think it's for both:

* I want to be able point to past achievements and see the value I'm adding (both for personal well-being and also CV writing/interviewing)

* I want to be able to see what I've done in a day/week/month/quarter to see if I'm performing well and delivering what both I and (potentially) my manager expects.

* If asked why X hasn't been done yet, I want something concrete to point to so I can provide my reason, without fumbling around for excuses or reasons I can't remember.

Is there any reason you chose RTM specifically? I happen to use Bear for my daily notes, but I'm wondering if perhaps just a to-do tracker (Kanban, RTM, whatever) and a single achievements.md file might be better.

I've been using RTM for a long time. At the time, at least, it was one of the best todo apps around.

It still meets my requirements. I've tightly integrated it into my processes and automations (via Zapier), e.g. when it comes to automatically creating tasks for things like payment reminders for outgoing invoices.

> Currently I'm using one text doc per day, titled with the date.

Same! In addition, twice a month I go through the daily logs and pull out highlights of accomplishments. Those "highlights" I use to write my self-evaluation during my performance review (to list what I accomplished since the last review).

From reading the other comments here, I have to say I think a single file may be easier to work with than the one-file-a-day we're currently using. For example, it'd be much easier to skim through a single file for the month/year/whatever and pick out the highlights than going through each file individually.

Anyway, love the highlights idea, think I'll be pinching that!

Understood. I'm glad you like my "highlights" routine. Makes me happy to hear my comment was useful. I've gotten a lot out of HN over the years, it's good to be able to give something back. :)

Onenote, I use a somewhat similar process but with Onenote it is easier to access a specific section, search is great, you can use better basic formatting and you can add and link to notes from your TODO

Pen and pad of paper

I'm in this camp (plus whiteboard).

<shameless plug> I then use https://sharetheboard.com to share my handwritten notes online (in real time), when needed.

The key, for me, is having something deliberately physical to counterbalance the laptop. The other key characteristic is temporariness - the ability to toss the paper or wipe the board.

For me personality matters a lot. I initially tried to adjust to multiple tools now I am adjusting tools to my personality.

*Mental shift*:

1. I shifted from deterministic to probabilistic. Being deterministic meant I had to do these tasks. If I didn't, I felt bad about it. Being probabilistic meant that there is a high chance that I would do these tasks but if I didn't that's okay. Probability doesn't account for outliers.

2. I started using my tool as more of a *reminder* as compared to a *guide*. My world is too chaotic sometimes, as I have to attend online zoom meetings, solve bugs and guide junior developers etc. My priorities would change from morning till evening. So, I decided not let a rigid framework control me but let the tool remind me that hey there is a task you jotted down to work on - do you have time to work on it?. I also realized that some tasks dry up or become irrelevant with time as universe take care of themselves.

3. I started planning my weeks before my days. I realized that at a macro level, I can't control my day but I can control my week. So, I make a priority list of what to be achieved at end of this week(abstract goals). Each week is a different page or note in my tool. I do reflective thinking after week end as on what I was able to achieve, what new things came on my plate, what came in between etc. This helped me in marking down my accomplishments.

4. I plan on day level as well but I don't keep admiring my tracker. I realized that after thinking through what tasks need to be done in the morning after looking at my tool planner, I can continue working on them. I mark ticks at the end of day.

5. I jot down bugs solved or programming or business wisdom achieved in the entire day in my notes as well. This helps me to recall easily in case someone asked me - what did you do on that day or week.

*Framework*:

1. After a lot of trial and error, I ended up with a modified version of Eisenhower matrix. It generally consists of four quadrants:

    - Urgent and Important
    - Urgent but not Important
    - Not Urgent but Important
    - Not Urgent Not Important

2. However, I ended up modifying it. I replaced word Important with impactful and added subcategories of simple, medium and hard under each quadrant as follows:

    - Urgent and Impactful
      - Simple
      - Medium
      - Hard

3. I keep different todo list for different projects and assign priority to projects. I ask myself the following: If someone put a gun on my head and ask me to choose one project priority-wise which one would I choose. Then, choose the second project and on. Of course, I prioritize Urgent and Impactful ones across all projects.

*Choice of tool*:

1. I used google calendar, keep, one note etc. Now, I have finally settled on Evernote. Sometimes, I get urges to switch to Notion or Trello as well but Evernote is working for me now.

PS: I derive a lot of inspiration from *My Effectiveness* app. You can have a look at it as well: <https://play.google.com/store/apps/details?id=com.andtek.sev...>

Reply on news.ycombinator.com