Why that one coworker got fired for no reason

Your manager calls you into a virtual meeting and, after wading through the requisite bullshit small talk, asks what you’ve been working on for the last month.

“Well I fixed that showstopper bug! And everyone agreed it had a big impact.”

“It looks like the fix was just one line of code.”

“Yeah but it took me two days to find that one line haha, you know how it goes.”

“I don’t. I went to business school.”

You’re sweating bullets now. You know this asshole already doesn’t like you, especially after last month’s town hall when you politely suggested we should have less bureaucracy instead of more.

“Well, I also designed our upcoming feature! That took a week!”

“I saw the UML diagram, it’s only 3 different boxes with arrows pointing at each other? How did that take a week?”

“Well I had to work with product on the requirements and then there was a lot of iteration with the team. You know how it goes haha.”

“I don’t. I went to business school.”

See where this is going? You need to be ready to prove it. Here’s how.

Know Prove your worth

I can’t believe I have to say this, but so many developers don’t get it. It doesn’t matter if Jane Doe from the Red Team can vouch that you worked closely with her. It doesn’t matter that your bug fix could have been published in Nature it was so transcendental. If you can’t prove you’re doing the work, you’re on the chopping block.

Why was that coworker fired for no reason? Because they weren’t doing anything! Or at least they couldn’t prove otherwise.

Your manager isn’t an idiot. Okay, well they very well may be, but the tools they use are not. They have tools that will suck up data from literally every possible source available. And these tools are getting better every year. Tools like Jellyfish, CodeClimate, Quantive, and if your organization is old and rich enough, plenty of homegrown stuff. If you’re unfortunate enough to live in the United States, they can legally install a keylogger on your laptop.

Are these tools measuring the “right” thing? It doesn’t matter! What matters is that your organization has standardized what it means to be “data-driven” with respect to performance management. Is there a qualitative aspect to performance review? Sure, but it plays a decreasingly important role. Your quantitative metrics are going to keep getting “flagged” to your boss if they’re not up to snuff regardless.

What’s a more realistic scenario here? Your manager stands up to their entire chain of command and HR and convinces them “this is all bullshit, MY developer is just a misunderstood polymath!” or that they give into the metrics and fire your ass for underperformance? Don’t bother answering, it was rhetorical. The principle of least effort already answered it (and in its honor I’ve linked the definition instead of copying it).

That means you have to game the system.

Work artefacts

Goodhart’s Law states:

Meaning that when value is assigned to a thing, then that thing will be optimized into oblivion. Like the time the French government tried to incentivize people to kill rats by offering a bounty on rat tails. People discovered that if you only cut the tail off a captured rat, it would continue breeding more rats whose tails you could harvest.

Don’t be so disillusioned to think that all metrics are bad. If management is measuring pull request (PR) throughput, is it really so bad that developers start pushing through smaller PRs? God forbid we end up delivering value faster with fewer defects, better testing, and more thorough peer review.

When your manager rolls up to you asking what you’ve accomplished, have your work artefacts ready:

Pull requests

The simplest and probably most widespread metric used to measure developers is how many pull requests they’re merging. This roughly corresponds to “Change lead time” for you poor sods who have been pounded over the head with DORA metrics.

Don’t jump the gun and dive headfirst into your next task without spending five minutes thinking about the order things can be done, otherwise you’ll hurt the metric instead of helping it. I know, I know, writing code is the fun part of the job, but if you don’t plan a little, then one thing leads to another and suddenly your pull request balloons into a two thousand line monstrosity. We’ve all been there, learn from it.

You’re already thinking,

That’s why we have peer review. If you’re sacrificing quality so that you can push more PRs through the pipeline, your colleagues should catch it and hold up the review. One of the reasons to incentivize smaller PRs is because reviewers statistically catch more defects this way.

If nobody is reviewing PRs with any kind of sincerity, you have bigger problems. Hell, these days you can utilize an AI code reviewer that’s auto-added to reviews so that you can at least get some feedback.

Outside of peer review, there are powerful tools for measuring the quality of the code you’re pushing, and if your organization were smart they’d be using them. Metrics like code coverage, cyclomatic complexity, cognitive complexity, and even rework can be tracked. Bugs added to your issue tracker will link back to your work items and/or pull requests.

And lastly, people be snitchin’! Your coworkers and management are gonna get pissed off if every single customer-facing incident is caused by you. Qualitative feedback matters most when everyone is sick of your shit.

Publish your notes

Remember that one line bug fix that took two days to do? Your single puny little PR for it is assigned the same value as that one the mouth breather in the cubicle next door merged, titled “Test: Assert that 1 == 1”.

You were already keeping notes while you debugged the thing, just put them somewhere that counts! Put them in the GitHub/GitLab issue discussion. Each time you have a new insight, a new theory, a new approach, or a new data point, add a comment into the discussion. This will bump up any measure of overall activity. This “activity measure” is triply important if you work remotely because otherwise your manager will start wondering if you are working two jobs because you go dark all the time. (Note: I don’t give a shit if you ARE working two jobs so long as you’re meeting or exceeding my expectations.)

Publishing your debug notes is good practice anyway. If a similar bug crops up for another developer down the line, your notes could drastically reduce the time to fix it. As a bonus for you introverts out there (everyone reading this), you can link your coworker to the discussion instead of actually having a conversation about it.

One last thing: this isn’t restricted to debugging. For feature development tasks, don’t be afraid to discuss all the different ways you thought about approaching the work before outlining what you settled on and why. Literally last week I reassigned a task to a coworker and I was glad that I had already spent the time elaborating my approach and any gotchas.

Promote TODOs to issues

Ditch your personal note-tacking apps like Obsidian or the tried-and-true plain text file when it comes to writing down things you want to do. Promote these to full-fledged issues tracked by your work tracking software (Azure DevOps, GitLab, or (shudders) Jira). Senior developers create work for themselves instead of being told what to do. Make it easy for your manager to check that box when they’re considering promotions.

Throw everything into revision control

Look, at the end of the day you need to be able to prove you were doing something other than googling meme templates to make jokes in your team channels, and anything that serves up immutable timestamps for that work is ideal.

Architecture work? Source control. Tools like Mermaid.JS or PlantUML fit nicely into git. Yes, merge your architectural diagrams into your source control. Have your architectural reviews in the same place code reviews happen.

If you’re being forced against your will to write design docs in e.g., Word (because you work at Microsoft), then the self-contained revision history will have to do. Your corporate overlords are probably sucking in that data anyway.

UI Work? Revision control. Now, I’m not a designer so I don’t know enough about UI mocking tools to say for sure how well they support the kind of revision control us developers are used to. I’m pretty sure it’s mostly dogshit though. Tools like Figma take care of their own “revision history” so that’ll have to suffice modulo any plugins that hack in something better. On the other hand, watch out for Adobe XD because it’s not enough to force you into paying $60 a month for Adobe Creative Cloud, they hate you so much that they’re also going to arbitrarily delete “old” revisions of your files because fuck you.

Closing thoughts

Your wall-of-text posts in Slack aren’t tracked. Okay, those are tracked, but by HR for compliance reasons in case y’all get sued. And HR is making damn sure that data is retained for the minimal amount of time according to law so that it can’t come up in discovery 10 years later.

If your manager can’t see it, it doesn’t exist when performance review time rolls around. That extra hour of lunch you took because you were staring off into space thinking about architecture? Didn’t happen. Your outside-of-work conversation at the bar that inevitably turned to work? The drunken ravings of a lunatic. That two hour pair programming session with the junior dev to get their stuff over the finish line? A big blank spot in your activity log.

If you spent so much time helping another dev, make sure that time gets tracked in a measurable way. Add comments to the issue or pull request as you go. Heck, co-assign the work if you’re really pulling some weight.

A rising tide lifts all boats, so definitely help your fellow devs. Just make sure that management knows it was you who lifted the tide.

Cover your ass

This post can be summarized as “cover your ass”. It’s okay to be humble when you’re talking about how you made varsity in high school. It’s foolish to be humble with managers about your performance.

When you start doing everything I’ve suggested, you’ll notice that your thoughts become better organized because they’re written down and not fighting for space in your head alongside sci-fi lore. You will delegate work easier because it’s already been prepped. You will solve bugs faster because previous bug fixes are well documented (and for the DORA bean counters out there, that is “Mean time to resolution”). And when your boss wants to squeeze in yet another feature, you can prove your plate is currently full.

Your project manager might even start making semi-accurate predications about what can be delivered over the next three months because you’re actually tracking your work.

Simply put, you will accidentally become a better developer by “gaming the system”.

Until next time.