DEV Community

Cover image for A way to not lose track of what you've done at work

Posted on • Originally published at

A way to not lose track of what you've done at work

The problem

How many times did you forget what did you do last Friday at work when you're beginning to work on Monday? Or, even yesterday?
"I was solving a bug and I figured out that the problem is in the database. Or, maybe not exactly. I need to do this again"

Summary: take notes on what have you discovered at work while you were working on a problem and what to do next, write any details that can be important to you tomorrow.


Forgetting anything important

I forget the details often. Sometimes I need to draw diagrams to connect all things I know about the system and how they are connected. Sometimes the issue I try to solve isn't so intricate, then I don't need to do all this stuff.
The problem here is that developers can't keep all the facets and details of a system they work on. When they execute a feature or solve a bug, many of them need first to understand how to do this step by step. Then, a working day ends or you took a break, and all the things you sure you remembered are vague now.

In such situations, I needed to gather what I've done before, what I remember now. The saddest part is I should understand again what I've known before the break. E.g. what function is called when you press the button, why this matters at all; why the data is sent to the service X, as it doesn't need it, and so on.


Take notes!

The way I try to do this now is to compose notes on anything important I've discovered while working on a problem. Of course, I don't need to write detailed documentation on what I'm doing and what I was doing. Just the details related to the problem and such that could be valuable to me when I'll be working on the issue tomorrow or after a vacation.

The things I include in the notes:

  • What I have discovered. E.g. "the simulate_universe function is being called 4 times in a row and then the app crashes. There is not enough memory to execute the predecessor function 'before_simulate' sometimes".
  • What things should I do next(TODOs). E.g. "understand where the memory leak is; figure out with what error the app crashes"
  • Additional information. E.g. "John Doe knows how to debug the problem, write to him"

The other plus of this method is that when you should transfer the thing you work on to another person. You can share the notes and I think it's simpler than trying to recall the details and then writing/speaking this information to your colleague.

What are your methods? Please share in the comments.

Subscribe to my Telegram channel

Top comments (0)