Layoffs in the WFH era are weird. Back in the day you had a pretty good idea of who got laid off because you saw them walking out the door with a box of their stuff. You could go up to them and say, "hey let's meet at $local_watering_hole and hang out". You could swap contact info if you didn't already have it. You could get closure. Now, one day a bunch of people just stop replying to email. You have a to wait a whi…
Figure out who's leaving the company: dump, diff, repeat
341–350 of 392 posts
Re: Figure out who's leaving the company: dump, diff, repeat
#342Not a WFH thing. This is a USA thing!! Edit: OP said "Layoffs in the WFH era are weird" Yes they are, but people here don't suddenly go offline quite as weird is what I was trying to get at. Here in Sweden if you are FTE there is usually a 1-3 month layoff period (upppsägningstid) where you work and get paid still. At the end of the period you leave. People usually email the team and even the entire company with "hey…
Yes, but in cases where a disgruntled employee can do real damage, companies can and do simply ask employees to go on gardening leave with immediate effect, while paying them the rest of their notice period.
https://www.theguardian.com/technology/2017/aug/01/sweden-sc...
Re: Figure out who's leaving the company: dump, diff, repeat
#343Well that depends I guess. A lot of companies/orgs have privacy policies that prohibit accessing services out of "curiosity." I.e. if you're working at a university it's OK to access student information if you're doing it for a specific work-authorized purpose but you can't go casually looking at people's information just to satisfy some personal interest.
Re: Figure out who's leaving the company: dump, diff, repeat
#344Earlier quoted context omitted.
I worked at a large web dev company and for years they had this attitude. Then one designer put in his two weeks and spent the majority of the time downloading all the site files for all of the sites the company had built over the two years he was there. We're talking hundreds of static sites where he took the all the design docs and static HTML/CSS/JS files one would need to recreate them somewhere else. Instead of…
> We're talking hundreds of static sites where he took the all the design docs and static HTML/CSS/JS files one would need to recreate them somewhere else. You make it sound like he poached your clients or extorted your company. As they didn't go after him legally, I assume that didn't happen. I assume all the files are on a thumb drive in his drawer, unopened, just in case he wants to remember how "that cool animati…
It feels like if an employee did this with modern projects, they would at the very least be summarily fired, if not have legal action taken against them.
Re: Figure out who's leaving the company: dump, diff, repeat
#345We had this internal web application. It had its own separate username/password table. I was asked to make it so you could login with your regular password instead.
It wasn't hard to solve the password part. I could make the web app consult the main system to verify your password at login. But... I couldn't eliminate the web app's user table entirely. It was too fundamental.
So I built a thing that ran periodically, got a list of users from both places, diffed the lists, and then did the required create/update/delete operations on the web app's user table. Thus the web app's user table mirrored the main login system.
I rolled this thing out and babysat it, keeping an eye on its log file. Naturally my code logged operations done on the user table. And I was like, "Hey, this is telling me who is joining and leaving the company!"
It even gave me a little additional info. The web app had certain roles and permissions, and these needed to correspond to organizational structure, which I got from the main login system. So if a user's web app roles changed, it was a clue they may have switched teams or got promoted.
I felt like I needed to be a bit careful with this info. Not that I wasn't allowed to have it, but I don't think IT expected anyone to have a tool that would make it that easy to notice changes as they happen. Potentially, I could have known someone was fired before their manager told them or something like that.
TLDR: Tried to streamline operations, accidentally developed a signals intelligence capability.
Re: Figure out who's leaving the company: dump, diff, repeat
#346Earlier quoted context omitted.
You could rewrite Plato’s Cave for some companies, especially the insular ones where there’s some culture shock when you get into “the real world”.
Plato’s cave needs to be rewritten anyway time to just acknowledge that its an overly long arduous convoluted setup that can be vastly simplified for the message it creates
Re: Figure out who's leaving the company: dump, diff, repeat
#347Re: Figure out who's leaving the company: dump, diff, repeat
#348Why? Because a good termination process is sensitive to there needing to be a communication about a termination that can happen well after the actual process of eliminating their access and telling them it's their last day.
So a better termination process is something like:
1. Employee goes to a physical space (preferred) where they don't have their work equipment or talk to their manager and/or HR using something that isn't work controlled (phone call, etc.).
2. A manual or scripted process executes that forces sign outs of all work things (computer, slack, google, whatever). Credentials get reset and not disabled. Perhaps someone can try to look for password reset metadata or other things that might indicate a departure, but it's a lot harder than looking for disabled uids.
3. After the person leaves or has finished their conversation remotely, the team that works with this person gets a broader communication from someone to tell them about the departure. If the company is small enough, maybe there's a broader communication to more people.
4. The rest of the termination process gets fired off that does disable accounts, etc.
Why don't all IT departments do this? Well for a lot of reasons:
1. They don't care, don't have incentives, or haven't been told by HR, etc. to care about handling the termination process in a more sensitive way.
2. For any sufficiently complex company, the number of edges cases of systems where you can't force a logout or handle a password reset increase over time. It takes a lot of testing to make sure a process works because vendors have bugs all the time or unintended behavior.
3. The risk of poorly communicated terminations increase as the number of people that either perform or can troubleshoot the automated process to terminate increase. As others commented, you don't want some ticketing system that is readable by a wide amount of people to see termination requests, so now how do you communicate a termination without too many people knowing about it?
Strangely enough, I think trying to achieve the most sensitive but automated process is good because it forces the company to communicate and acknowledge a departure before the full termination process fires off, but maybe I'm in the minority.
Re: Figure out who's leaving the company: dump, diff, repeat
#349Earlier quoted context omitted.
I've been seriously considering using Git for all sorts of oft-changing-but-rarely-majorly data. Lists of books in my bookshelves. The other problem is that I sorta want transactional-database features on top of these things. Git does this well. I also want fast indexing on parts. Git does not do this well. I am considering writing a "standard" for the dumping of sqlite to git, so that I can just delegate this out; A…
Would fossil fit this bill? Somewhat git-compatible, based on sqlite3.