DEV Community: Vicenç García Altés

The Weekly Work Log: A 10-Minute Habit That Transforms Your Career

Vicenç García Altés — Mon, 09 Mar 2026 09:31:16 +0000

Every Friday at 4pm, close your laptop for a moment and ask yourself one question: What did I actually do this week?

Not what you were busy with. Not what meetings you attended. What did you accomplish?

If you can answer that question in specific, concrete terms, you are ahead of 90% of your peers. If you write it down, you are building the single most valuable career document you will ever own.

This is the weekly work log. It takes 10 minutes. It changes everything.

Why a weekly cadence matters

You might be thinking: "I already keep a brag document. Why do I need a weekly log too?"

Good question. A brag document is the curated highlight reel. It is the polished record of your biggest wins, the document you pull out when writing self-evaluations or preparing for promotion conversations.

A weekly work log is the raw material that feeds it.

The difference matters because of how memory works. On Monday, you can recall Friday's debugging session in vivid detail: the red herring in the logs, the moment you spotted the race condition, the fix that took three lines. By next month, that entire episode has compressed into "fixed a bug." By review season, it is gone entirely.

A weekly log captures the detail while it is fresh. A brag document curates the best of it later. One is the quarry, the other is the sculpture.

The 10-minute Friday ritual

Here is the exact process. It works whether you use a text file, a notes app, or a dedicated tool like BragDoc.

Step 1: Open your log. (30 seconds)

Whatever your system is, open it. The key is that it's always the same place. Not a random sticky note. Not a Slack message to yourself. A consistent, searchable location.

Step 2: Scan your week. (3 minutes)

Glance through your calendar, your pull requests, your Slack messages, your ticket board. You are not reading in depth. You are jogging your memory. What meetings led to decisions? What code shipped? What conversations mattered?

Step 3: Write 3 to 7 bullet points. (5 minutes)

For each item, write one to three sentences. Include what happened and why it mattered. If there is a number, include the number. If someone gave you feedback, quote them.

Step 4: Tag it. (1 minute)

Add a project name, a skill, or a category. This makes your log searchable later. When your manager asks "what have you done on the Platform project?", you want to filter, not scroll.

That is it. Ten minutes. The clock on your desk barely moves.

The template

Here is a real example of what a weekly work log entry looks like. This is for a single week:

"Week of Feb 17, 2026"

Shipped connection pooling to production. P95 latency dropped from 320ms to 125ms. [Platform, PostgreSQL]

Paired with Dev on his first API endpoint. He pushed to production on Thursday with no issues. [Mentoring, Leadership]

Reviewed and approved the RFC for the new notification system. Left 12 comments, mostly around error handling edge cases. [System Design]

Fixed flaky integration test that had been failing intermittently for 3 weeks. Root cause was a missing test database cleanup step. [Testing]

Led sprint planning for next cycle. Team committed to 34 points, which is 15% more than last sprint. [Process]

Five bullet points. Under 150 words. Took eight minutes to write.

Now imagine having 26 of these at the end of a half-year review cycle. That is not a blank text box anymore. That is a goldmine.

What to capture (and what to skip)

Always capture:

Things you shipped. Features, fixes, migrations, deployments. The tangible output of your work. Include numbers whenever possible: "reduced load time by 40%", "migrated 2.3M records", "handled 12 on-call incidents."
Decisions you influenced. Architecture proposals, RFC feedback, trade-off discussions. Even if you did not write the final doc, if your input shaped the outcome, log it.
People you helped. Mentoring, pairing, unblocking a colleague, onboarding a new hire. This work is invisible in git logs but highly visible to managers who know what to look for.
Feedback you received. When a colleague says "thanks, that code review caught a real bug" or your manager mentions your work in a team meeting, write it down verbatim. Third-party validation is the most credible evidence in any review.
Things you learned. New tools, new patterns, conferences, courses. Growth is a career signal, and logging it helps you articulate your trajectory.

Skip:

Routine meetings that led to no decisions
Tasks you started but did not meaningfully advance
Work someone else did (log your contribution, not the team's)

The filter is simple: if you would mention it to your manager in a 1:1, it belongs in the log. If you wouldn't, it probably doesn't.

From work log to brag document

The weekly log is raw material. Once a month, spend 15 minutes reviewing your last four entries and promoting the best items into your brag document. "Best" means:

It had measurable impact
It demonstrated a skill you want to be known for
It involved cross-team collaboration or leadership
Someone else endorsed or praised the work

This two-tier system means your brag document stays curated and compelling, while your weekly log stays comprehensive and low-effort. You never lose detail, and you never have to sift through noise when it is time to write a review.

If you want to see what a well-maintained brag document looks like in practice, check out this example profile on BragDoc.

Common objections

"I don't have time." You do. You spend more than 10 minutes per week deciding what to have for lunch. The issue is not time; it is priority. And once you see how much easier your next review is, the priority will be obvious.

**"My weeks are repetitive. There's nothing to log." **If this is genuinely true, that is a career signal worth paying attention to. But more likely, you are undervaluing your own work. The "routine" debugging session that saved the team a day of investigation is worth logging. The code review where you caught a security issue is worth logging. Stop waiting for dramatic moments.

"I'll just do it monthly." You will not remember enough. The difference between a weekly log and a monthly log is the difference between a photograph and a faded memory. Weekly captures texture and specificity. Monthly captures summaries and guesses.

"My company has its own tracking tools."Jira tracks tickets. GitHub tracks commits. Neither tracks impact, context, or the human side of your work. Your weekly log is the only place where "I debugged the outage at 2am and wrote the post-mortem that changed our alerting strategy" lives as a coherent story.

Start this Friday

You do not need to set up anything elaborate. Open a document right now and write this week's log. It will take you less time than it took to read this article.

And if you want a system that handles the tagging, the monthly curation, and the review generation for you, BragDoc does exactly that. Log your work, and when review season comes, the AI turns your entries into a polished self-assessment. No blank text boxes. No scrambling.

But the tool does not matter nearly as much as the habit. Start this Friday. Ten minutes. Your career will thank you.

Performance Review Self-Evaluation Examples for Software Engineers

Vicenç García Altés — Mon, 02 Mar 2026 10:38:51 +0000

Every six months, the same ritual happens across the tech industry. A calendar reminder pops up. A form opens. And thousands of engineers sit there, cursor blinking, trying to remember what they accomplished since the last review cycle.

The problem is not that you didn't do great work. The problem is that you didn't write it down when it happened, and now you're trying to reconstruct months of effort from memory, git logs, and Jira tickets.

This article will help you in two ways. First, we'll give you concrete self-evaluation examples you can adapt right now for whatever review cycle you're currently facing. Second, we'll show you the system that makes this entire exercise unnecessary going forward.

What makes a good self-evaluation?

Before we get to examples, let's talk about what separates a useful self-evaluation from a forgettable one.

Specificity beats generality. "I contributed to the project" tells your manager nothing. "I designed and implemented the caching layer that reduced API response times by 60%" tells a clear story. Your manager reads dozens of self-evaluations. The ones with concrete details stand out.

Quantify wherever possible. Numbers make impact tangible. Percentages, dollar amounts, time saved, users affected, tickets reduced. Not everything can be quantified, and that's fine. But when you have numbers, use them. They turn opinions into evidence.

Show the "so what." Every accomplishment should connect to something bigger. You didn't just write code. You improved reliability for customers. You unblocked a launch. You reduced operational costs. The connection between your work and the business outcome is what makes a self-evaluation compelling.

Be honest about challenges. The best self-evaluations acknowledge difficulties and describe how you worked through them. "This migration was more complex than initially scoped because of undocumented dependencies in the legacy system. I created a dependency map, coordinated with three teams to validate it, and we completed the migration with zero data loss." That sentence shows judgment, not just execution.

Examples by category

Technical delivery

"Designed and implemented the real-time notification system for the mobile app, serving 12,000 daily active users. The system processes an average of 45,000 events per day with 99.97% delivery reliability. I chose a WebSocket-based architecture over polling after benchmarking both approaches, which reduced server load by 40% compared to the original proposal."

"Led the migration of our authentication system from a custom JWT implementation to Auth0. The project took 6 weeks and affected every service in our platform (14 microservices). I wrote the migration plan, coordinated the rollout schedule with three teams, and handled the production cutover during a maintenance window. We had zero authentication-related incidents in the 30 days following the migration, compared to an average of 2.3 per month before."

"Identified and fixed a memory leak in our data processing pipeline that had been causing intermittent OOM crashes for three months. The root cause was an unbounded cache in the transformation layer. After deploying the fix, our pipeline uptime improved from 94% to 99.8%, and we eliminated the need for the manual restart procedure that operations had been running twice per week."

Collaboration and leadership

"Onboarded two new engineers to the payments team over Q3. I created a structured onboarding plan that included architecture walkthroughs, paired programming sessions on real tickets, and weekly check-ins for the first month. Both engineers were making independent contributions within three weeks, which was faster than our previous average of five weeks. I've since shared the onboarding template with other team leads."

"Facilitated the cross-team API design review for the new partner integration platform. This involved aligning engineering, product, and the partnerships team on a contract that would work for our three launch partners while remaining extensible. The review process I set up (RFC document, async feedback round, then a 90-minute decision meeting) is now being adopted by other teams for similar cross-functional decisions."

"Served as the primary on-call engineer for the checkout service during Q4, which is our highest-traffic quarter. I handled 7 incidents during my rotation, with a median time-to-resolution of 23 minutes. After noticing a recurring pattern in two of these incidents, I proposed and implemented an automated circuit breaker that has prevented the same failure mode from recurring."

Process improvement

"Reduced our CI pipeline runtime from 18 minutes to 7 minutes by parallelizing the test suite and introducing selective test execution based on changed files. This change saves the team approximately 22 hours of collective waiting time per week (based on an average of 40 pipeline runs per day across 8 engineers). The approach was documented in a team RFC and has been adopted by two other teams."

"Introduced structured post-mortems for production incidents. Before this, our incident reviews were informal and inconsistent. I created a template based on the blameless post-mortem format, facilitated the first three reviews to set the tone, and set up a shared archive so the whole engineering org can learn from past incidents. We've conducted 11 post-mortems since the process was introduced, and they've generated 34 action items, 28 of which have been completed."

Learning and growth

"Completed the AWS Solutions Architect certification in Q3. I applied the knowledge directly to our infrastructure review in October, where I identified three cost optimization opportunities that reduced our monthly AWS bill by $2,400 (about 15%). I also presented the key architectural patterns to the broader engineering team in a lunch-and-learn session that had 30 attendees."

"Led a team book club on "Designing Data-Intensive Applications" over Q3 and Q4. We covered one chapter per week with eight regular participants. Several design decisions in our Q4 planning were directly influenced by concepts from the book, including our approach to event sourcing for the audit log feature."

Common mistakes to avoid

Don't be vague. "Worked on various projects" or "helped the team deliver" are placeholders, not evaluations. If you can't be specific, it usually means you don't remember the details well enough. This is the core argument for keeping a running log of your work throughout the year.

Don't undersell. Engineers are particularly prone to this. "Just fixed some bugs" might actually mean "identified and resolved a class of race conditions that had been causing data corruption for enterprise customers." Describe what you did with the same level of detail you'd use if you were explaining it to a friend who doesn't work at your company.

Don't only list solo work. Many of the most valuable things you do involve other people. Mentoring, code reviews, design discussions, unblocking teammates, facilitating meetings. These contributions are real and they matter, especially at senior levels where influence and collaboration are explicit expectations.

Don't ignore what didn't go well. A self-evaluation that's 100% wins reads as either dishonest or lacking self-awareness. Pick one or two areas where things were difficult or where you're actively working to improve. Frame them constructively: what you learned, what you'd do differently, and what you're doing about it.

The system that makes this easy

Every example above has something in common. They include specific details, dates, numbers, and outcomes that are nearly impossible to reconstruct from memory after six months.

The engineers who write great self-evaluations aren't better writers. They're better note-takers. They have some kind of system, whether it's a text file, a notes app, or a purpose-built tool, where they jot down accomplishments as they happen.

The habit is simple. When you ship a feature, close a significant PR, resolve an incident, get positive feedback, or finish a project, you open your log and spend 30 seconds writing down what happened and why it mattered. That's it. When review season arrives, your self-evaluation is already 90% written. You just select the highlights and polish the language.

If you want a tool designed specifically for this workflow, with role-based organization, skill tagging, colleague endorsements, and one-click markdown export, take a look at BragDoc. It's built to make the logging habit as frictionless as possible so that your next self-evaluation writes itself.

What Is a Brag Document (And Why Every Developer Needs One)

Vicenç García Altés — Wed, 25 Feb 2026 10:18:30 +0000

Picture this: it's performance review season. Your manager asks you to summarize your accomplishments from the last six months. You open a blank text box and stare at it. You know you did good work. You shipped features. You fixed gnarly bugs. You unblocked your teammates at least a dozen times. But the details? Gone. Evaporated into the daily blur of standups and Slack threads.

So you write something vague, like "contributed to the payments redesign," and hope your manager remembers the rest.

They don't.

This scenario plays out in thousands of companies every review cycle. And it's the single biggest reason talented people get passed over for promotions they deserve.

The fix is embarrassingly simple: write things down as they happen.

That's a brag document.

A brag document is just a running log

A brag document (sometimes called a "hype doc" or "achievement log") is a personal record of your professional accomplishments. Every time you ship something, solve a problem, receive praise, or learn something hard, you write a quick note.

Not a polished essay. Not a LinkedIn post. Just a few sentences: what happened, why it mattered, and any concrete results.

Here's what a real entry might look like:

Migrated payment processing to Stripe Led the migration from our legacy payment provider to Stripe, reducing failed transaction rate from 4.2% to 0.3%. Coordinated with 3 teams over 6 weeks. Zero downtime during cutover.

That took 30 seconds to write. But six months from now, when you need to justify a promotion or update your resume, that entry is gold.

Why most people don't keep one (and why they should)

The concept is not new. Julia Evans wrote about brag documents back in 2019, and the idea has been circling engineering communities ever since. Yet most people still don't do it.

The reasons are predictable:

"I'll remember the important stuff." No, you won't. Research on memory shows we forget roughly 70% of new information within 24 hours. After six months, you're reconstructing, not remembering.
"My manager sees my work." Maybe. But your manager has 8 to 15 other reports, their own deliverables, and a dozen competing priorities. They physically cannot track everything you do.
"It feels like bragging." The name is unfortunate. This isn't about self-promotion. It's about self-documentation. Doctors keep patient records. Lawyers keep case files. You should keep a record of your professional output.

Five things a brag document does for your career

1. Performance reviews write themselves
This is the obvious one. When review time comes, you don't start from scratch. You open your brag document, scan the last quarter's entries, and pick the highlights. What used to be a dreaded two-hour exercise becomes a 20-minute copy-and-edit job.

2. Promotion cases get concrete
"I think I'm ready for senior engineer" is a feeling. "I led 3 cross-team projects, mentored 2 junior developers, reduced deploy time by 40%, and handled on-call for the highest-traffic service" is evidence. A brag document gives you the receipts.

3. You catch your own growth patterns
After a few months of entries, patterns emerge. Maybe you're drawn to infrastructure problems. Maybe you keep volunteering for cross-team coordination. Maybe your best work happens when you pair with designers. These patterns are career signals, and they tell you where to lean in.

4. You're always interview-ready
Job searching while employed is stressful enough without trying to remember specific accomplishments from two years ago. With a brag document, your resume bullets and STAR-method stories are pre-written. You just polish and submit.

5. You build confidence through evidence
Imposter syndrome feeds on vagueness. When you can scroll through months of concrete accomplishments, the "I'm not good enough" voice gets quieter. The evidence is right there.

How to actually maintain one

The biggest risk with a brag document is abandoning it after week two. Here's how to make it stick:

Write entries the same day. Don't batch. Don't plan to "catch up on Friday." When something happens, whether you deploy a feature, get positive feedback in a PR, or debug a production incident, open your brag doc and write 2-3 sentences. Right then. The fresher the memory, the better the detail.

Include impact, not just activity. "Worked on search" tells you nothing in six months. "Rewrote search indexing pipeline; query latency dropped from 800ms to 120ms, reducing support tickets by 35%" tells a story. Whenever possible, include numbers, timelines, and outcomes.

Don't filter. It's tempting to only log the "big" things. Resist that urge. The small wins add up and often reveal patterns you'd otherwise miss. Mentored a teammate through a tricky deploy? Write it down. Fixed a flaky test that had been annoying the team for weeks? Write it down.

Tag entries by role or project. As your career progresses, you'll want to slice your accomplishments by company, team, or project. Good categorization now saves painful archaeology later.

Review monthly. Set a 15-minute calendar reminder once a month. Scan your entries, fill in anything you forgot, and add context where it's thin. This small habit keeps your document honest and complete.

What goes in a brag document?

If you're not sure whether something is "worth" logging, it probably is. Here are categories to consider:

Features shipped: what you built, who it was for, what the outcome was
Bugs fixed: especially production incidents or long-standing issues
Technical decisions: architecture choices you drove, trade-offs you evaluated
Collaboration: cross-team projects, unblocking teammates, code reviews
Mentoring: onboarding new hires, pairing sessions, knowledge sharing
Process improvements: CI/CD changes, testing strategies, documentation
Learning: new technologies adopted, talks given, certifications earned
Feedback received: praise from peers, managers, or stakeholders (quote them directly)
Endorsements from others: when a colleague specifically vouches for your work

That last category is especially powerful. When someone else says "this person's work was excellent," it carries more weight than any self-assessment.

Start today, not Monday

The best time to start a brag document was when you started your current role. The second best time is right now. You don't need a fancy tool. A text file, a Google Doc, or a notes app all work. What matters is that you start.

But if you want something purpose-built, with role-based organization, colleague endorsements, markdown export for your resume, and a clean interface that makes logging painless, that's exactly what we built BragDoc to be.

Your future self, sitting in that next performance review, will thank you.