I think if there was a rigid spec, it would work against one of the points made early on in this doc (which I think is worth taking note of):
> Rule #1 is: Write them in whatever form makes the most sense for the particular project.
This is an unsatisfying rule, but I think it's important because each team/problem space/etc. is different and too strict of rules can often lead to documents that may end up being shallow.
However this admittedly doesn't help with this other problem you brought up:
> Also, when design changes - these docs need to be updated.
... but that may be okay given a shared understanding of what the goal of said document is. If the goal is to gain consensus around an implementation (as opposed to it being a living document), the document may have served its purpose by the time that consensus is reached, even if later on the design changes. If the goal is to have living documentation of a system, then maybe the rough format specified in this article isn't correct.
One term I've heard for design documents is that they end up being a piece in a "Decision Log", which has helped me feel less bad if the document falls out of date. These documents end up being more point-in-time representations of the collective understanding/opinions of how a specific project/system was being thought of, and that has its own advantages even if it falls out of sync.
The first points here are absolutely correct. These documents are a way to communicate and get feedback (and iterate) on an idea with a group of people in your organization. Different organizations will communicate differently, and have different needs.
Despite there being a whole bunch of implementations out there, I had also written one a while ago: https://github.com/thebrokencube/yahnes . It does need some updating, but seems to work well enough for my use (plus, I just wanted to scratch my own itch).
Probably best to sort of consolidate some of these into a few really good ones, but we'll see.
> “But this is an elective service and our culture is taught to tip for elective services. And yet HQ doesn’t want to offend or dissuade customers by making the ability to tip more prominently featured for fear they may end up going to Uber. And so no drivers get tipped even when a passenger would like to give one. Maybe that’s more likely what’s bringing down morale.”
I never used Lyft or Uber until last week, and this was the most surprising part. I was trying to figure out how to tip the driver, and tbh I don't think I was able to figure it out. I ended up tipping them after the fact through the emails they send you, but it was very surprising as to how ambiguous that part of the user experience is.
With Lyft and Uber starting to take off a bit in my city, I was going to recommend it to some friends to make some extra cash. I don't think I'll continue to give this recommendation anymore though, if tipping is discouraged/hidden.
I've only used Uber, but my understanding is that the tip is built in. You choose a fixed percentage when you sign up, and that's the tip every driver gets. You can express how pleased you are with the service in your review, there's no need to do this through money. This model is a bit part of the reason I like Uber; tipping is an annoying, awkward, and outdated convention that I would prefer not to deal with.
I'd rather not have a built in tip as a customer. I don't want to tip someone who doesn't do their job well. I want to tip someone who does an exceptional job, and I may even tip them exceptionally.
Granted I've never used a service like Uber, so I can't directly understand where you're coming from.
IIRC, Uber solves this by letting you rate people after each ride. People who have less than (4? 4.5?) stars get kicked off the service, so if you rate them a 1 then you probably won't see them again. So, in theory, you should only get rides from people who deserve a tip.
That's definitely a legitimate model. At least my experience with Lyft was that you could either tip or review, and I don't remember seeing an option to set a tip percentage. Definitely agree that tipping is awkward though, I kind of wish so many people didn't need to rely on them to make livable wages.
Tipping is not discouraged or hidden at all. Its right on the screen. I always tip 2 dollars for Lyft. Last Lyft driver said the average was 3-7 but some people don't tip.
My suspicion is that the author was trying to distinguish total order of events vs. partial order of events. I feel like the reason vector clocks and the like were created was to deal with the fact that real-time is problematic in distributed system. There is some response from the author though on this question: http://www.bailis.org/blog/linearizability-versus-serializab...
I tend to agree with you. I find that certain people I know who are extroverts always seem happy, but you spend enough time with them and get to know them, it's more or less a facade and they're not any more or less happy than others. Just like anything else I don't believe this to be universal, but it may be more common than advertised.
Quality control, and speed. This may not be as big of a problem as it used to be a few years ago, but private trackers give you quite a bit more assurance that what you're downloading is what is advertised. Also, since to be part of a private tracker you have to maintain the ratio, many users set up seedboxes and just leave their torrents on, while this doesn't seem to happen quite as much on public trackers.
Normally if you follow a low-carb diet, you get your fiber from greens. I believe the statement was targeted more towards carbs like bread, pasta, rice, etc.
Ok, here it is. Technically, we don't need carbs. Whatever that means, it is what it is. Carbs are a non-essiential macronutrient.
We need some vitamins, minerals and what not as well as protein and fat. We don't need carbs. Some of those vitamins and minerals come from plants, which have, as we say in the biz, trace carbs and fiber.
When I'm cutting down for a photoshoot I go keto. I might not have a veggie for weeks. My bloods and panels all look fine. I mostly eat veggies b/c I feel bad for not eating them.
I do take a multivit every day and I'm eating plenty of fat which helps the colon move things along.
When I'm gaining muscle, I do eat carbs. Lots of carbs. But we don't need carbs.
Do you have any science to back up this bold claim?
And what are you claiming carbohydrates are? Simplex and complex carbohydrates - sugars and starches?
It seems like you're saying that we don't need carbs, but that eating a diet with no carbs means we lose out on all those foods that have other useful nutrients (ie green vegetables). So, we tend to eat diets that have carbs to get the other benefits. Is that right?
Why not just for amusement? Or to just see what interesting things people have come up with? Why does everything have to be "only towards this goal", what happened to just doing things just for curiosity's sake?
Do you have any suggestions on creating these contracts? Mainly, is it necessary to lawyer up before even starting to make sure your contract is bullet proof?
> Rule #1 is: Write them in whatever form makes the most sense for the particular project.
This is an unsatisfying rule, but I think it's important because each team/problem space/etc. is different and too strict of rules can often lead to documents that may end up being shallow.
However this admittedly doesn't help with this other problem you brought up:
> Also, when design changes - these docs need to be updated.
... but that may be okay given a shared understanding of what the goal of said document is. If the goal is to gain consensus around an implementation (as opposed to it being a living document), the document may have served its purpose by the time that consensus is reached, even if later on the design changes. If the goal is to have living documentation of a system, then maybe the rough format specified in this article isn't correct.
One term I've heard for design documents is that they end up being a piece in a "Decision Log", which has helped me feel less bad if the document falls out of date. These documents end up being more point-in-time representations of the collective understanding/opinions of how a specific project/system was being thought of, and that has its own advantages even if it falls out of sync.