HEURISTIC #1
When in doubt, chose the adventure. (Credit: Nietzsche)
HEURISTIC #2
What’s the right thing to do here, versus the comfortable one?
HEURISTIC #3
To make a thing inevitable, do as much as you can right now. For instance, to make it inevitable to take a letter to my office the next day, I put it inside my shoes. (Credit: BF Skinner)
HEURISTIC #4
If it’s popular and most people agree with it, walk on. Interesting and unfashionable is where the real fun is - and, likely, the values of tomorrow. (Credit: Peter Thiel, and, again, Nietzsche)
The best software I ever worked on - software in which the customer never reported a single bug, and every requirement was met - could not have been done without the documentation. The documentation was part of the process of creating the software - the larger part, really.
Requirements, design, implementation, testing; all documented thoroughly, all reviewed and checked, each stage linked clearly to the previous and the next. One could literally trace a requirement from the requirements documentation, through the design, into implementation (which was done using literal programming, producing beautiful PDFs for humans to read - there was very little need for anyone to ever actually look at the actual pure Objective-C code that was fed to the compiler), and then onwards to testing, such that each individual test was linked to proving given requirement(s) that had been written down at the start; sometimes years previously.
The customer was so impressed that they asked us to take over from another supplier whom they were busy suing for lack of delivery of a piece of the same system. Our software was delivered on time, exactly to spec, fully documented from requirements to design to implementation to testing. The whole project ran for most of a decade.
It certainly wasn't easy. It required rigor and discipline and review panels and, I gather, somewhere between ten and twenty years' experience of creating software like that. It worked; the only software I've ever worked on in which the customer never reported so much as a single bug. The entire system could be completely understood down to the level of the code by reading the documentation, and when changes were required, the software engineer would begin by reading the documentation and upon opening the literal style source file, would find it just as expected from the design. I've never seen anything like it before or since.
They went all in, though, and took years to get there. One couldn't just take a modern, agile-style software shop and start doing this. It was culturally ingrained.
I certainly agree that in other places, I've seen some truly awful documentation that hindered more than it helped. I've seen system diagrams literally consisting of a square box with "server" written in it. Protocol documents that contradict themselves on the same page. I once was double-checking the wiring diagram for a cradle for a processor board, and disagreed with the voltage of a single pin; it turned out I and the other chap read the exact same line of text from the board manufacturer and interpreted it in completely opposite ways - one of us interpreted it as meaning the pin should be grounded, the other that it should be connected to the live rail. The documentation was so bad we ended up having to go back to the manufacturer and get a human on the line willing to go on record with the correct value.
Don't worry about it yet. Buy conventional - that's what you're eating when you eat out anyway.
> is that expensive? how cheap should I go?
Don't worry about it yet. Grab whatever is on sale to start. If you notice you don't like it, don't buy that brand again.
> finding the right recipes - how do I compare 20 different ones from the web?
Buy three cookbooks to start: Mark Bittman's "How To Cook Everything", an America's Test Kitchen cookbook that appeals to you, and a cookbook of a cuisine you enjoy that's popular on Amazon. Alternate between the three.
> Which are more healthy?
Don't worry about it yet. Whatever you cook from these cookbooks will be better for you than what you get from takeout.
> Dietary recommendations are all over the place
Don't worry about it until later. Get cooking first. Whatever you cook will be better than what you get later.
> finding out what I forgot to buy
This is a matter of making a list before shopping. I suggest buying for two meals max at first.
Nobody worried about most of this for thousands of years -- you don't have to worry about it either.
Back in the days of shareware, around 1985, I wrote a program called TXT2COM. It was a simple way of turning a text file into an executable. All a user had to do was run the converted com file and the text file appeared on the screen with full scrolling, search and save. I had my name and phone number embedded in the program.
My first problem was when someone converted the Constitution of the United States into a COM file, but made some typos. I got hundreds of calls.
Then someone converted a entire library of gay porn text files which resulted in some uncomfortable phone calls to my wife while I was at work.
I released another version without my name and phone number, but the damage was done. I can still find my name embedded on com files in old archives.
The program was eventually bundled with an edition of "The Art of Computer Programming" by Donald E. Knuth. He used it to wrap some of the text files on the disk that came with the book. He paid me with a signed copy of the book and a very nice letter.
HEURISTIC #2 What’s the right thing to do here, versus the comfortable one?
HEURISTIC #3 To make a thing inevitable, do as much as you can right now. For instance, to make it inevitable to take a letter to my office the next day, I put it inside my shoes. (Credit: BF Skinner)
HEURISTIC #4 If it’s popular and most people agree with it, walk on. Interesting and unfashionable is where the real fun is - and, likely, the values of tomorrow. (Credit: Peter Thiel, and, again, Nietzsche)