I don't see it in tech circles as much, but in other circles like consulting, banking, advertising, it's pretty common to see people constantly cycle back and forth between the same set of employers every couple of years. Think Goldman Sachs trader leaves for JP Morgan, then leaves for Morgan Stanley, then leaves for Goldman Sachs, and so on
The idea that senior engineers need public commits to be even considered for a job seems a little extreme to me. There are myriad reasons why an extremely competent senior engineer might not have public commits.
The lack of public commits does not signal whether or not someone is a competent senior engineer.
I guess if the rest of the CV was a really strong match, I'd give them a chance but they'd have to do a "technical interview" same as any other junior. I can only speak for myself that I haven't seen many CV's in my environment where 98% of the stack is built on FOSS and 100% of the tooling uses FOSS that an expert in that field has never contributed anything to a FOSS project, has never asked a question on an issue or created an issue (and also lacks any other public facing work like personal projects, talks, blogs, etc). I'd also interview them if they were recommended by a colleague.
My experience is completely opposite of the author's. I sign on once a day when I access a service that uses my firm's SSO solution. I'm then automatically signed in to all other services as I use them. It's quite seamless. I have no complaints about the SSO setup in my firm.
So your company doesn't have certain functions where someone has said "this is really critical so we'll force a sign-in even if the SSO token is already there" because that happens to me 10 times a day at my work.
I see this in situations similar to sudo where you need to make sure it is the same user that signed on when elevating privileges, vs letting in anyone who sits down at an unlocked user's terminal.
Which is silly because if you do that you're basically admitting that your SSO isn't fulfilling its promise of identifying the user. If you are having the thought, "what if the user I authed isn't the user anymore" then you should be reauthing them for any service at that point.
Almost as fun as when TSA uses logic like “we thought you were going to hijack a plane using those nail clippers, but now that we’ve made you throw them away, you can board with no further scrutiny! Crisis averted!”
Yes, this does happen. Especially for HR related matters. But that's definitely more of an exception than the rule. For most services that I use on a day-to-day basis, the experience is seamless.
Honestly I don't mind this too much as long as it's yubikey only, that literally is just reach up, tap, hit enter: 1-2 seconds if you know it's coming. If they require to reenter a password it's more like 10-30 seconds depending on if I mistype anything. That's just setting the wrong incentive to have a weak password that is easy to type.
Web development is the way things are moving - a lot of "desktop" apps now are web apps in disguise (thanks electron). It's worth getting familiar with web development for the job opportunities alone.
It always (still?) surprises me how difficult it is to share files across the Internet. You'd think this would have been a solved problem already given how long we've been communicating with each other electronically.
