This has always been the case. At Google most employees lost about a week of time twice a year to write their performance review documentation. I'm sure a lot of companies made it worse with remote workers, but I don't feel that this is anything fundamentally new.
> 85 percent of bosses say hybrid work makes it hard to be confident that employees are being productive
If they can't be confident employees are productive because they can't see them working, how on earth did they measure productivity before? Weren't they merely measuring how many people they could see working and not whether they actually produced anything?
Exactly, they were never confident in that workers are productive. This is understandable in many cases, but it almost nothing to do with remote work then. They could only measure that employees were busy before, not that they were productive.
Well you could have just popped over to someone's desk and caught up on their status. You could see, at a glance, whether they were blocked, or struggling or not. Remote requires much more formal process for that kind of synchronous feedback and you're guaranteed to interrupt someone.
Fully async is possible but it's really hard. You get much slower feedback and much longer iteration times. Instead of ad hoc collaboration and course correction, you're dealing with playing tag and over the fence throws.
> Well you could have just popped over to someone's desk and caught up on their status. You could see, at a glance, whether they were blocked, or struggling or not.
This is about as good as deciding George Costanza must be working hard because he's always angrily furrowing his brow.
If you're in a sitcom and only dig that deep, perhaps. In real life its easy to read body language and see if a junior is struggling. By the end of sprint one, you look at actual output and if it doesn't match your interpretation you adjust and get to know them better.
That's because of lot of people were not productive even before, but they looked like they were. Remote is revealing how much BS todays' workplace has became.
Most bosses are baby sitting. Maybe I’ve been incredibly unlucky but I have never had a boss in tech who produced anything but meeting invites.
If there are teams that need fat trimmed it’s HR, PM, and management. THE tool necessary to check if software eng are at work exists; source control. Rather than having managers do data entry in Jira, read your source control logs into unified place for them; Google sheets, or some dashboard. Their data entry jobs are not producing business functionality. IT is not the cost center anymore but the backbone of business.
I can manage all my HR needs from a slick website now. I have not connected with an HR person since I was hired into my current gig 3 years ago.
Given how simple it is to build complex software stacks now, the endless hiring of middle management has just increased the gamification of office work. They have little productive work to do and engage, unintentionally maybe, in distracting efforts to appear on top of things.
Frankly; who cares if past orgs used to in-office life can’t survive this. That’s a free market. Managers keep chanting “disrupt!” and similar shallow sound bites. Keep following orders; disrupt away the unproductive sycophants who went into tech management the last 10-15 because of the boom itself, with zero ability to produce.
I took a look at my manager's calendar once and it was nightmarish. 8 hours of straight planning meetings, some of which overlap.
And us boots-on-the-ground devs tend to largely ignore what management plans, as we actually know what is and isn't possible with the libraries we're allowed to use and the time allotted.
I've been in plenty of those meetings. It's ten minutes of content stretched into one whole hour of assholes patting themselves on the back, cargo culting jargon, asking the same questions they asked the previous day, not listening when you answer their questions, asking for magic and being confused when it doesn't happen, assuming hard things are easy and complaining when obvious problems arise, especially if you warned them previously, claiming you aren't doing enough to "show value", and just wasting time.
The project I'm working on has been "behind schedule" for months, is super time sensitive, and I've just been ripped away from it to do a completely different, important, time sensitive project. My manager STILL complained when I didn't show up to TWO DAYS of "Agile training" that was just watching useless powerpoint presentations about how "the SCRUM MASTER" serves everyone and is a magical being that "provides value" and other pointless Rally As Agile cargo cult.
Heaven's sake, the agile manifesto is like 100 words!
> THE tool necessary to check if software eng are at work exists; source control.
Careful. I don't commit every experiment I run, and some features or bugs require quite a bit of experimentation. I once had a client who refused to pay for a day on which I did a lot of work, but didn't commit it to source control.
Supporting anecdote: I develop API integrations with third-party software used by our clients. Part of that means testing various APIs that may have quirks or be poorly documented, and sometimes inspecting the way our clients have chosen to arrange their own data in those APIs.
This can lead to a lot of little scripts like `list_thingies.sh` or `get_thingy_by_id.sh`, so that if something goes weird I can easily provide a small repro-script to another person with some confidence it'll be helpful even if their company has a very different tech-stack.
However all those unpredictably one-off experiments and tools for inspecting remote data shouldn't be part of whatever I check in for our production code, not least because they often have some credentials embedded in them. (Especially when the thing being tested is whether we're authorizing our client correctly.)
That said, we've been discussing how we might want to keep them in a separate "random exploratory shit just in case it's relevant again someday" repo.
> That said, we've been discussing how we might want to keep them in a separate "random exploratory shit just in case it's relevant again someday" repo.
You definitely should. If they're useful, not just to you but also to others, then you want them backed up and accessible. Just remove those credentials.
Lots of naive advice in here. A lot of work goes into a product besides LOC in source control. PMs and management interface with other teams. Do YOU want to be in meetings with sales and marketing going over the product for the millionth time? The business doesn't want to pay engineer hours for that either. There's nothing worse than slick B2B software with no human intervention. Walk outside the happy path and you're SOL.
If all you’re going to do is walk the happy path the marketing necessity makes sense; you’re a bit player in a crowded cottage industry. Your startup probably doesn’t need to exist as 9 others are doing similar enough data crunching.
Real talk; open source ML is on the way that will end digital content creation jobs. Intelligent deployment of infra is here and will get better; bye devops/secops.
If you’re suckling at the teet of the past you’re missing out on a lot of cool projects. Stable diffusion is just the start of smart open source software. I’d reconsider your path altogether if you’re envisioning a long career in software and avoiding cross training.
After an employee was caught being simultaneously employed at Google, my employer has started counting changes per engineer per week. It has been pretty controversial! Exactly the “gamification” you’re decrying here.
I don't consider it "proving" I'm working but, I tend to over-communicate (or some call it just "communicate") with my team. I let them know when I'm running to lunch or running an errand. I tend to talk about what I'm working on throughout the day. Folks rarely respond to any of it but, I feel a level of accountability. I don't expect anyone else to walk me through their day... It's just a "me" thing.
Distracting Slack noise. I'm always a little annoyed when people do this and litter public channels. If you feel strongly about communicating your status changes all day, set your personal status - if someone wants to communicate directly with you, they can see that you're "out to lunch until 1:30EST! :foodemoji:" or whatever, but it's not proactively notifying everyone else who doesn't care.
There was an old Dilbert comic where Dilbert gets permission to work from home and he asks if he has to work a full 8 hours, or can he just work as much as he does at the office once with all it's distractions
38 comments
[ 2.6 ms ] story [ 78.2 ms ] threadIf they can't be confident employees are productive because they can't see them working, how on earth did they measure productivity before? Weren't they merely measuring how many people they could see working and not whether they actually produced anything?
Maybe we should schedule a weekly meeting to discuss this problem further.
Fully async is possible but it's really hard. You get much slower feedback and much longer iteration times. Instead of ad hoc collaboration and course correction, you're dealing with playing tag and over the fence throws.
This is about as good as deciding George Costanza must be working hard because he's always angrily furrowing his brow.
If someone looks like they are slacking (not busy( but I can’t tell if they are delivering enough, then the problem isn’t that they aren’t busy.
If there are teams that need fat trimmed it’s HR, PM, and management. THE tool necessary to check if software eng are at work exists; source control. Rather than having managers do data entry in Jira, read your source control logs into unified place for them; Google sheets, or some dashboard. Their data entry jobs are not producing business functionality. IT is not the cost center anymore but the backbone of business.
I can manage all my HR needs from a slick website now. I have not connected with an HR person since I was hired into my current gig 3 years ago.
Given how simple it is to build complex software stacks now, the endless hiring of middle management has just increased the gamification of office work. They have little productive work to do and engage, unintentionally maybe, in distracting efforts to appear on top of things.
Frankly; who cares if past orgs used to in-office life can’t survive this. That’s a free market. Managers keep chanting “disrupt!” and similar shallow sound bites. Keep following orders; disrupt away the unproductive sycophants who went into tech management the last 10-15 because of the boom itself, with zero ability to produce.
And us boots-on-the-ground devs tend to largely ignore what management plans, as we actually know what is and isn't possible with the libraries we're allowed to use and the time allotted.
The project I'm working on has been "behind schedule" for months, is super time sensitive, and I've just been ripped away from it to do a completely different, important, time sensitive project. My manager STILL complained when I didn't show up to TWO DAYS of "Agile training" that was just watching useless powerpoint presentations about how "the SCRUM MASTER" serves everyone and is a magical being that "provides value" and other pointless Rally As Agile cargo cult.
Heaven's sake, the agile manifesto is like 100 words!
Careful. I don't commit every experiment I run, and some features or bugs require quite a bit of experimentation. I once had a client who refused to pay for a day on which I did a lot of work, but didn't commit it to source control.
This can lead to a lot of little scripts like `list_thingies.sh` or `get_thingy_by_id.sh`, so that if something goes weird I can easily provide a small repro-script to another person with some confidence it'll be helpful even if their company has a very different tech-stack.
However all those unpredictably one-off experiments and tools for inspecting remote data shouldn't be part of whatever I check in for our production code, not least because they often have some credentials embedded in them. (Especially when the thing being tested is whether we're authorizing our client correctly.)
That said, we've been discussing how we might want to keep them in a separate "random exploratory shit just in case it's relevant again someday" repo.
You definitely should. If they're useful, not just to you but also to others, then you want them backed up and accessible. Just remove those credentials.
Also it’s illegal to not pay at least minimum wage for “piecemeal work”.
I refuse to take hourly contract work. Half now, half upon delivery. Customers need to put some real skin in the game.
Real talk; open source ML is on the way that will end digital content creation jobs. Intelligent deployment of infra is here and will get better; bye devops/secops.
If you’re suckling at the teet of the past you’re missing out on a lot of cool projects. Stable diffusion is just the start of smart open source software. I’d reconsider your path altogether if you’re envisioning a long career in software and avoiding cross training.
They've done a good job of setting up eternal rent-seeking establishments; gonna be impossible to get rid of them now.