thebrokencube
Joined 15 years ago
Joined 15 years ago
Probably best to sort of consolidate some of these into a few really good ones, but we'll see.
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.
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?
Oh man. This struck way too close to home, as it is was the biggest reason I didn't actually go through with suicide when I was at the darkest point in life. That feeling that you can't do anything right, even ending your already frail and delicate life: I don't know of many things more disheartening than that.
Your description of how it feels to be suicidal is very well written and probably the most accurate summary I have read in this regards.
> 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.