Live data from Hacker News

Writing a good design document

grantslatton.com

131–140 of 152 posts

Re: Writing a good design document

#131
post #30

> Amazon meetings start with the presenter passing out copies... of a prose document... The meeting starts with everyone sitting in silence, reading the document, and adding notes and questions in the margins with red pen. I've never worked at Amazon, but I've heard this a lot, and it always strikes me as an odd practice. Odder still is that it apparently works and everyone I hear talk about it seems to love it. You'…

They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings.

To highlight two ways to go about this, we can assign homework, or assign, for lack of a better word, meetingwork. We don't always know how much free time our colleagues have outside of the time we've scheduled for a meeting. At least by enforcing meetingwork org-wide, it is ensured that everyone has at least some time to read the docs and they're fresh in their mind, even on short notice.

You're right about "reading speed", but I think the common alternatives are no one knows how prepared anyone is vs a few people might not be fully prepared.

Re: Writing a good design document

#132

Earlier quoted context omitted.

What do you want to see, then? Colorful prose? I and a few others really did save my company 10 million dollars one year. It was in EC2 spend for a hadoop cluster. I can tell you how we did it and who did what. Yes it was actual dollars we would have otherwise paid to AWS, it is not funny money calculated by looking at sticker rates and ignoring our discounts (which were large). I'm proud of this and it was one of my…

I've only been a hiring manager once, and it was for a junior-level position so take that into account. When I read resumes, accomplishments meant next to nothing to me. I was looking for capabilities. Your EC2 example is probably an exception to what I'm about to say because EC2 is very well known and you can quantify the difference you made in real dollars. But, 99% of the time I have no frame of reference and ther…

> It's much more useful to me to know what classes of problem you can solve

There is somewhat less opportunity to bullshit on what problems you have solved than on what problems you can solve.

Re: Writing a good design document

#133
post #130

I used the following sources to create an RFC template (and promote the document culture across the engineering documentation): - https://www.industrialempathy.com/posts/design-docs-at-googl... - https://github.com/rust-lang/rfcs - https://github.com/kubernetes/enhancements/blob/master/keps/... - https://blog.pragmaticengineer.com/rfcs-and-design-docs/ Hint: tailor the process and template structure based on your org…

I'm broadly in favor of RFCs but they need to be dictated from top-down. That's easier said than done.

Most RFC committee debates ime devolve into firing squads in which the presenter needs to answer every question with pin-point accuracy and perfect context from the asker. Otherwise, they look unprepared and the RFC is negated.

This is allowed to happen because everybody is a theoretical co-equal in the process. Thus, everybody wants to have their say. You'd hope people would read ahead of time but there's always somebody who doesn't yet feels entitled to ask pre-emptive questions. It makes for very combative discussions.

The exception is when a double-skip manager stops that from happening and lets the presenter "make their case" and walk through the whole RFC.

Re: Writing a good design document

#134

Earlier quoted context omitted.

> But isn't that bizarre? I can't think of anything else where we need engineers to do something by a deadline, and we just resign to the fact that they won't do it unless we sit them in a room and babysit them while they do it. This is practically the point of meetings. Meetings exist as a forcing function to achieve communication that likely could have happened asynchronously but for some reason didn't.

I disagree. I think companies that have meetings like this have an immature meeting culture. Meetings are for low-latency collaboration, not information transfer. For example, reading a design doc is obviously more efficient asynchronously because everyone has different reading speeds and doesn't need everyone else in the room while they read. Arguing about tradeoffs in a design doc is usually more efficient in a mee…

> For example, if the design doc says we should do X but you think it should do Y, in an email I maybe have to enumerate all the advantages and disadvantages, but in a meeting, maybe you're convinced after seeing just 20% of my rationale.

This is organizationally inefficient. You should write these reasons down in the design document so that you do not need to rely on both of us still being employed 5 years from now to explain to someone who is evaluating the state of the system on why the decision was made. A design document must include justification, not just the final decision, -- that's obvious from the code.

What you're describing as "immature meeting culture" I would instead describe as "mature documentation culture". Different companies work differently of course, and if you're absolutely optimizing for latency and have relatively small groups of stakeholders, meetings are super efficient since you can make all decisions now. But if you're optimizing for throughput and have larger groups of stakeholders, more asynchronous (or entirely asynchronous), document/slack/email driven approaches.

I think the amazon approach is weird and somewhat childish, but I stand by "meeting is only necessary if the stakeholders haven't approved your design offline/async". For such meetings you can use the amazon approach, or you can assume folks have already reviewed and left open comments, and only address outstanding comments during the meeting.

Re: Writing a good design document

#135
post #130

I used the following sources to create an RFC template (and promote the document culture across the engineering documentation): - https://www.industrialempathy.com/posts/design-docs-at-googl... - https://github.com/rust-lang/rfcs - https://github.com/kubernetes/enhancements/blob/master/keps/... - https://blog.pragmaticengineer.com/rfcs-and-design-docs/ Hint: tailor the process and template structure based on your org…

Re: https://www.industrialempathy.com/posts/design-docs-at-googl...

> ... sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date.

Using R Markdown (or any Turing Complete documentation system), it's possible to introduce demarcations that allow the source code snippets to be the literal source of truth:

    // DOCGEN-BEGIN:API_CLASS_NAME
    /**
     * 
     *
     * @param arg 
     * @return 
     */
    uint8_t method( type arg );
    // DOCGEN-ENDED:API_CLASS_NAME
Use a GPT to implement a parser for snippets in a few minutes. Then invoke the function from the living document for given a source file, such as:

    `r#
      snippets -> parse.snippets( "relative/path/to/ClassName.hpp" );
      docs -> parse.api( snippets[[ "API_CLASS_NAME" ]] );
      export.api( docs );
    `
The documentation now cannot ever go stale with respect to the source code. If the comments are too verbose, simplify and capture implementation details elsewhere (e.g., as inline comments).

In one system I helped develop, we were asked to document what messages of a standard protocol were supported. The only place this knowledge exists is in a map in the code base. So instead of copy/pasting that knowledge, we have:

    MessageMap MESSAGE_MAP = {
    // DOCGEN-BEGIN:SUPPORTED_MESSAGES
    { MessageType1, create() },
    { MessageType2, create() },
    ...
    // DOCGEN-ENEDED:SUPPORTED_MESSAGES
    }
And something like:

    `r#
      snippets -> parse.snippets( "relative/path/to/MessageMap.hpp" );
      df -> parse.messages( snippets[[ "SUPPORTED_MESSAGES" ]] );
      export.table( df );
    `
This snippet is parsed into an R dataframe. Another function converts dataframes into Markdown tables. Changing the map starts a pipeline that rebuilds the documentation, ensuring that the documentation is always correct with respect to the code.

If a future developer introduces an unparseable change, or files are moved, or R code breaks, the documentation build pipeline fails and someone must investigate before the change goes onto main.

Shameless self-plug: The R Markdown documentation system we use is my FOSS application, KeenWrite; however, pandoc and knitr are equally capable.

https://keenwrite.com/

Re: Writing a good design document

#136

Earlier quoted context omitted.

I disagree. I think companies that have meetings like this have an immature meeting culture. Meetings are for low-latency collaboration, not information transfer. For example, reading a design doc is obviously more efficient asynchronously because everyone has different reading speeds and doesn't need everyone else in the room while they read. Arguing about tradeoffs in a design doc is usually more efficient in a mee…

> For example, if the design doc says we should do X but you think it should do Y, in an email I maybe have to enumerate all the advantages and disadvantages, but in a meeting, maybe you're convinced after seeing just 20% of my rationale. This is organizationally inefficient. You should write these reasons down in the design document so that you do not need to rely on both of us still being employed 5 years from now…

I agree you should document the decisions and discussions around them. I never said you shouldn't, just that the discussion shouldn't be entirely written. But you can discuss live and summarize the discussion in the doc after.

Relatedly, I don't think full discussions about the design doc should live forever in the design doc. When I was at Google, I hated reading design docs where every line had a convoluted, 20-message comment thread attached to it in the margins. When I owned a doc, I'd drive those comment threads to a resolution, write up a concise summary of the debate in the appendix, then resolve the thread.

Re: Writing a good design document

#137
post #30

> Amazon meetings start with the presenter passing out copies... of a prose document... The meeting starts with everyone sitting in silence, reading the document, and adding notes and questions in the margins with red pen. I've never worked at Amazon, but I've heard this a lot, and it always strikes me as an odd practice. Odder still is that it apparently works and everyone I hear talk about it seems to love it. You'…

> They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings. There's no difference in the amount of time spent whether it's read in or out of the meeting. At least spending the time in the meeting to read it, people are more focused on the topic at hand and the time will be better spent. Besides, I'd bet the fraction of those docs that are ready sufficiently ahead of the meeting a…

>There's no difference in the amount of time spent whether it's read in or out of the meeting.

I address this point directly in the comment you're responding to.

Re: Writing a good design document

#138

Earlier quoted context omitted.

> For example, if the design doc says we should do X but you think it should do Y, in an email I maybe have to enumerate all the advantages and disadvantages, but in a meeting, maybe you're convinced after seeing just 20% of my rationale. This is organizationally inefficient. You should write these reasons down in the design document so that you do not need to rely on both of us still being employed 5 years from now…

I agree you should document the decisions and discussions around them. I never said you shouldn't, just that the discussion shouldn't be entirely written. But you can discuss live and summarize the discussion in the doc after. Relatedly, I don't think full discussions about the design doc should live forever in the design doc. When I was at Google, I hated reading design docs where every line had a convoluted, 20-mes…

> Relatedly, I don't think full discussions about the design doc should live forever in the design doc. When I was at Google, I hated reading design docs where every line had a convoluted, 20-message comment thread attached to it in the margins. When I owned a doc, I'd drive those comment threads to a resolution, write up a concise summary of the debate in the appendix, then resolve the thread.

Yes exactly, you don't need the entire back-and-forth, but the relevant information should be written down somewhere.

Re: Writing a good design document

#139
post #114

Logistically speaking, is there a good hosting service for design docs but have google docs-like functionality to be able to comment and share feedback? I increasingly use tools like cursor to iterate on design docs that are in markdown format and currently I move things over to google docs manually and when there is feedback, I need to go back to cursor which creates a slow and weird loop. Have people identified bet…

https://hackmd.io might fit the bill. I use it for some open source projects I work on, but don't really touch the advanced features.

Re: Writing a good design document

#140
post #132

Earlier quoted context omitted.

I've only been a hiring manager once, and it was for a junior-level position so take that into account. When I read resumes, accomplishments meant next to nothing to me. I was looking for capabilities. Your EC2 example is probably an exception to what I'm about to say because EC2 is very well known and you can quantify the difference you made in real dollars. But, 99% of the time I have no frame of reference and ther…

> It's much more useful to me to know what classes of problem you can solve There is somewhat less opportunity to bullshit on what problems you have solved than on what problems you can solve.

[deleted]
Post reply on HN