I often come across tips/pointers/exhortations about how to write good design documents. I generally agree that it's an important step: not just for clarifying your own thinking, but also for communicating effectively with others. However, these types of posts often lack are concrete examples of what a good design document actually looks like. I understand that many of these documents are proprietary and intended for…
The problem with design documents is that they require maintenance which takes more effort than it solves problems.
Writing a good design document
91–100 of 152 posts
Re: Writing a good design document
#92Earlier quoted context omitted.
> They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings. Amazon’s practice is a reaction to the fact that nobody actually does this. According to the article I read about this years ago, they realized that “creating a strong culture around reading before the meeting” also isn’t possible because many attendees had a meeting before this one, and couldn’t prepare for that meeting…
> Amazon’s practice is a reaction to the fact that nobody actually does this. 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.
Re: Writing a good design document
#93Earlier quoted context omitted.
> 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 Pretty much anything, unless you're in the engineer's management chain, or you've given them a direct incentive. It's always been my experience in bigco that people can ignore almost anything that doesn't come from t…
Then you should schedule two meetings: one in a reading room, at any time that fits each individual calendar, and then later the real one in a meeting room with everyone's involved, at the same time.
Re: Writing a good design document
#94Re: Writing a good design document
#95The structure I prefer for a technical design document is like a three-layer onion.The first layer is the problem statement, goals, non-goals, and requirements, both functional and non-functional. The next layer is the functional specification, which describes precisely how the system will work from an external perspective. The third and final layer is the technical specification, which describes the internals. Each…
Or a formal proof, e.g. when discussing secure protocols.
Re: Writing a good design document
#96Earlier quoted context omitted.
Not sure about the author, but having a few hundreds interviews under my belt (as the interviewer) some of those statements are incomplete. Your example is complete, but if I see statements like: "decreased latency by 5%" I will ask you if are we talking about median or long tail latency. Another example would be "developed a ML model that increased revenue by X%". Here it is missing how the population is affected. I…
You want all that on a resume?
Re: Writing a good design document
#97A reasonable starting place: The best design document conveys the critical aspects, requirements, and relevant information in a way the audience will understand and be able to further reason about.
p.s. Sorry for the complaint, I was a bit disappointed because this is potentially a really interesting subject! Why does cargo-cult content get such good traction so consistently? Cargo-cult driven design leads to some odd outcomes IME. Sigh
Re: Writing a good design document
#98Earlier quoted context omitted.
> Replace adjectives with data I think this idea got so pervasive all throughout tech that all the resumes that i now get are filled with so many numbers that i don't even know what to make of them.
If I get one more resume from a “seasoned professional” who has “decreased X by N%” I am going to close hiring, quit tech, and go be a hermit. N.B. I received such a resume while typing this comment and am absconding to Outer Mongolia as I type
So my impression is that they work sloppily and oriented more towards office politics than good engineers.
Re: Writing a good design document
#99> This disappoints the ego-seeking behavior of many engineers. Good engineers often want people to realize how clever they were.
This is probably partly true to a small extent, but for the most part I think it trivialises a larger problem.
I have had this exact problem as an academic publishing papers. My ability to write straightforward easy to follow manuscripts has backfired on me many times, whereby explaining the steps in a clear, intuitive order has led reviewers to state that the findings were non-novel since they were a clear intuitive series of logical steps. My (sad) experience has taught me that if you make the reader 'work' a tiny bit towards developing the intuition themselves, and appreciate how this specific sequence of steps wasn't necessarily trivially obvious before announcing it on paper, then they will appreciate the novelty and the thinking that went behind it a lot more.
Obviously I don't necessarily think the mass of obfuscated papers out there are academics intentionally obfuscating to prevent rejection and raise appreciation in their readers (it's more likely to be a lack of skill or interest in investing the effort to write more clearly). But (despite it's frequent abuse as a phrase) leaving _some_ things as "an exercise to the reader" turns out to not always be the 'lazy' or 'ignorant' thing to do.
Now, of course, design documents may not necessarily have the same goals or gatekeepers as academic papers do, but I think attributing leaving some steps up to the reader to be entirely about engineering ego-seeking behaviour is a bit misguided. If your goal is to make someone understand and appreciate something, then there is such a thing as "explaining it too much" (and thus robbing them of the experience of developing their own, and far more useful, insight).
And this is doubly true in teaching contexts (arguably not the usual purpose of a design document, but ...).