Hacker News Reader

The way interviews (and hiring) is conducted sense this as well, illustrate it. Giving it the (alibi of) equality prinicipal treating everyone the same with standardised measures and whiteboard tests effectively looking for new people fit a simplistic API, possessing the standard communication style and returning the expected (here simplistic) results allowing a hot swap attitude for human components.

There should be additional proper internal training and discovery of hidden talents and diversity, also retention measures (this automated firing method seems to be the opposite) if they want to avoid stagnation into predetermied style by standardised persons. With the dynamicity of the industry stagnation puts giants in danger of stepped over or trip in a shorter period than a top manager's tenure (earlier stagnating giants could live for decades due to their mass, for the pleasure of top executives).

Loss of organizational knowledge.

It is the zombie disease. Companies start off, have people with tons of knowledge, people don't get into higher positions, politics happens, they leave, and now you have someone that's there just for the job and is surviving off of limited knowledge. They leave because they don't own the system, and now the org is inefficient and cumbersome, effect becomes worse with the next hire, etc.

Company dies, another spawns, cycle continues.

Seeing this happen to my company, management layer is bloating and engineers are dropping away leaving juniors in their place. The result is calendars are becoming more ladened with endless meetings where managers all try to dominate a conversation and come to the end without a single actionable point, well I am wrong there, the action point is to discuss it at the next meeting.

Well the main trouble is that you don't get rewarded for sticking around, being paid essentially the same as a "new hire" as "can poke holes and come with ideas" being very similar in pay scales.

Only way to scale is to hit your knees in every two years to get a proper pay raise. Even if detrimental to your knowledge and work place.

yep, the attitude towards layoffs isn't just dehumanising, it actively discourages company loyalty. It's clear that the company sees employment as a purely financial transaction, and all the complaining about "quiet quitting" will not stop that attitude being reflected back.

Literally today I said something similar.

"Who knows about this data?"

"X and Y do, but they're gone. These people know a little bit about it."

C'est la vie.

Ten years of this same experience and my peers still don't get why I'm trying to get into management.

> We'll get the job done without her, but it'll take us 5×? 10×? as long

But you accepted a salary that does not pay overtime and the trend is that people will work the overtime to meet the totally made up deadline. C suite doesn't care about Alice and is hoping cutting her loose will make everyone else work harder to keep their jobs. They normally do. Who's out of their mind in this scenario again?

I'm surprised that the government hasn't started cracking down on unpaid overtime. It not only violates workers' rights, but also means less tax revenue. In other countries it's required by law to pay double for any overtime.

If you are paid a salary (you make $X / week), there is no overtime (or unpaid overtime). You get the same amount each week no matter how much or how little you work or how much or how little you accomplish. If you make at least $684 / week and are an exempt employee paid on a salary basis, there is no overtime.

To get to the "you get overtime for working more than 40h/week" people need to switch from being salaried to being hourly (and then they would be paid for all hours worked - note that exempt employees don't get a 1.5x overtime increase).

However, I will note that a lot of people start saying "don't track me", complaints of time sheets, and there's a fair amount of boasting of only working 20h/week.

You want to get to "no unpaid overtime" - the path there is through working hourly rather than salary and only getting paid for 20h if you only work 20h.

https://www.dol.gov/agencies/whd/fact-sheets/17a-overtime

> However, Section 13(a)(1) of the FLSA provides an exemption from both minimum wage and overtime pay for employees employed as bona fide executive, administrative, professional and outside sales employees. Section 13(a)(1) and Section 13(a)(17) also exempt certain computer employees. To qualify for exemption, employees generally must meet certain tests regarding their job duties and be paid on a salary basis at not less than $684* per week.

https://www.hourly.io/post/salaried-employees-overtime

> Under the Fair Labor Standards Act (FLSA), any employee that’s categorized as an exempt employee is ineligible for overtime pay—even when they put in more than 40 hours of work in a week. Because many salaried positions are categorized as exempt, they would fall under the overtime exemption umbrella—and, as such, not be entitled to overtime pay.

Well, frankly, they are gone because the raise they get is less than competition will pay time right from the start at new job.

> So many times — easily multiple times per week if not per day — I am having to answer "ah, that system. Alice would know the answers, be able to guide you, is the resource you need … alas, she left/was laid off." We'll get the job done without her, but it'll take us 5×? 10×? as long.

I think that in particular is problem with knowledge transfer and retainment, sure, it will usually take longer for someone else to pick up but it should be documented enough (and cross-trained if needed) that it isn't x10. After all Alice might just be on long vacation instead of leaving the company and stuff shouldn't stall because one person takes a vacation.

> We'll get the job done without her, but it'll take us 5×? 10×? as long.

This begs further reflection.

Is it because Alice was amazing? Is it because the code is bad? Is it that the other engineers aren’t seasoned enough? Maybe that system is badly implemented.

Also, people leave all the time so you have to be ok with an Alice leaving (or die). You cannot depend on people being around for ever to ensure continuity.

Sometimes places have high turn over because they ask people to move fast while cutting corners because have high turn over and don't know how long people will be there and so they ask people to move fast while cutting corners because they have high turn over...

No, it's because people who have a lot of experience with one thing tend to be better at that thing, regardless of how good your documentation is.

It's like levels of caching. Having information in someone's head is like having it in an L1/L2 cache. Having documentation is like having the information in RAM. And having no documentation and putting things together from scratch is like hitting a hard drive.

That's an amazing similitude, I must note it down. I reckon the last bit could be even "got to fetch it from the network", since you'll likely have to hit Stack overflow..

To stretch out the metaphor, asking a knowledgeable coworker could be "read from RAM", then documentation could be "read from disk"; or vice versa. But I find having someone to bounce questions off of easier than reading docs

I'm leaving a role where I've been the sole supporter for 5 years of a Windows app written by amateurs. Every antipattern you can imagine if in there.

I compare it to a maze that I've traveled many times. I know my way around the maze, but I don't think the team that I'm KTing this too is going to figure it out.

I predict they're going to just freeze the code and leave any existing bugs as is.

Generally it's because nothing is documented. All the knowledge about a system is in the previous employee's head.

Now it all has to be pieced together from what code and configuration exists. Nobody documented the shortcuts, the rationale for why it is coded/configured that way, or the quirks or bugs in the system.

Of course none of this can be put into a spreadsheet thus it doesn't exist, as far as management is concerned.

There is no real way to document a large software system even if you wanted to. You would have to update the documentation every day assuming someone is going to read and digest it even if you make it available.

It was because Alice had experience and familiarity with it, which was lost when she left.

So the answer to GP's point "Also, people leave all the time so you have to be ok with an Alice leaving (or die). You cannot depend on people being around for ever to ensure continuity." would be that if the trend was for people to be rewarded for sticking around longer, even if alice quit there would on average still be a Bob or an Eve with the same level of experience in the team who could hanlde this?

It is because Alice knows the code, so she does not have to spend time figuring it out. It is because Alice knows what was important requirement and what was emergent property, so she knows what she can sacrifice.

It is because Alice knows how to log in, where to click to get to the right place and what to fill into fields to enable the button.

Sure, someone can do it. But Alice had spent several months becoming an expert on that particular part of the software. She knew the domain, had good contacts with the micro-service owners, knew the API off by heart and of course she wrote the code. All of that can be learnt again but it will take another few months. Now the feature that would have taken a weak takes seven weeks. Would it have been cost effective to have two engineers becoming experts at the same time in case Alice left? No. Will he carefully written docs she left help? Maybe, but until we have another expert on that feature, every modification will take much longer.

I thought about remarking on documentation, but I wanted to keep the comment brief.

Even where we have documentation, what experience buys you — what Alice in the example has — is that she's going to the documentation to spur her memory, as a quick double check, and just to give her a good guide rail to make sure she hasn't missed anything. But because she knows the area, she can still be quick about it. Someone new to the system are stuck using the docs not for reference, but for tutorial and basic understanding. They're going to need to read every word, and worse, comprehend every word, and that will take far, far more effort than the "I'm a bit foggy on detail D, what did the docs say? Oh right." that Alice would be doing.

But let's accept your "Maybe that the system is badly implentmented" — quite possibly! But it's the experience of having worked with it, learned how it modeled its problem, and learned how its model falls down and then, finally, that insight into "this would be a better way". That takes time and understanding, if you want to build a next system, particularly one that avoids a second-system effect.

Oftentimes, the questions or problems are of the form "we have tool X, and it does job J, but we have this other job, J', and it's … sort of like J? Can tool X do it?" Now tool X has never encountered this particular problem — by definition it cannot be documented — and it might be we need to change tool X. Again, experience makes this take a lot less time. Even for a well designed system, it still requires someone new to it to dig in and figure out first how it ticks before they can even approach such a question.

The reality is, of course, far less rosy, and there are many places where the docs could be better, often a lot better. But we've lost the most qualified person to improve them!

An upside is that it pushes companies away from crappy legacy internal systems to high quality open source or saas.

Hmm I don't know if that's an absolute. Really depends on everything in the details.

Business rules are usually what drives complexity, and a spaghetti of interlinked SaaS is unlikely to be better than a spaghetti of code you have full control over, at least if you have a software team.

But the details matter a lot. Some businesses are better staying as just a spreadsheet instead of trying to bring in or build software. Some businesses really do need custom software for their business requirements.

I meant more ancillary things like custom source control, custom testing frameworks, custom database, custom build tool, hand configured servers that only Alice knows how to provision, maybe even a home-grown programming language.

Edit: Since the original article is about Google, I should perhaps clarify that Google is big enough that it can do get away with having all or some of the above. But they are wise to open source most such things, so that they ensure their versions stay competitive rather than becoming a drag.

Yeah that's fair enough, there are a lot of third party and open source toolchains and frameworks to use now. One of the big benefits of using a framework is distributed knowledge and hiring people who already know your stack.