I remember when I left feeling funny that there were as many people working on metaverse stuff as were in company when I joined (like 16k), and it’s mind boggling to me now that the layoffs are affecting around same amount.
I remember when I left feeling funny that there were as many people working on metaverse stuff as were in company when I joined (like 16k), and it’s mind boggling to me now that the layoffs are affecting around same amount.
1. When capturing complex logic areas, especially if related to any areas that are related to money or legal considerations
2. When onboarding new people on any side who need to learn about or get context on a product (product, design, eng)
3. When you revisit a V2 3 months later and forgotten what decisions you made or why you made them
Lots of detailed specs to me sounds like a fast velocity of products and totally compatible with startups. That said, you also added the word "lots" that OP didn't use. It could just mean two or three!
Once all the interconnections are figured out and the mechanical engineers know what needs to hold what shape at what temperature and pressure, and the metallurgists know what chemicals will be touching the metal, and the power connectors to sensors are all numbered so you know how many you need and where they'll go, and the communications lines with what format and inputs/outputs they'll talk to at what voltage... to me a spec is the document that tells everyone where their little part needs to fit.
You have to do that downstream and collect it back upstream for larger projects, since the person doing it never has enough expertise. And then the spec negotiation between teams that don't really necessarily know what constraints each other has which need to be resolved so that people know what to design.
It's frustrating but actually writing down a detailed spec really does enable a lot of other stuff to happen. I'm sometimes blocked as an individual because of a team that's in my path but which isn't really in my field. Say, they do optics and I design the optical sensor so I need to know the optical power to expect but they have to do simulations and get information from the chemists and semiconductor test engineers first. I need a spec for what they want -- I need to know how low the light level is, how much noise there is, and lots of other little details too.
I don't know if that qualifies as "terribly meticulous" but in my experience skipping the spec step often means wasting an incredible amount of time solving the wrong problem.
That’s half the battle of writing code.
At our startup, the philosophy is to “first write code without writing code”.
This gives clarity of problem and proposed solution to weed out edge cases, before going too deep into implementation phase.
I don't feel the same about some of my years in tech. There are periods where I can't remember doing much of anything that could be called progress, even though I know that I was "meeting with stakeholders" and other ostensibly important things. There's this diffusion of responsibility that occurs in large orgs where everyone is micromanaging some infinitesimal slice of the mission while communication overhead and "following the process" consumes unimaginable amounts of time.
It's hard to not want to throw the baby out with the bathwater and desire some kind of self-governed organizational anarchy, but I'm not sure where I think that line is best drawn.