101–110 of 152 posts
Engineers have used drawing for millennia and yet software developers seem to be completely unfamiliar with them. A good drawing will help people visualize the problem in an instant, and let people talk about the different options much more easily.
Earlier quoted context omitted.
Why does it matter when they read it? If they need more time for the meeting they can schedule more time. Only downside is that finding meeting slots becomes more difficult, but the total time spent doesn't change.
In addition to the reasons already listed (slowest reader etc) it's also good, at leasdt for some, to let new information sink in before discussing it.
Earlier quoted context omitted.
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
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…
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 therefore no way to evaluate claimed accomplishments on a resume.
Oh, you managed accounts totaling $24MM in accrued receivables annually? Sounds impressive, but what if every one of your peers were managing $30–40MM and you were well known to be a slacker? Etc.
It's much more useful to me to know what classes of problem you can solve and which tools / techniques / technologies you're proficient with toward solving them. Descriptive statistics do very little for me.
Earlier quoted context omitted.
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
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…
> Think of a design document like a proof in mathematics. The goal of a proof is to convince the reader that the theorem is true. The goal of a design document is to convince the reader the design is optimal given the situation. We don't need to veneer technical writing in faux rigour for it to be worthwhile. That's the silly stuff that belongs on LinkedIn. This kind of psuedo-rigor feels good to nod along to, but it…
Many will answer that it helps them think. But why do we need a formal process to think? Thinking is a valuable skill that should be practiced all the time.
Earlier 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.
Earlier quoted context omitted.
The problem with design documents is that they require maintenance which takes more effort than it solves problems.
Without fail, people who say this really mean "I am unable or unwilling to put in the hard work at the design stage to resolve uncertainty and will instead push these problems downstream to the development process where hopefully no-one will remember I'm responsible for the ensuing mess".
They usually follow the structure:
1. Solution
2. Context (problem space)
3. Alternatives + Details
4. Logic behind the decision for the solution (reiterating drawbacks)
5. Time/task breakdown (if applicable)
6. Closing remarks
7. Notes (usually only useful for technical audiences engaged in the implementation)
Earlier quoted context omitted.
> 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.
> 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.
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 meeting than an email because the low latency communication and additional signals from live communication make the discussion more efficient. 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.