I worked for IBM Cloud about 6+ years ago. While there, we had to connect to a Softlayer VPN to get into our Jira instance. My VPN account and Jira account never got provisioned so I couldn't connect nor see the Jira board. My team-mates couldn't even assign a ticket to me b/c of this. They would just put my initial's in the ticket summary and send me a slack of the details.
It was right before I left that we got our own Jira instance. This was all around the time of the Red Hat acquisition. I remember the announcement b/c we used SuSE for everything IIRC.
I work for a company that has so much bureaucracy and silos that teams maintain wiki pages with links and routing on how to create tickets for specific tasks and wether there is a specific mandatory information needed in order to not have your ticket just closed as incomplete without an explanation.
Sometimes a team unilaterally decide to change the process, info is sent to a random number of mailbox/managers who may fail to pass the info. Some entire teams just put themselves in away status 24/7 and do not respond to direct messages.
So yes I can believe his story. Sometimes in these kind of companies you just don't know who and how to ask for something and you just hope someone knows someone who might know.
What's the largest company you've worked for? A lot of big, older companies, are just so messed up that its just not worth it. How do you do this? Well you have to find the specific form, or specific person who does the thing, who is that? no one knows. So that provisioning of a vpn and getting in jira might literally be like a month of work.
I've worked for S&P Global, so pretty large. If you don't have an account that you need, then you need to be tenacious, which of course is super annoying. If you don't have an account on a system you should, it's 100% on you after a while.
On consulting engagements, 0% of the time are Jira and git provisioned correctly for an outside consultant. I used to be appalled at being paid for two or three days of waiting for the IT guy to fix this. Now I use the time to find cleaning supplies and deep clean my cubicle and chair. People do look at me funny, but I feel better not just sitting there reading.
I did, multiple times. I was a contractor. I was the only one on my team of contractors whose account was screwed up. There seemed to be no priority to do anything there. One of many many reasons I left when I could.
I had a similar thing happen to me with a huge company as a contractor. I couldn't work for 3 weeks due to a combination of login issues and permissions settings. Couldn't file a ticket and no one was really sure who to call/ask. Finally a director caught wind of it and knew who to talk to.
I imagine that's done via JIRA tcket/IT before onboarding.
So if they somehow can get past initial device deployment/user account logon, and get other resources IE; slack....well that speaks to how difficult/pointless it would be to get proper VPN/Jira access.
I worked on a telecom codebase that dated back to 1985. Similar experiences. Was wild to think of contributing to something that was almost as old as me.
Depends on the database. Microsoft SQL Server typically uses the PK as the clustering index. This dictates the order the table data is stored on disk. If you row PK is random you're going to have write latency and a fragmented index.
Even in non-clustered indexes (relevant to pretty much all SQL implementations not just MS SQL Server) random keys can cause the index to balloon over time due to many page splits, requiring extra space or extra maintenance rounds (rearranging the indexes to optimise them occasionally, if the relevant data grows rapidly or changes often).
The effect is just worsened by clustering, as done in SQL Server for significant (or at least measurable) benefits for many data patterns, because your base data is bigger due to wasted space due to excess page splits, as well as your supplementary indexes, so that needs reorganising more often too.
A common answer is to use an int (or maybe bigint) for your internal keys and a UUID for anything external, so you have the benefits of a UUID for external use (practically zero chance of collision in distributed systems, if appropriately random, and not potentially leaking information in some security contexts) but the efficiently of the integer otherwise. Or to use a partially ordered UUID format, which balances the compromises slightly differently (benefit: single value, dropping some of the UUID issues, keeping some of the benefits; detriment: letting some of the disadvantages of UUIDs, potentially reducing some of the benefits).
The most deployed database these days is probably SQLite if you count semi-embedded contexts (ie. mobile apps). Excluding that it does look like MySQL is still on top, but Postgres is catching up fast. I completely forgot InnoDB uses clustered indices by default. Regardless, I was referring to most by implementations, not deployment numbers.
It was right before I left that we got our own Jira instance. This was all around the time of the Red Hat acquisition. I remember the announcement b/c we used SuSE for everything IIRC.