The biggest mistake those employees make on their way to getting overlooked is assuming their boss knows.

Everyone needs to advocate for themselves.

A good boss will be getting feedback from everyone and staying on top of things. A mediocre boss will merely see "obvious" things like "who closed the most tickets." A bad boss may just play favorites and game the system on their own.

If you've got a bad boss who doesn't like you, you're likely screwed regardless. But most bosses are mediocre, not actively bad.

And in that case, the person who consistently helps unblock everyone needs to be advertising that to their manager. The person who's work doesn't need revisiting, who doesn't cause incidents needs to be hammering that home to their manager. You can do that without throwing your teammates under the bus, but you can't assume omnipotence or omniscience. And you can't wait until the performance review cycle to do it, you have to demonstrate it as an ongoing thing.

What you're describing was precisely our culture at the last startup.

One group plans ahead and overall do a solid job, so they're rarely swamped, never pull all-nighters. People are never promoted, they're thought of as slacking and un-startup-like. Top performers leave regularly because of that.

The other group is behind on even the "blocker"-level issues, people are stressed and overworked, weekends are barely a thing. But — they get praised for hard work. The heroes. (And then leave after burning out completely.)

(The company was eventually acquired, but employees got pennies. So it worked out well for the founders, while summarily ratfucking everyone else involved. I'm afraid this is very common.)

It's even got a name: https://en.wikipedia.org/wiki/McNamara_fallacy

> Also this push to measure everything means that anything that can’t be measured isn’t valued.

Never thought I'd see an intelligent point made on hackernews, but there it is. You are absolutely correct. This really hit home for me.

The phenomenon being discussed here is a type of overfitting:

https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart....

The last 50 years or so of managerial practice has been a recipe for overfitting with a brutal emphasis on measuring, optimizing, and stack ranking everything.

I think an argument can be made that this is an age of overfitting everywhere.

Jira is already almost like "productivity theater" where engineers chart the work for the benefit of managers, and managers of managers only. Many programmers already really resent having to deal with it. Soon it will be a total farce, as engineers using MCP Jira servers have LLMs chart the "work" and manage the tickets for them, as managers do the same in reverse, instructing LLMs to summarize the work being done in Jira.

It'll be nothing but LLMs talking to other LLMs under the guise of organizational productivity in which the only one deriving any value from this effort is the companies charging for the input and output tokens. Except, they are likely operating at a loss...

Yes but metrics! How can the CEO look like they know what's happening without understanding anything if they don't have everyone producing numbers?

This compounds with each _team_ modeling the work in jira/excel too!

> steals a new worker’s lunch on the first day, just to see if he asserts himself

> to filter out the non-fighters

This is bullying and hazing.

Many of the workers in the 1950s were combat veterans who had lived through some shit and weren't as easy to push around. Contrast that to today when a lot of people tend to panic over minor hazards like a respiratory virus with a >99% survival rate. That cowardice puzzled me until I realized that a lot of younger people have led such sheltered lives that they have never experienced any real hardship or serious physical danger so they lack the mental resilience to cope with it. They just want to be coddled and aren't willing to fight for anything.

That generation had it more together as citizens, and they held on to power for a long time. Postwar all of the institutions in the US grew quickly, and the WW2 generation moved up quickly as a result. The boomer types sat in the shadows and learned how to be toxic turds, and inflicted that on everyone.

What if the workers decide the work is imposing on them? Maybe that's a good thing but it could go too far.

> The reason 1950s workplaces were more humane is that any boss who tried to impose this shit on workers would have first been laughed at, and then if he tried to actually enforce it by firing people, it would’ve been a 6:00 in the parking lot kinda thing.

That era also had militant labor organization and real socialist and communist parties in the US. Anticommunism killed all that and brought us to the current state of affairs where employers that respect their employees even a little bit are unicorns.

I would just terminate the call. Like... hell no.

Everyone's complaining about that as a developer, and rightly so. But that can't be easy for the PMs, either, trying to find a way to "add value" when they have no idea what's going on.

I'd expect there to be some "unexpected network outages" regularly in that kind of situation...

Yep, that would be my own personal hell.

This is kind of cool as an alternative process to develop apps with. Literally product in a zoom window telling you what to build as you go along. No standups, no refinement, no retros etc. Just a PM that really knows what the customer needs and the developer just building those as you go along.

Twice the billable hours! /s

I think thats the observation being made. Most people respond to the organizational problem with the only tools they have, which manifests as that.

Usually management knows and doesnt care about the problem

Doesn't this depend on the number of servers, crash rates and recovery times? I wouldn't feel confident running 3 servers running at 80% capacity in ultra low latency scenarios. A single crash would overwhelm the other 2 servers in no time.

What work are you doing the last few days? My experience is for a very narrow range of tasks, like getting the basics of a common but new to me API working, they are moderately useful. But the overwhelming majority of the time they are useless.

This has been my experience as well.

Cursor Chat and autocomplete are near useless, and generate all sorts of errors, which on the whole cost more time.

However, using composer, passing in the related files explicitly in the context, and prompting small changes incrementally has been a game changer for me. It also helps if you describe the intended behaviour in excruciating detail, including how you want all the edge cases/errors handled.

I recently tried Cursor for about a week and I was disappointed. It was useful for generating code that someone else has definitely written before (boilerplate etc), but any time I tried to do something nontrivial, it failed no matter how much poking, prodding, and thoughtful prompting I tried.

Even when I tried to ask it for stuff like refactoring a relatively simple rust file to be more idiomatic or organized, it consistently generated code that did not compile and was unable to fix the compile errors on 5 or 6 repromptings.

For what it's worth, a lot of SWE work technically trivial -- it makes this much quicker so there's obviously some value there, but if we're comparing it to a pair programmer, I would definitely fire a dev who had this sort of extremely limited complexity ceiling.

It really feels to me (just vibes, obviously not scientific) like it is good at interpolating between things in its training set, but is not really able to do anything more than that. Presumably this will get better over time.

I guess tech debt could even be increased in some cases. Some people shouldn't have too much time available :-)

well, not the original poster, but I have been managed by both kinds, and the best manager I ever had was not a former techie and the worst was a former programmer.

The worst manager did often say things that were sort of valuable and correct in a general way, like "well you don't actually know that because it hasn't been tested" which was of course true, but he also seemed to think he could tell people what the correct way to do something was without knowing the technology and the codebase. This often meant that I had to go to junior developers later, after a meeting, and say "concerning ticket X, T. didn't consider these things(listing the things), so that while it is true that we should in principle do what T. said, it will not be adequate, you will also need to do this - look at the code for this function here, it should be abstracted out in some way probably, this was my crappy way of handling the problem in desperation Y months ago."

Trying to explain to him why he was wrong was impossible in itself, he was a tech genius evidently, and you just had to give it up after a bit, and figure that at some time in the future the decisions would be reversed after "we learned" something.¨

on edit: in the example I give the manager as I said was correct in what he wanted done, but as I said it was inadequate as the bug would keep recurring if only that was done, so more things had to be done that were not as pretty or as pure as what he wanted.

I want my manager to help get the business out of my way- managing requirements, keeping external dependencies on track, fussy paperwork and such.

I don't need my manager second-guessing my every decision or weighing in on my PRs making superficial complaints about style while also bemoaning our velocity.

Hands down, the best managers I've had have all been clueless about the languages and types of work I do, and the worst managers have (or think they) have some understanding of what I do.

Oh, I vastly prefer people who don’t understand and know it.

Reminds me of Frank Zappa comparing "cigar chomping old guys" to the "hip young types" that replaced them

https://youtube.com/watch?v=KZazEM8cgt0

> Let me ask you this, would you rather be managed by a hierarchy made up of people who don't understand what you do? Because I assure you it is far worse than being managed by "class traitors".

One's direct manager should be a developer, yes. The problem is the level above that - most organisations don't have a SWE career track, so if you want a pay rise you need a promotion and that's only available for managerial roles.

The problem there is that a lot of developers make very bad managers and a lot of organisations don't give a fuck about giving their managers the proper skills training. The result is then usually a "tech director" who hasn't touched code in years but just loves to micromanage based on knowledge from half a decade ago or more. That's bad enough in Java, but in NodeJS, Go, Rust or other hipster reinvent-the-wheel stacks it's dangerous.

They come in and blather completely irrelevant, way outdated or completely wrong "advice", plan projects with way less resources than the project would actually need - despite knowing what "crunch time" entails for their staff themselves.