[FirmwareBurner]

Or check Jira and Git, it's not rocket science. If the person has a task assigned that would take a junior max 3 days of chill work to knock out but it's been 7 days and still no results and the person hasn't reported any blockers on the dailys, it's pretty obvious there's a performance issue.

[icedchai]

I usually check Git, see nothing committed, then ask them privately "how are things going with your project? Do you need any assistance?" Another couple days goes by, some garbage that doesn't run is committed to git... I ask again. The cycle repeats. I'm just the tech lead on the project, I have no real authority, so if the situation doesn't improve I do mention it to the actual manager. They usually then do nothing.

[FirmwareBurner]

Damn I'd like to work at your company to coast for a bit to relax. Where I'm at right now you'd be fired on the spot after a couple of weeks like that if your manager hears you're doing nothing.

[icedchai]

We had someone who got fired for performance issues. It took a good 6 months.

[The_Colonel]

It's quite easy to hide (provide plausible deniability for) low productivity if the person is smart about it. Complain about environment issues, broken CI builds, unexpected complexity etc., there was one meeting too, then put in the minimum amount of progress.

[tharkun__]

For many of these there are fixes.

I've had people try the env issue thing. I asked them to never try longer than 15 minutes to solve an env issue by themselves. Post on the public dev channel for help or ask me privately if they don't feel comfortable with it (it happens, that's OK). A lot of people just aren't good at troubleshooting env issues and I happen to be good at it even if I have never had that issue and I keep an eye on others posting and often can find a solution for people quickly. It's amazing how many people can't read error output, especially stack traces, and figure out which is the relevant message to search by.

Broken CI same thing really. And it's easy to compare if it's just them or everyone's builds are broken.

Complexity I offer help. Pairing for as long as needed. I've had a few guys where it became clear here that they really just weren't good. There are many signs here that you can collect and document. I've also done Re-implementations from scratch (not looking at their code) in some instances, proving their "hidden complexity" that took a week to not solve took me literally an hour to code down.

[The_Colonel]

For sure, if you like to be a detective and expose the slacker, it is possible to do it. But more often I see people rather giving the benefit of the doubt.

[tharkun__]

As a peer that's totally OK.

As the manager/lead I have an obligation to figure out if someone is just having temporary trouble or if they're simply a slacker by nature or just not good at their job. If that is the case it is my duty to get them out. They can slack off somewhere else and drag other people down, not me and my team.

Both for the company (I couldn't really care less in most cases, since the company doesn't care about us either) and for the rest of the team (I could never stand managers that let obviously bad/slacking people continue working alongside the rest of us that do their job properly and the slackers still get the same raises and potentially even negotiated a better salary, as they're probably good talkers, but bad walkers). I care for actual walk. I do not care for cheap talk but it's the most common.

[FirmwareBurner]

Of course it's easy to fake issues to justify lack of productivity for months when you're remote, but then you should be sharing your issues at the daily meetings so people can help you fix them to get on with work. That's what the dailys are for.

Keeping your blocking issues silent for days is what the problem is, not that you habe issues.

[pawelduda]

Complaining about all these is legit, I'd rather do it and get fired for "underperforming" than push through this shit and burn out. These sound like excuses but could be real issues that should be investigated because maybe it's rotten infrastructure that nobody cared about because it's "unproductive". Other devs can be affected too, apart from the person raising it because they lowered their expectations over time and can handle the suffering for the time being, while waiting second hour for CI to pass

[The_Colonel]

All of these are legit, and that's why they're great excuses. CI works most of the time, but sometimes has hiccups for whatever reason. Everybody gets hit by such issues from time to time, this particular dev is just reeeally unlucky and happens to catch those every other day. But nobody keeps the stats. People might get a hunch something is wrong, but what can you do with that?

[pawelduda]

Offer help with troubleshooting, hop on a call (maybe pair programming), ask what have they tried to solve the problem, etc, etc... If you assume someone is slacking because of common roadblocks, you're setting yourself up for trust issues. If you see they are indeed underperforming, you can take regular steps from there. If they straight up lie it'll be obvious at some point. No need to start with stance of distrust IMO

[tkiolp4]

Or perhaps: the task is really not that important and nobody cares. If it should take “3 days of chill work” and nobody complains on day 5, well, perhaps it’s better to not solve the task at all.

[FirmwareBurner]

Found the Googler.

Clearly from OPs complaints it's clear that people are checking in on the work, which is missing, that's why he opened this topic.

[GoToRO]

Aaa... the mythical junior.

[FirmwareBurner]

What's mythical about that?

[GoToRO]

Every manager I know will threaten to hire that junior. The problem is that he/she doesn't exist.