Eliminate 'Where Did the Time Go?': Evidence-Based Time Tracking with WakaTime

"I'll finish this feature implementation in about 3 days."

You declared this and started working, but in reality, it took 5 days. Or conversely, you thought you had included a buffer in your estimate, but time passed without you even knowing where it went.

I believe every engineer has experienced this.

The "man-hour estimation" we usually do often relies on a "gut feeling" based on past empirical rules.

But is that gut feeling really correct?

In this article, I will introduce WakaTime, which automatically measures programming activity just by installing it in your editor, not just as a logging tool but as a tool to update your self-awareness as an engineer.

To those of us who forget to press the stopwatch

Many people have probably tried time-tracking tools like Toggl to find out how they spend their time.

However, the reason many fail is clear.

"It's a hassle to press a button at the start and end of every task."

"Hours pass by after forgetting to press it, and then I enter it haphazardly later, making the data meaningless."

This doesn't work. Development work is more fluid. You look things up while coding, check specifications on Slack, and rebuild your local environment.

It's impossible to manually record all these seamless transitions.

WakaTime's greatest strength is that the measurement cost is zero.

By simply installing a plugin in editors like VS Code, JetBrains IDEs, or Vim, it automatically detects and records "the time you are actually typing on the keyboard" and "the time a file is active."

Time spent watching YouTube in a browser is not counted.

Only "pure time spent facing the code" is visualized.

Being confronted with your skills through data

After using WakaTime for a while, you will be confronted with facts that are brutally accurate on your dashboard.

Language and Project Ratio

A pie chart will show how much time you spent on which language in which project.

Facts will come to light, such as, "I intended to work on the main feature implementation (Go) this week, but in reality, I spent 40% of my time on configuration files (YAML) and minor frontend fixes (TypeScript)."

This is a discrepancy that you cannot notice through "intuition" alone.

Granularity at the File Level

What I personally find most valuable is tracking at the file level.
The time spent editing specific files like UserController.ts or styles.css is recorded down to the second.

This allows you to identify "which file (feature) was the rabbit hole."

If you find that a specific implementation is taking a long time, it might not just be that you are working slowly; it could be a sign that the class design is too complex, causing maintainability to drop.

It can also serve as an indicator for prioritizing refactoring.

"Man-hour Estimation" Becomes "Prediction"

The biggest advantage of continuing to use WakaTime is the improvement in estimation accuracy.

For example, suppose you are implementing an API for a new admin panel.

Where you previously might have answered, "Well, about 2 days," looking at WakaTime data changes that.

"In the previous similar task, the implementation itself took 6 hours, but it took a total of 12 hours including test code and back-and-forth for specification confirmation.

Since this time is of a similar scale, I should secure 2.5 days including a buffer."

In this way, you will be able to provide numbers with a solid basis.

You can explain to clients or PMs "why that time is necessary" as data based on actual results rather than a lack of ability, making it easier to avoid unrealistic deadlines.

Detecting Signs of Burnout

Engineers lose track of time when they concentrate, but their performance definitely declines.

WakaTime visualizes daily coding time in graphs, which is also useful for understanding your own limit line. Simply knowing your tendencies, such as "If my daily coding time exceeds 6 hours, my performance drops significantly the next day," helps you pace yourself better in long-term projects.

It is also effective from the perspective of maintaining motivation. By displaying your WakaTime status on your GitHub profile, your achievements are visualized as "this is how much I've built up," encouraging you to continue learning and developing.

Plans and Hurdles to Adoption

Basically, the Free plan functions well enough.


https://wakatime.com/pricing

Security and Privacy Concerns

When using it for work, there may be concerns about whether the code content is being sent.

What WakaTime sends to the server is only metadata such as "filename, project name, language, editor, and timestamp," and the contents of the source code are not sent.

If you are still concerned about project names being exposed externally, you can use a .[WakaTime](https://wakatime.com/)-project file to map project names to aliases, or exclude specific files and folders just like with .gitignore. Please configure these settings in accordance with your team's security policy.

Installation Procedure

The procedure is very simple.

https://wakatime.com/plugins

1. Create an account on the official website
2. Copy the API Key (Secret Key) from Settings
3. Search for and install "WakaTime" in your editor's extensions
4. Enter the API Key when restarting the editor or via the command palette, etc.

With just this, recording will start from that moment.
(In some cases, depending on the IDE or editor, setup is completed simply by logging in)

Conclusion

Time cannot be managed. A day is 24 hours for everyone, and past time does not return.

What we can manage is not "time," but "our own actions."

WakaTime reflects your actions as an engineer like a mirror.

Whether you look in that mirror and tidy your hair or leave it as it is, is up to you.

However, without looking in the mirror, there is no way to know what you look like while developing.

First, why not start by recording how you spend your time for two weeks?




The hints for growth should be hidden within the gap between the "ideal engineer image" you imagined and the "actual logs."