How do you keep track of work tasks

This is the one thing I find Asana effective for. Another option might be to repurpose issue tracking software - after all, it's basically just a to-do database. I've also known people who use plain text files on a remote machine plus vim plus SSH.

But software is just a tool. What it sounds like you really need is a system for keeping all these balls in the air. Without a system, no software is going to solve the problem of failing to remember you need to follow up on things.

This type of work is something I find Getting Things Done very effective for. You don't have to rigidly implement everything the book prescribes, but it does offer a philosophy and a toolkit of processes that you can mix and match to keep your work organized.

Once you have a process, you can implement it in OneNote or index cards, or whatever the heck else feels ergonomic to you.

If I were doing consulting, I'd look into using JIRA Service Desk to interface with clients and using JIRA internally to track tickets (JIRA integrates with Service Desk). I'd manually enter any external communications into Service Desk as a way to both log and confirm the communication with clients. My favorite feature of Service Desk is that it provides a clear "status" so that participants know whose court the ball is in.

You may be talking about something else.. I'm a beginner (first job), but I tend to make use of comments and commit messages (this may be due to the fact I buy pens and notebooks in bulk and have a tendency to take notes).

Comments:

I write them so I can just do a git grep and have a lot of information. Read: they tend to follow a certain format.

TODOS are for code I write that I intend to add. Others will probably read them and might do them, or tell me not to do them because of a reason I wasn't aware of.

  # TODO: Refactor this so it doesn't make that many copies.
  #       Something along these lines:
  #       def foo(arg1, arg2, *, bar=None):
  #           ...
  #       This way we can do x, y, z. Profiling shows spam
  #       spends most of it time doing x instead of y.
  #       Investigate why. Maybe do it à la PEP 666.

However, I sometimes open a ticket, assign it to myself, add a proposed implementation off the top of my head in the ticket body, then just reference the ticket in the TODO not to clutter the code (the information is captured nonetheless).

I also have files "musing" and "refactoring": the first where I toy with things that, somehow, always manage to save the day when I need them. Custom data structures, utilities, tools to make things easier. I suck so I try really hard to make my code really easy to use and write code to be able to be as lazy as possible (and learn a few things doing it)

'refactoring' is when I don't want to mess with someone's code but I see a way of doing something I'm not certain is better and that portion is not a priority. I'll reference the file and the function and make it better. It almost always is because I have the luxury of perspective the person that implemented it first didn't have, whether that person is me in the past, or another human.

  # QUESTION: Why does foo instantiate CoolStuff with arg
  #           when bar does it too in yo.py

A question is useful in many cases: When the information is with someone else but I don't want to unplug from the code; I just capture that in a question and continue working on the code. I do a git grep periodically to see if my questions are answered (I might have gained more insights into a subject, or talked with another person, or just got some sleep. The questioning not being lost is what's important because I think code is just answering questions).

You can also append the person's name or something.

If I do something that's not obvious, I add comments on what I was trying to fix, how I fixed it, and why that way instead of another. This way a reader might get their answer. I add "# NOTE:" for emphasis.

If I do a temporary thing, I also use warnings so I can run and generate errors and prefix functions with _throwaway (this way I can git grep them).

Commit messages:

They tend to include what was changed and why (which issue/wart it fixed and why it was a wart/issue because is it really a bug or was it intended? and how it was fixed) plus the next steps I'm planning to do after that commit.

Goes like this:

  X feature is working now. Problem was that foo did xyz
  but didn't commit to the db and condition Y wasn't met
  yet. Change affects foo method in waw.py.

  Next steps: Implement Z feature and refactor W so it uses
  memoryview instead of making all those copies in z.py.

When I'm the only one working on the code, I go insane with comments, etc. When the code involves other people, I tend to have a branch where I have a lot of stuff, but will push a more mentally sane branch for others to use.

This allows me to:

- Have a set of questions I can ask and get answers to. If I'm talking with someone, I do a git grep and see if their name doesn't come up and ask them a question I wanted to ask them when I was doing x, y, or z.

- Know what the next steps are.

- Have co...