9 ms·

Design doc culture at google is why I left the company. I wrote a very high level doc shortly after joining the company outlining a fairly trivial task (one th

• devjab 2y ago
  You have a point in that bureaucracy can needlessly get in the way of meaningful change. It frankly always will to some degree. That being said, part of the way you make sure it gets the least amount of in the way is to standardise it, and actually enforce those standards. From your description you fall into both categories, which means your colleague was correct. Now, your amount of details is very scarce, so it’s extremely likely that I’m getting the situation wrong. But look at it from an enterprise level perspective or change management, if you allow slight deviations here and there for thousands of employees then you’ll very quickly end up with what would be the equivalent of the difference between Italian, Spanish and French. Which all shares the same Latin “standard” and then deviated ever so slightly. If you think there is a lot of pseudo work involved with managing the bureaucracy of enforcing a design doc standard then you should see just how much pseudo work it saves.
  • SSchick 2y ago
    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.
    • Degorath 2y ago
      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.
    • Lutger 2y ago
      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.
    • devjab 2y ago
      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.
  • kortilla 2y ago
    What you said would make sense if they weren’t forcing the author to go find more alternative approaches.
  • larsrc 2y ago
    > 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.
• gonzo41 2y ago
  The old school way of fixing that problem is to have a standing change order for routine work so you can point to it and say "my problem is just like that" and get the green tick right away. Though the moment you suggests things like change control people get all weird these days.
• dyauspitr 2y ago
  Then include templates from other areas pointing out the repeated work. You can’t just hand off a couple of lines in a brief to a dev, especially if they are not aware it’s been done before.
• t8sr 2y ago
  You get the behavior you incentivize. In the “early days”, design docs were a tool to agree on a direction and provide context to your coworkers about what you’re doing. Later, as new people joined at an exponential rate, they were told by well meaning managers to write the docs for perf reasons, and things kind of spiraled from there. Google’s culture became a cargo cult of itself. Some companies I worked at after Google were reluctant to discuss their promotion process in detail, because they saw what happens when people microoptimize for it.
  • deleted 2y ago
    [deleted]
  • Arainach 2y ago
    Microoptimizing for what the cargo cult believes gets you promoted is strictly worse than microoptimizing for what actually gets you promoted.
    • klabb3 2y ago
      It’s a meh from me - either is bad. If you are in a highly complex and professional field (in the traditional sense of the word) single axis optimization hollows out the whole craft. Engineering is delicate and constant battling of tradeoffs, and decision consequences are often delayed by longer than average tenure, let alone a 6 month perf cycle. The more you McKinsey the process, the more mediocre and incoherent the results.
      • Arainach 2y ago
        You get what you measure. You can't hire smart motivated people and then be surprised when they figure out to optimize for their rewards. If you want a team that lands stable customer-loved products, make THAT your performance review. Turns out that's hard to do objectively and consistently.
        • lupire 2y ago
          According to your other comment, then, a company that "lands stable customer-loved products" would be a "hotbed of nepotism" that people shouldn't work for.
• thisisit 2y ago
  I have a reverse problem at the place I work. When I ask people to write a very high level design doc for a fairly trivial task they go - "There many more way to get this done so writing these is useless. And as the task is trivial an engineer should be able to figure out one of these ways and do it." Many of these people are external consultants who have been working with the company for 15+yrs. So, there is a fair standard in place already because the tasks are done by the same people. But then they go out of their way trying to create a boogeyman of "what happens if people don't follow the standards?". The end result is that either design docs don't exist or woefully out of date. Hence the company has to keep hiring these same consultants year after year on hugely inflated costs.
  • Cthulhu_ 2y ago
    > Hence the company has to keep hiring these same consultants year after year on hugely inflated costs. There it is. There's good scratch to be made in prolonging the problem.
• jppittma 2y ago
  We do "one-pagers" if there's basically one, simple, straight forward way to do something; however, I'm with google on this one. If you're designing something, and there's only a single solution under consideration, either there's no design, or you're not being thorough. Choices and tradeoffs are what make design
  • wasteduniverse 2y ago
    [dead]
  • mewpmewp2 2y ago
    What if it is something really obvious and has been done so for last 20/20 times it feels almost embarrassing to consider anything else? You could list out the embarrassing methods, but it still feels useless work for show.
    • Jensson 2y ago
      Then it is just a change and reviewed through normal code review. Design docs is only for when you do something that isn't obvious.
      • mewpmewp2 2y ago
        But then you don't get promo?
        • Arainach 2y ago
          You don't get promo in your scenario either. A design doc for something that's trivial will be called out in promo packet review and not given much credence. If the packet is primarily comprised of such artifacts the promo will be denied.
          • lupire 2y ago
            It depends on level. For a junior, these are great design docs because they educate other juniors about engineering, and educate senior bad-doccers about good doc writing, and show developing skill in the art of doc writing, before the engineer has the additional cognitive burden of writing about something much harder.
• deleted 2y ago
  [deleted]
• jvans 2y ago
  the compensation structure in big tech makes people lose their minds optimizing for that next promotion/stock grant. It helps big tech retain talented people but the incentives to look "impactful" drive all the wrong behaviors
• pclmulqdq 2y ago
  The mistake was production of a design doc instead of just writing the code. If it's trivial enough that there's nothing to discuss, you generally just change the code. If it's complicated enough, it becomes a negotiation process where at least 5 different people have to be able to put it into their perf if you want to get it done.
• weezin 2y ago
  I'm dealing with this right now at another large company. Being asked to write a document for an integration we've done 20+ times because its part of someone else's larger promo project's design.
• brotchie 2y ago
  Used to feel this way on other teams. Almost as if you were expected to write them for the sake of writing them (cargo cult engineering). Now on a team of many OG Googlers (15+ years tenure) and Design Docs only exist when they’re needed (something that touches multiple systems, something that’s obviously complicated with many trade offs, etc) Otherwise it’s just “write the CLS.”
  • andrekandre 2y ago
    > Otherwise it’s just “write the CLS. (apologies for the noob question) but what is cls in this instance?
    • lupire 2y ago
      Change Lists (Pull Requests, Change Sets)
    • deleted 2y ago
      [deleted]
  • lupire 2y ago
    One presumes in those simple CL cases, there is already a doc for the system being edited, and the new code followes the design.
  • dataflow 2y ago
    > Now on a team of many OG Googlers (15+ years tenure) and Design Docs only exist when they’re needed This almost certainly has nothing to do with the team or tenure, but everything to do with what levels they are(n't) trying to get promoted to. Have you controlled for that and still seen a distinction?
• summerlight 2y ago
  This is likely due to culture established by the teams working on old, mature products. There, you're going to work with at least 10 people to launch trivial projects. In my case, it's usually 20~30 people with a blast radius of 100~500. You're not going to casually 1:1 with all of them since you and they are all busy. If you don't get a good review from stakeholders, there's a good chance that some angry folks will come for you and make you roll back your launch. In these contexts, design docs are meant as an asynchronous communication tool for information heavy topics. And this is so asynchronous, you will talk to those people join 10 years later if you product becomes so successful. I've been saved multiple times thanks to some random design doc from 2010 that explains the weird decision that still haunts us. This probably doesn't work very well on lean/small teams or less complex tasks. But engineering culture usually has its own rationale and context, even if it has become a cargo culture.
• rexreed 2y ago
  Another word for Design Doc = "Shelfware"
• iimblack 2y ago
  Couldn’t you just reference a recent doc and say this is mostly the same with these x differences leading to y alterations for z reasons?
• aprdm 2y ago
  I interviewed a couple of folks from Google recently and it was mindblowing how they "work", it's very unfortunate. I feel for some of the people who only worked there their whole lives (e.g: from recent grad within the last 5y), it is unlikely that they actually know how to program.
• menzoic 2y ago
  This isn't unique to Google. This is encouraged at Uber and Airbnb as well. I would think its a common practice. The idea is to show that you consider alternatives and did due diligence. Following the way its always been done isn't necessarily a good thing. If its a different product area there could be better approaches unique to that area. Its not fake work, it just proves you actually considered other approaches instead of blindly following status quo.
• m463 2y ago
  The problem with stuff like this is that it saps the (finite) energy of your team. Not everyone is a tank. High int lose their hit points and they're gone with all their mana.
• asdfman123 2y ago
  Right. > The decision whether to write a design doc comes down to the core trade-off of deciding whether the benefits in organizational consensus around design, documentation, senior review, etc. outweigh the extra work of creating the doc I'd argue that extra work of creating the doc is an upside because it clarifies your thought process, and design-by-committee is a massive downside. In fact, I happen to be writing this during a design-doc meeting. I am getting absolutely nothing from it. I was writing code all morning and the background noise now prevents me from continuing productive work.