One of me and my PhD advisor got it wrong. When "120% slower" is vastly faster than "80% slower", there will be confusion.
699 karma · joined June 19, 2019
Pondered the estimation a bit more. The first two points of a group of 7 define a line. The probability of the remaining five being close enough to the line is just the probability of each being close enough, to the power of five. We can roughly estimate that probability as the "close enough" distance divided by the total area. Let's just normalize. Let's assume distribution within a unit square Some of the lines would not cut in a way that most of the "close enough" area is inside the box, but that's a constant factor and not to big.
Given n points and the probability p7 that seven points lie close enough to a line, we take the number of different sets of seven points, N7 = (n choose 7). The likelihood of a match is (1-(1-p7)^N7).
This is a very rough estimation, of course, but it gives some idea of the likelihood.
The universe has had a lot of opportunities to come up with wacky stuff.
You're conflating unit tests and functional/integration tests there. A unit test should test that a single function/method/class does what it's expected to do. The game design changes should change how they are put together, but not often what they do. If your setThingOnFire() method suddenly also flips things upside down, you're going to have a bad day. Instead your callers should add calls to flipThingUpsideDown().
I'm not even sure one could separate religious and non-religious purposes. I think there was much less of a distinction. Even in ancient Rome, the gods were involved in many everyday activities, it would surely have been even more so in the Stone Age
Also, survivorship bias.
I would love to see how it compares to regular software and hardware trigonometric implementations on various kinds of hardware through the ages.
* It empties my head of the immediate parts of the idea, letting me move on to deeper parts and more productive considerations.
* It makes flaws more obvious, especially to myself.
* It makes it easier to share these thoughts, especially with people in other offices. They usually give really good feedback.
* It gives me a much better idea of how much work is involved than if I just start coding.
* It usually points out some things I need to learn before I start coding - adjacent systems, appropriate tech choices, etc.
Yes, it's also good for promo, but a successful project is better.
I often get comments on how useful my docs are, so I think I'm onto something.
The worst case is really when even more time has been spent coding, testing, releasing, and integrating the overly complex design, and then it's extra work on top to get rid of it.
> Anywhere else I would have been grabbed after lunch and would have worked on defining the problem for a few hours with the team at the whiteboard.
I do that at Google regularly, often in parallel with writing the doc. Nothing beats talking with an experienced engineer directly.
What a good early design doc can do is turn meaningless changes (e.g., doing a project for the sake of promo) into meaningful non- or minimal change. The best code is the one not written.
And at least in my area (Core), the design docs only go through anything like a formal process when it's a larger project that would take years or multiple engineers. Other areas are probably different.
One of the things that had been problematic at Google is the creation of many more products than are really needed, leading to the infamous Google Graveyard. One of the reasons I have come to like writing design docs for my ideas is that a lot of the ideas turn out to be crap when they get written out. Quite a few are good enough that they have already been done, or close enough, which my colleagues can then inform me of. This is a very lightweight way of trimming out useless projects.
And no, Reader wasn't useless. Different story.
What you are talking about here are assumptions, which are usually implicit and sometimes not even part of the thought process. One purpose of writing a design document is considering and stating the relevant assumptions.
Protobufs explicitly do not have a built-in version system (though of course you could add an optional field for it), presumably because it is better to inspect the data than build in assumptions that a certain version overs a certain invariant.
Autoref itself seems a fine way of messing up your references and making your source code less readable. The beauty of naming is that you have the context at hand. Moving around blocks of text, or adding and removing text, happens throughout the process. With autoref, you now have to remember to _sometimes_ update the refs or get subtly different references. I wouldn't trust myself to get that right.
As for the generations, may I have the honour of knowing your age, my friend?