Your Weekly Work Log Is the Most Underrated Career Tool in Engineering

Most engineers spend zero time documenting what they actually did this week.

Not zero time on documentation - they write plenty of that. Design docs, runbooks, post-mortems, inline comments. They document everything except the thing that directly affects their career.

That gap costs them. I saw it play out hundreds of times at Facebook.

The Pattern I Kept Seeing

When promotion season came around, the engineers who struggled most were rarely the ones who had done the least. They were the ones who couldn’t reconstruct what they’d done.

Twelve months of work compressed into three weeks of panicked calendar-diving. “I know I did something with the auth service in Q2… and there was that outage I led the response on… when was that again?” They’d piece together a promotion packet that was technically accurate but strategically thin - missing the context, the scope, the cross-team impact that actually justified the next level.

The engineers who sailed through promotion cycles did something different. They kept notes. Not elaborate notes. Not a second job’s worth of documentation. Just a consistent record: what they worked on, what got unblocked, what shipped, what failed and what they learned from it.

When it came time to write their promotion packet, they weren’t reconstructing their year. They were editing a document they’d already been building.

What a Weekly Work Log Actually Is

Not a timesheet. Not a project tracker. Not a status update for your manager.

A weekly work log is a private document you write for yourself, in your own voice, that captures what you actually did and why it mattered. Five minutes on Friday afternoon. Bullet points are fine. Nobody sees it unless you decide to share it.

What goes in it:

What shipped or moved forward. Not “worked on feature X” - that’s a timesheet entry. What actually changed because you were working on it? “Merged the rate limiting changes, unblocked the payments team who had been waiting two weeks on this.” That’s the difference.

What you learned. The tricky bug you finally understood. The pattern you noticed across three different incidents. The conversation with a senior engineer that shifted how you think about distributed consistency. These are the things you’ll forget by next quarter that are actually evidence of growth.

What you influenced that you didn’t own. Engineering impact above senior level is mostly indirect. You reviewed a design and pushed back on an approach that would have caused problems six months later. You helped a junior engineer think through a problem rather than just fixing it for them. You flagged a dependency risk in a planning meeting that nobody else had caught. None of this shows up in your commits. It disappears completely if you don’t record it.

What slowed you down. Not as a complaint log. As a forcing function for thinking about whether you’re operating efficiently, whether there are systemic problems worth raising, whether you’re getting blocked by the same things repeatedly.

Why This Matters More Than Most Career Advice

The standard career advice is “make sure your manager knows what you’re doing.” That’s not wrong. But it misses the real problem.

Your manager is managing multiple people, attending meetings you’re not in, dealing with their own priorities. They have a general sense of what you’re working on. They do not have a detailed picture of your individual contributions - especially the ones that didn’t result in something they can directly observe.

When your manager writes their assessment of your performance, they’re working from incomplete information. If you’ve been keeping a work log, you can fill in that picture with specifics when it matters: in your weekly 1:1, in your self-review, in conversations about promotion timing.

This isn’t about gaming performance reviews. It’s about not leaving a gap that gets filled with someone else’s narrative.

At Facebook, the engineers who advanced quickly were almost always the ones who could articulate their own impact clearly and specifically. Not arrogantly - specifically. “I owned the migration for three services, unblocked two teams who were waiting on it, and the work shipped two weeks ahead of schedule” is not bragging. It’s useful information for a manager who’s trying to make a case for your promotion to a committee that doesn’t know you.

If you can’t give them that information, they have to make the case without it. Sometimes they succeed. More often, the promotion gets deferred for “one more data cycle.”

How to Build the Habit

The engineers I know who do this well treat it like a code review - something you do consistently, not when you feel inspired.

Friday afternoon, last thing before you close your laptop. Ten minutes maximum. Write it somewhere you’ll actually look at it: a private Notion page, a Google Doc, a plain text file. The format doesn’t matter. The consistency does.

A few prompts that help when you’re staring at a blank page:

• What would I tell a colleague if they asked what I got done this week?
• What decision did I make or influence that I wouldn’t want forgotten?
• What’s something I understand now that I didn’t understand on Monday?
• Who did I help, and how?

You don’t need to answer all four every week. Any one of them usually surfaces something worth capturing.

The Long Game

Six months of consistent work logs give you something most engineers don’t have: a real-time record of your own growth.

When self-review season arrives, you’re not trying to remember what you did. You’re reading back through a document that already has the raw material. The patterns become obvious. The impact accumulates on the page. The narrative writes itself.

More importantly, you start to see gaps. If you’ve been writing “worked on feature X” for five straight weeks without anything in the influence or learning buckets, that’s useful signal. You’re heads-down on execution but not growing. That’s fine for a sprint. It’s not fine for a year if you’re targeting a promotion.

The work log becomes a diagnostic tool as much as a record. It shows you where your time actually went versus where you think it went.

The engineers who advance consistently aren’t necessarily doing more work than everyone else. They’re doing better work and they know specifically what it is. That second part doesn’t happen automatically. You have to build it deliberately.

A text file and ten minutes on Friday is a pretty low bar for a tool that directly affects your career trajectory.

If your resume is the document that gets you the interview, your work log is the document that earns the promotion. One of these is getting significantly less attention than it deserves.

If you’re working on translating what’s in that work log into a resume that actually communicates your impact, the Software Engineer’s Resume System walks through exactly how to do that.