One thing that is always on the table - if you see a person picking up valuable work and they don't have a ticket for it - you as a manager can create that ticket.
Now you may need to coach the person on how to do that themselves (can we make the ticket making process more lightweight? Can we make a heuristic like just put story points for the time you've already spent on it plus a buffer for after-the-fact work?)
But managers who really want documentation and truly think people are doing underappreciated work can always make it themselves.
Dropbox was where I first encountered the infantilization of the workplace, with animated emojis all over your biannual performance review. It was a shock, having come from a real company run by adults. Now everyone thinks this is normal, at least at companies that use Slack where 40% of the traffic is animated emojis.
Exactly how I felt working at Google with their “open concepts”. Thankfully I am back at the University of Washington in a cubicle now, away from the yuppy babies. God knows where people get these ridiculous ideas.
I've never been a big fan of any such language, regardless of layoff context. Do enough people prefer it that it's actually a net win for business by way of improved morale or whatever? I wonder if it's been seriously studied.
Then again, I'm also of the mind that email addresses (or whatever other contact methods) ought to belong to functional areas/positions rather than to people (other than for person-specific topics such as time off, personal development, etc.) so turnover doesn't lead to questions of where to send questions/requests. I assume this is an unusually inhumane outlook!
I agree it's actually a well crafted layoff announcement. I wouldn't even faulting for using Dropboxers. If layoffs have to happen there are much worse ways of announcing and implementing them than this. Still very unpleasant if you're affected... (been there...)
I would bet money that Elastic uses a Terraform provider for Github and they marked repos private in an automated way, and the reverse API operation doesn't function in the same way.
It's possible that any delay is them trying to figure out how to get Terraform back to a good state rather than making the repos public being this inherently hard thing.
> It's possible that any delay is them trying to figure out how to get Terraform back to a good state rather than making the repos public being this inherently hard thing.
I don't know if it is Terraform, but if that was the case, it would actually be trivial to rollback the IaC terraform itself, or even from a previous statefile.
All things considered it doesn't seem to be a destructive mistake, and not 18:00 on a Friday :)
My experience with non-AWS providers in TF is that they're less maintained and buggy - in theory this should be easy, but people seem very afraid of TF and I can picture this getting chaotic.
But you're quite right that if they're comfortable enough, they should go into S3 and get a statefile they were happy with!
Permissions aren't the problem. But the upstream source of all the forks is wrong if you take a repo private, all stars from folks outside your organization are gone,... So you need GitHub support to restore everything.
And the details how it happened are a bit different but it was a configuration error (making things too secure )
Fair enough, and what I said was wrong too, so it's turtles all the way down!
I butchered Cunningham’s Law, thank you for correcting me, though the name of the law is confusing since it was McGeady who pointed out: "The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.", which is what I did, and what the parent comment did, it is attributed to the great Ward Cunningham, creator of the first Wiki, who is a rightful dude. I have nerd-sniped myself on this. At least I'm less wrong now, thank you.
I also kinda wonder if they accidentally removed a user or some credential that has the permissions needed to make things public again, a TF change could involve both the public/private change and user account changes. Could be a bit to look up an admin account to fix things.
You’re probably right, but I’m not sure I understand the point of managing a GitHub organization in Terraform, that sounds harder than it needs to be. Are there some reasons I’m missing?
All the common Infrastructure as Code reasons - you can get a change reviewed, people have an audit trail of changes, you can template out repos so they all look the same, anyone can propose changes even if making the changes are locked down to a few people, so on and so forth.
It’s useful to have a vision like this. Not because everyone will hit all these criteria. (If you do, I’d love to steal your hiring process.)
I find it useful because coaching people to be better is easier with an ideal like this to point to, that is complete. Lots of managers struggle to put into words why they don’t see an employee as they see themselves. If you have a genuine difference of opinion, you can relate back to something like this. Say your employee does a lot of tickets, and sees themselves as a hyper productive engine on a team. You as a manager see them picking up low-impact tickets and not finishing any features the business asked for end-to-end. The employee wants their productivity to be recognized. You want your employee to be more focused on a single business outcome rather than seeing a high number of tickets in the done column.
Some people (especially neurodivergent people) really “get it” when they have a pre-read they can think on and apply to their situation. A blog post like this is nice because you can have the employee read a bullet and then talk about how it applies to their situation in a 1:1.
In the past, I’ve really wanted better strategies for making this work organizationally.
If you say, “we have CRUD apps and some event-driven, truly bespoke stuff,” you have the problem of devs not wanting to work on the CRUD apps and only wanting the bespoke stuff.
Things I have tried
1. Hire seniors who are jaded by overengineering; they are happier to work on CRUD apps and will do things well.
This is my favorite strategy but there are not as many of these people.
2. Have contractors do CRUD and full-time employees work on core features.
This can create an uncomfortable culture split and if you’re not confident in managing contractors, can mean delays or having the customer-facing stuff look sloppy. I’ve also found some contract shops are not set up well to do security-critical things that aren’t a differentiator, like auth.
3. Pay for non-core stuff through vendors, and have employees focus on core things and a smaller set of non-differentiators.
This requires higher vendor spend but is probably the easiest to have a consistent culture and hiring setup.
The European cultures of Spanish/French were equally early (and earlier) to California. The author touches on them but dismisses them a bit.
I get the sense that this analysis is just based on the author’s knowledge of English cultures of the period? I think Spanish/French culture had influence too, it’s just that the author didn’t do enough research on them to be able to include them in their model.
If you want an example of a language where the exact opposite advice is taken at all times (with all the pitfalls described in this blog post), give Clojure a whirl.
Kinda depends on how much you value inductive vs. deductive reasoning, but the authors make the deductive case that:
- There's strong incentives to misreport in these areas (the compelling example from Sardinia was that the person is alive for the purposes of pension fraud, but really dead)
- People who are incentivized to report people being older than they are will do so
And the inductive case relies on data, which is presumed to be totally flawed because of the misaligned incentives.
The security vulnerabilities that affect my PII kinda contradict the idea that the kernel is an implementation detail. It’s not an implementation detail if I do, in fact, have to care about it.
As much as I hate the amount of illnesses my kids get from daycare - maybe this shouldn't be a goal? In workplaces, hospitals, etc. we definitely want to reduce illness. In daycares, the kids are all building their immune systems and the contact with germs is a vital part of that.
I definitely understand the teachers don’t want to be sick, and it’s a hardship on parents to keep kids home, so it’s not all about the kids’ health. But the kids’ health might be better served by letting them get more minor illnesses, not less.
Even a third less is probably still plenty. And the putative immune system benefit strikes me as hypothetical unless the exposure and effect are quantified.
Well, I've got all mine, unless another booster is available that I don't know about. One thing about vaccines is that you know exactly who got them, and who didn't. This probably makes it a lot easier to study.
And I'm willing to believe that some childhood exposure to pathogens is beneficial, but I don't think we know how much of a good thing is enough, or too much.
Do you think that we’ve discovered and cataloged the sum total of milder pathogens that protect against worse illnesses in a lab? Got all mine means “got all the ones we currently know enough about to develop a vaccine for.”
I'd agree based on my own bias which appeals to nature, and thus can only agree if the environment's somewhat untouched. but we've introduced so much into our environment, from tyre/brake dust to micro plastic to covid, I'd really much rather we just clean the air. we are not anime protagonist that evolve in real time, evolution in the real world consists of the unfit dying, and the ones that lives reproduce etc
Now you may need to coach the person on how to do that themselves (can we make the ticket making process more lightweight? Can we make a heuristic like just put story points for the time you've already spent on it plus a buffer for after-the-fact work?)
But managers who really want documentation and truly think people are doing underappreciated work can always make it themselves.