Hacker News Reader

I don't disagree, hence "fake work" in quotes.

Some people may (and clearly do thrive) in such environments but I personally did not.

This particular scenario was a simplified excerpt but very well captures my perceived experience. Having to write a design for for something that was a solved problem (by a team maintaining a framework) felt like pure busy work.

If there was a higher meaning to this process this higher meaning (other than looking good / getting promoted) was not communicated in any effective manner.

Maybe I'm dis-illusioned with the current culture in big-tech but a promotion should be a result of doing good work, not doing work that is designed to look good.

And yes I understand that some of these mechanisms may exist to provide employees a clearer path for ascending the corporate ladder.

Sad to hear your team was like that, mine definitely went the way of "if you know which way you're going to solve a problem anyway, why bother writing a design doc?" and I never felt burdened by them.

Good work needs to look good in order to be seen. And in enterprise, it needs to be able to be compared in order to be fair and afford some level of control from top down.

Standards solve those problems at the cost of some overhead and waste, due to being what they are: a fairly generic reification of best practice (at best).

Even though some overhead is just inherently part of the game, the efficacy of standards (and metrics) does vary. Not all have equal merit. And it does sound like some of the Google standards went off the rails a bit.

Oh I’m not a big fan of it either. Especially because I’ve never really seen a lot of the “fake work” have much value. Usually enterprise architecture or whatever you want to call it ends up being an insane amount of aged documentation that is useless because it’s never updated despite the best intentions. Over the years it’ll typically also erode its own standards as the people leading the efforts change and their standard preferences change with them.

Last but not least, it’s a total waste of time to have actual developers do it. Instead of working on something useful. Of course the challenge then becomes that 90% of the architects and whatever actually don’t know how to write their own design documents from changes, which means they need to waste developer time to do it… meaning that no only are they a completely useless employee they are also wasting the time of useless employees.

This shouldn’t be taken as black and white. As I wrote earlier, it can be done to help work flow. It’s just than in reality these processes usually end up doing far more harm than good. But if you, are, going to do it, at least enforcing standard is the right thing to do.

I personally avoid working at places with too much bureaucracy because I don’t want to waste my time writing documents nobody will ever read after they are approved.

> You have a point in that bureaucracy can needlessly get in the way of meaningful change.

What a good early design doc can do is turn meaningless changes (e.g., doing a project for the sake of promo) into meaningful non- or minimal change. The best code is the one not written.

And at least in my area (Core), the design docs only go through anything like a formal process when it's a larger project that would take years or multiple engineers. Other areas are probably different.

What you said would make sense if they weren’t forcing the author to go find more alternative approaches.