Join them if you can; dumb down your work and focus on predictable things rather than interesting work. Try to move closer to a profit center instead of a cost center because you'll get proof in the pudding there. And start quietly sending out resumes.

If you have a good manager who understands your contribution and can deal with the politics and constant demands for progress reports from do-nothing middle managers who need to send progress reports to their managers then you can probably do well until they get pushed out.

She should try, at the very least. Otherwise you have a bad manager. Your manager's job is to look out for what's best for the team, not to answer to a chain of command. This isn't the military.

If any employee, at any level, can't have a constructive conversation with the level above about what the level above has gotten wrong, you have a busted company culture.

Remember, you, the IC, are supposed to be the expert at your programming job. Your manager doesn't have that expertise, but she is supposed to be the expert at understanding what you're up to. Her manager doesn't have that expertise, so the second line manager should depend on your manager for that information, rather than dictate down manifestly inadequate productivity measures.

Like, I just want to solve problems with code, I hate that I also have to constantly advertise how smart and useful I am because managers are so myopic that they can't figure out if I'm valuable.

It brings out the worst in people; you get people holding meetings about stuff that could be summarized in an email in order to give the illusion of working hard. Pages and pages of documents that will never be read are created because if you don't create them then it's hard to say you were doing stuff. Hundreds of tickets pile up in Jira that will never get done because you need to give the appearance that you're actively important in the improvement of the product(s).

I get it, it's the world we live in, but I don't have to like it.

The companies I've worked for spend a lot of time recruiting talent. If a manager wanted to can someone because they didn't know that fixing bugs takes time, it would be the manager in front of a more senior manager demanding they explain their logic. Also, if you've managed programmers or SW projects for any amount of time, you'd understand why things take time.

Most folks I've seen get terminated is because the company is shrinking, or they are not performing or they are a jerk and/or violating company policies.

My thoughts are do the best work you can, be nice to others and you'll be fine as long as the company is making money. Don't worry about 'metrics', people generally know who's worth keeping based on more than that alone.

"If you know nothing of what they are doing, you suspect them of doing nothing".

I've used this sentence to catch myself over the years where I've been quick to judge someone as doing nothing at their job or day-to-day, and then used it as motivation to (if possible) learn about what their days actually look like. I'm almost always finding out I just didn't know enough about what they did.

As the article points out, this goes the other way too. It doesn't matter how good you are at your job if nobody at a decision making level understands what you are doing.

I thought I was doing pretty good on PR reviews. I do one or two a day. I read the description, sometimes more than once. I read through the practical testing steps. I follow them, sometimes with a lot of setup required. I really make sure it does what it's supposed to do. I read the code, line by line. Sometimes before I do the practical testing, sometimes after. But I read through the code, several times. I don't know how you wouldn't. Functions are calling other functions I haven't gotten to yet. So I read through the code multiple times. I don't just try to understand what it does, but why it does what it does. Is there a better way? Is this going to change or impact something else it should or shouldn't? A good code review can easily take an hour or more, in my humble opinion. Two reviews a day on top of all my bs meetings and I still have my own shit to do. How does my teammate have triple my PR reviews for the quarter? Seems crazy.

One day I'm pair programming with one such teammate. We finish the task, I create a PR, write a description etc. I press the ready for review button and start to say, "see you later bla bla" and suddenly there's an approval on the PR. It's been 5 seconds, tops. It's the other teammate with 10x code ninja numbers on the team. I remark that approval was pretty quick. My teammate forces a nervous sounding laugh. They work together ever day and seem pretty close, huh.

Anyway, after that, every morning after I made coffee and opened my laptop I'd spend 10-15 minutes just going down the list of open PRs on the project and approving them. I didn't look at the code or even bother reading the description. I just approved them all. I also started opening PRs for stupid shit like minor typos in comments that I'm quite sure no one even reads.

My next review my manager said I had made some impressive improvements and gave me a "meets expectations".

I'm looking for a job in a different industry now. I'm not out of software development, I just don't think I can work on another e-commerce webapp company run by MBAs again. I think I'd rather be broke.

This one bothered me. Because increased pull request (PR) throughput does not, in ANY way, imply "fewer defects, better testing, and more thorough peer review". In fact, it probably implies the reverse; just writing the smallest amount of code you can to get it out the door, then coming back and adding to it later. Edge cases? Next PR. Automated tests? Next PR. Comments? Next PR. Maintainability? Next PR. Taking the time to make sure the feature you're working on makes sense? That's not a PR, skip it.

Measuring PR throughput is the same as measuring lines of code, effectively. Nothing about increasing either one of them implies adding real value.

I've become very jaded around performance reviews. A number of years ago, I worked my butt off putting in insane hours and being extremely productive. I knew that I deserved the highest performance rating possible. And in the review my manager agreed that that was what I deserved, but instead I got a successful rating - completely middle of the road average. I was shocked. My manager informed me that HR specified what percentage of each rating they were allowed to give out and that he had had to give the higher ratings to other employees for various reasons. Ever since then, I've done the bare minimum of work to get by. Why work my butt off to get a successful rating when I can do the bare minimum and get the same rating?

ETA: none of this is as helpful as having my team and higher ups understand and appreciate what I do, though. That's step 1. Or step 0 if you can feel that out in the interview.

So, just the previous week I've made 5 small PRs, all of them working on the same certain "area" of the code base but different pieces of it. Two of those PRs touched almost every single corner of that "area" (differently structured error reporting and differently formatted logging) another one had a rather sizeable refactoring and code movements between three major files of that code area, and as for the two remaining ones, one absolutely depended on the other but could not be done in the same PR because of how the JIRA issues were structured (i.e. "PROJ-9004: Make it do foo", "PROJ-9005: While foo from PROJ-9004 is happening, make it also do bar").

I've also made a decision to not order those PRs sequentially (i.e., base the next PR on a previous PR), and instead branched each PR from the dev trunk and went to work on them. As a result, I've increased the work I had to do approximately by 50% because of the merge conflicts I had to resolve. The reviews combined took about twice as much time as a single big review of all five changes in one PR would've probably taken. The QA took about five times as long since QA did full regression of that code area 5 times instead of 1 time; they've also almost missed an error in the 4th pull request because of all the repetitiveness.

All in all, 10/10, recommend it if you need your coworkers to get lost in the maze of similarly-themed little branches, all alike.

https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

so we are the losers.. ah. Fine.

This is why my next project is a programmable HID bluetooth device that simulates key strokes and mouse movement. Imagine hackertyper.com but from a device instead. Because your corporate surveillance metrics are bad and you should feel bad ;)

In other words, if you are not excited to work with me, I am not working for you. Too much feudalism mindset in especially the US workforce is hampering wide-scale productivity.

If your work environment is not win-win and you're managing optics to avoid getting fired, just go where your coding talents are valued & be a happy person instead.

That said, it's actually very good advice if you want a promotion. Your manager needs hard data to take upstairs.

There's the problem.

Organizations whose leaders aren't able to discern your actual value are going to be miserable places to work. You play their games or baffle them with BS. But you don't get to attain any sort of authentic actualization.

...

Take my pessimistic commentary with a grain of salt. I'm job searching at the moment for a software manager role and the opportunity landscape is a wasteland of b2b insurance widget companies, usury companies, and AI dead-ends. If you want to build things that help real people, you may have to DIY.

We've gone from "You don't get promoted if you don't show clear visibility for the things that you do" to "You can get fired for not showing clear visibility for the things that you do".

The first is true. The latter isn't.

There are dystopian black swan events like the richest person in the world going on a ketamine binge and buying your company and dragging everyone into a meeting room with printouts of examples of your code.

Unless you're involved in one of those, noone gets fired for doing a lot of things but not tracking them enough in JIRA to cover your notes.

Most teams know who on their team gets shit done and who doesn't. They also know the ones who get things done without a clear track record of it. They are asked to help with every problem, and are constantly too busy to get their own stuff done because they're helping everyone else with theirs. Yes, they struggle to get promoted, but they certainly don't get fired.

The people who get fired are the ones who THINK they're in that group, but they're talkers, not do'ers. They get fired and everyone shrugs and goes "oh well, anyway."

Then they go and write blog posts like this to help precisely the wrong type of person that needs this advice - cargo culting impact. Becoming allegiant to process for the sake of visibility.

It'll certainly lead to more clutter and confusion in the world and in the tracking systems.

Might as well write blog posts about how to pad your line counts in your pull requests so that people looking at your Github graph at performance review time think you did more than you did.

>>“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.”

Was this article written by a LLM? Coze that's the most made-up, cliché, unrealistic, middle school parody-level perception of how businesses operate.

Any reasonably large and old company with a software base will have a god-awful overengineered incomprehensible duct-tape wrapped ball of mud that needs constant pampering and costly maintenance. With most task being very much "find the needle in the haystack" type, with the needle being that "one line" indeed but the problem in finding it being, obviously, the haystack. And this "needle finding" being that one thing that totally and definitely all this AI hype can't do shit about. Literally nothing, all those 700 billions burned into LLM training are absolutely orthogonal and useless with respect to the real problem maintenance and development of legacy software (that is most software) poses.

No.

Add value. It's not your job to quantify it. It's not your job to create an understanding of what you do.

If your organization or your manager specifically does not recognize your contributions, be happy to move on.

If you get feedback that says "we recognize your value, but we really need x" that's reprioritization. Respond appropriately. If documenting your value in that way prevents you from actually being valuable, be vocal about it. If it's just a pain and you can still do your job, then suck up the pain like everybody else.

I've been in large engineering organizations. They want to quantify everyones value so that there's "fairness". BS. There is no large scale way to determine of a software engineer is good at his job or productive. Yes, some people have more opportunities to affect the bottom line than others. Yes, some people have easily quantifiable work. That's how the world works.

Have they figured out a way to recognize and effectively incentivize good teachers? Not in my 51 years.

Have they figured out a way to recognize and effectively incentivize good CEOs? Nope.

What makes you think that we should be that easy to stack together and figure out?

I'm senior. I'm experienced. I'm valuable. I'm not always right, and I am not always valuable. In the end, I've had a good and healthy career focusing on the things I'm good at and the things I care about while letting other people figure out if I'm worth what I cost to keep around. Some of those people made good decisions and some bad ones. I still moved forward and my kids have always had food on the table. I say that's enough.

Aside from the naïve understanding of military culture, an organization full of managers looking only to promote and protect their teams is equally unhealthy. Dilbert spoke of "battling business units" whereby each team fought against one another to promote themselves. Not good. A manager must represent their team upwards to the higher chain, but must also represents the higher chain downwards. It is always two-way conversation.

No, your manager's job is to make their boss look good. This trickles up to making the CEO look good to the board and ultimately the investors/shareholders.

I mean, I know. I’ve been that asshole. Useful to still have a paycheck while you’re getting a startup off the ground. I got so much practice at “the dog ate my homework but here’s a fresh coffee” as a kid it was ridiculous.

I have to get my team to do the things the company expects, even when it's dumb or annoying. I can't get good bonuses for people who aren't visibly hitting the right targets.

Unless your total mission in life is to reform the company (good luck with that), you go with the flow. Having a good rant about it helps sometimes. But managers don't have much power to change the whole system.

It's moderately likely that behind the scenes someone was complaining to your manager that you were blocking their work and that the "metrics" discussion was just a cover for that.

Usually when I review a PR I am just sanity checking the overall approach, figuring out or asking how they tested it, and making sure there's nothing crazy that will cause pain for everyone else later. Detail correctness I don't consider my problem because there's no economic way I can verify it. I can usually approve in minutes and I don't consider it a waste of time, I did the things the process needed of me.

Unless something irreversible is happening (and it should be reviewer's job to be aware of that), the fix for a bad PR is more PRs.

There are projects where almost the only thing that matters is approving quickly because this will let your co-workers get on with their job, this culture tends to evolve in orgs with lots of related repos where you need 5 MRs and pipelines (that flow on to each other) to deploy the tiniest unit change. It's completely dysfunctional but it happens a lot.

I imagine there are places where reviewers are expected to spend an hour "raising the bar" on every PR but I've never worked at one. I'm also not sure if I'd want to.

Note that there's not one thing or process that makes sense, it's very context dependent with lots of exceptions. For example, if someone from a "far away" team is contributing to a particular repo for the first time I will probably reach out to them to see what they're trying to do and review more carefully because they likely have limited context vs a core contributor.