> I wonder if Amazon would check the Slack+Chime logs to see how the activity drops before and after RTO mandate.
I would be surprised if they did this, and if they did, use it for implementing any sort of meaningful change. Plus I would not put faith in leadership to being able to interpret what this really means because they are so out of touch with how things are going. Discussions with upper leadership is heavily reviewed and curated as a means to avoid getting called out and stay under the radar. They all have a skewed view of what's going on with the teams that build and this data wouldn't feed into it in a way that would be meaningful.
Likely what they will do is keep track of stuff like regretted attrition, hiring numbers (once they get back to hiring), Connections results, project/goal delays (the well established orgs are all aggressive about tracking dates along with goals to see how things are going).
> a lot of my colleagues have started working at 9 am and log out at 5pm pronto
I think this is a great thing. This is long overdue there. It's too common for employee's personalities to be all Amazon all the time. I've been to many social events over the years where I'm told to not bring/invite anyone from my Amazon circle because all they can do is talk about Amazon.
It used to be my favorite social media platform, but I quickly deactivated my account on Christmas and then deleted the app.
The major problem is that Threads will surface and even recommend (via your Facebook feed as well) threads that people you follow have responded to. Great in theory, but on Christmas Day I opened up FB to find it recommended this highly toxic anti-gay post in the middle of all my friends' posts about the holiday. It was because someone I follow on threads took the bait and commented on this post.
I've had far too many instances of this sort of behavior in my life and the only options available were to unfollow everyone, constantly block these abusive actors, or leave. For me, it was absolutely not worth staying, despite the up sides.
> Imagine a scenario where Photoshop would scan images you uploaded for copyright material and then refuse to work if it determined image contained any copyrighted material or characters (even if it was just a fan drawing you did).
YouTube does this. I have many friends that perform classical piano in their spare time. They record themselves playing a piece that's 200+ years old then put it on YouTube where it gets flagged saying some big record label owns the copyright for it because it's similar to a recording they put out.
> Leave work slightly unfinished for easier flow the next day
Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.
I like this example better because understanding a root cause and not having it fixed is more concrete than "slightly unfinished" which is too vague for me to measure.
I have done something like that at times. I find the bug in the afternoon. Now I have the satisfaction of having found it and don't want to risk the frustration of it not actually being the actual bug I found. So I saved it for the next day, to milk the satisfaction again, but also to be more fresh at it to fix it right and test it, or to better be able to deal with it not being the actual bug!
Though my boss at some point was puzzled "why don't you just fix it now?"
Also taking notes to bridge the time gap, physically or even just in the mind, can help improve understanding. Could be described as rubber-ducking with a future self.
>Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.
This works, but also needs some notes with a "dump" (on the previous afternoon) of all relevant points. For some subtle bugs and complex codebases it's easy to forget some key point, even though you found what the main issue to fix is. So if you already know some subtle points/edge cases in the afternoon, write them down.
It’s a lot of fun leaving notes. When I’m working in the office and the next day is a WFH day I ssh in to my home computer and write my notes in a text file in the home directory. It feels like I am reaching through the computer to my desk at home.
I like this, too. “Slightly unfinished, but fully understood” is a great place to pick up. A “slightly unfinished understanding” of the problem or task at hand is a great way to nuke one’s mental model and end up stuck trying to recreate it in the morning.
But how do you really know if the problem is fully understood? I often think I’ve understood a problem multiple times, and only reach a true understanding through repeated testing and fixes.
Sure sure, but a complete but incorrect understanding of the system is, to me, still better than an incomplete one. If I have a complete system in my head, I can use that to jumpstart my thinking the next day and then get to a correct understanding. But an incomplete understanding is even more confusing the next day because of all the loose ends.
Often, I find a good rest gives me greater understanding of a difficult problem or complex bug. Sometimes you get lost in the weeds. I also work much faster in the mornings, which helps.
This is the huge part. You found the bug, so your anxious mind is calmed, but you did NOT write the first fix that came to mind, so you have time to mull it over.
Often you realize sometime in the night that the first fix would have had other subtle issues.
And you’re less likely to throw a quick fix on in the morning.
Definitely. I’ve even had those magical moments where you wake up and realize you solved the problem in a dream. I think my preference is to have the major points of confusion cleared up so that they don’t become more confusing when I lose my mental model overnight.
A professor I worked with liked to stop work in the middle of typing something. “As if I fell asleep or passed out while working on it”, he said. And the next morning, kickstart the flow state by doing the very simple task of typing the rest of the unfinished word. Followed by the less simple but still straightforward task of finishing the sentence/line of code. And so on.
What if you're not working on a bug? If you're proficient, you should be able to measure the amount of work left in something so that it's "easily finish-able in the morning."
I did something like this yesterday. The only problem is that I spent all night dreaming of SQL statements to implement the solution. YMMV if you have trouble turning your brain off it seems.
I've seen many people refuse "low impact" work that's just flat out required for things to operate. Talking about keeping systems stable, working on tickets while they are on-call, and generally doing things that make work easily transferrable to others. These people that "refuse low impact work" end up being terrible teammates a lot of the time.
That's why they call it "on-call", you only work if you get the call. If you're on-call and being expected to work on unrelated tickets then you're now adding many hours/days to your working week, and somewhere near and just over the horizon is burnout town.
> people that "refuse low impact work" end up being terrible teammates a lot of the time.
yes, but there's a high chance they'll climb the corporate ladder way faster, while not caring about being great teammates because this is not a requirement for advancement. Actually, dumping this on someone else's lap [0] should be on the list of things to do if you want to move up from loser to sociopath [1].
I sneak in advanced things into lectures and preface it with "for students that are more advanced or have more prior knowledge in the subject..." I usually see the more advanced students perk up and the other students exhale and zone out a bit to rest their brain. Seems to work fairly well.
> While some of the commercial reasons for keeping game art under wraps make sense, many artists working in the video game industry say they're subject to a power imbalance, even in full-time studio positions, that sees the bulk of their work locked away in vaults, where not only can fans never see them but where artists can't share them either, not even in professional settings like job applications or portfolios.
This is actually a pretty big problem. My cofounder and I run a small video game studio and we worked with our lawyers to figure out how to protect artists as well as the company in a way that seemed fair. What we came up with was a general blanket rule that if an artist's work gets used in any public way (promo materials, game launch) then they can use that work immediately for their public portfolios. In the situation where it's not released we have end dates in the contracts for when they can use their work in their portfolios.
> If an artist's work gets used in any public way (promo materials, game launch) then they can use that work immediately for their public portfolios
Do you see this case being prohibited as the norm for other studios? (the cited section only talks about art "locked away in vaults")
> In the situation where it's not released we have end dates in the contracts for when they can use their work in their portfolios.
That's actually quite charitable, but IMO understandable how difficult this is for larger companies. After all your company paid for that product of work, which also reveals parts of your creative process.
Imagine Ford paying someone to make five car-designs, ending up using one of them and ultimately losing full control over the remaining four...
>Imagine Ford paying someone to make five car-designs, ending up using one of them, and ultimately losing full control over the remaining four...
Which is how things used to work. The Isuzu Impulse was originally a design for Audi and then BMW by Giugiaro which was turned down, and Giugiaro then reworked it a bit when Isuzu came asking for a new design. Originally the Cizeta V16T was a Lamborghini Countach replacement, before Lamborghini turned it down and Moroder bought the rights to it. The Chrysler minivans of much fame were originally a Ford design from 1972 called the Ford Carousel that Henry Ford II told Lee Iaccoca to buzz off with... Which he did after a minor rhinoplasty to the thing. And they were a smash hit that was half of the equation that saved Chrysler in 1983 and left Ford almost dead.
> Imagine Ford paying someone to make five car-designs, ending up using one of them and ultimately losing full control over the remaining four...
Yeah this isn't a valid comparison in the slightest. Artists using work for their public portfolio doesn't mean that they can use the work for other employers or in other contexts. Not sure how you made such large leap here.
> Someone who just happens to be a smooth talker shouldn't be earning more than someone else. If they actually bring more to the table, that is why they should earn more.
I love this mindset, in my experience it's a hard problem to solve.
Smooth talkers tend to fall into a few different categories that give them a leg up in negotiations - being part of a majority (usually straight male in engineering) or narcissists. (And yes, I'm oversimplifying things here just to get my point across.)
Everyone else? Some will be able to advocate for themselves, but others (especially under-represented groups) can easily downplay their worth. I've seen multiple times when women especially are trying to please the hiring manager/company and 'be flexible' in what they take. Other times it's from people outside of the U.S. where cultural expectations are different. To fix this we need people to have enough self-worth/self-esteem/trust to push on what they are worth and/or the company needs to act as an advocate on behalf of the employee. I've seen both be pretty tricky to figure out over the years.
I agree it's a hard problem to solve. And pay transparency alone won't solve it.
But it helps, as not only do you know what other people are making but they'd know what you're making. So people who manage to talk their way into some extra bucks on the way in, well now their coworkers know. And if that person isn't performing at a higher level, they'll start complaining.
And then yes, there are problems with the above. But my larger point is this puts more information in the hands of more employees, which can only be a good thing. The set of employees it hurts are the one set of employees who I think shouldn't be getting ahead in the first place.
I have a different reaction as I find this information useful. The lower range tells me if it's even within what I'm targeting. And if I get to an offer stage and I'm at the lower end of the spectrum, I would want to know why.
> I'm sure there's a substantial population that this redesign was successful for, but it's nobody I've talked to.
I think the measurement of success in this case has less to do with the customer's feelings about the product and more about people understanding and using the full feature set of Slack. All the new features they've been adding in just kind of floated by and we never used them. Either they were embedded in the middle of a series of steps we already had habits around (so we just ignored them) or they were so subtle that we didn't see the point in trying them out.
In other words, the problem they were really trying to solve was around scaling the product with all the features they had. That's likely where measurement of success will take place.
In other words, the new features are not something the users were looking for.
Instead of admitting adding new features just for the sake of adding new features, they want to force them into the faces of users still not wanting to look for them
I would be surprised if they did this, and if they did, use it for implementing any sort of meaningful change. Plus I would not put faith in leadership to being able to interpret what this really means because they are so out of touch with how things are going. Discussions with upper leadership is heavily reviewed and curated as a means to avoid getting called out and stay under the radar. They all have a skewed view of what's going on with the teams that build and this data wouldn't feed into it in a way that would be meaningful.
Likely what they will do is keep track of stuff like regretted attrition, hiring numbers (once they get back to hiring), Connections results, project/goal delays (the well established orgs are all aggressive about tracking dates along with goals to see how things are going).
> a lot of my colleagues have started working at 9 am and log out at 5pm pronto
I think this is a great thing. This is long overdue there. It's too common for employee's personalities to be all Amazon all the time. I've been to many social events over the years where I'm told to not bring/invite anyone from my Amazon circle because all they can do is talk about Amazon.