> The compiler is very picky, but once code compiles it gives you the confidence that it will work reliably.
> Sometimes I had trouble making the compiler happy with the design I was trying to use, and then I realized the design had fundamental issues!
I experience a similar sentiment all the time when writing Rust code (which for now is admittedly just toy projects). So far it's felt like the compiler gives you just enough freedom to write programs in a "correct" way.
I don't really do unsafe/lower-level coding, so I can't speak to much there however.
Also during the week devices are only allowed upstairs for homework use only.
How do you prevent them from going downstairs after you've fallen asleep?
If anyone is looking for games like this here are a few single player games I'd recommend:
Monument Valley
Mini Metro
A Good Snowman is Hard to Build
Gunpoint
Snakebird
Braid
Sayonara Wildhearts
Super Mario Run
Untitled Goose Game
Race the Sun
The first problem he encountered was that multiple connections couldn't both be using the database at a time without clobbering each other. "No problem," he thought, this is a good use case for micro services. A service sitting on top would ensure that there was only one operation being performed at a time.
Next, his problem was that the database would get corrupt sometimes when something bad happened in the middle of writing the file. His solution was to put the entire JSON format inside of a JSON string. If it could be parsed successfully, then he knew the whole file was written. Then all he needed were "backup" files for each table, in case the current one was corrupt.
Next, his problem was that querying and iterating through a large table performed badly, since it required parsing the entire thing first. Querying several times required the whole file to be parsed every time. The solution was to move SOME of the tables over to JSON-inside-SQLite.
EDIT: Oh yeah, the next problem was how to structure the data inside of sqlite. He decided to make a single table called "kitchen_sink" that held every JSON value. There was a column that said which "collection" it belonged to. There was another column that represented the row's primary key. So you could quickly query for a collection name, and a primary key, and get the full JSON row.
So the next problem was that you couldn't query quickly for things that weren't the primary key. So new columns had to be added called "opt_key1" and "opt_key2" where certain rows could put key values, and indexes could be added on those columns, so you could quickly query by it's first optional key, or it's second optional key.
My question is, why didn't he go for any of the existing solutions when setting them up would've still been faster than rolling his own DB-in-a-JSON-file solution?
Imagine developing apps on an ARM-powered macbook, deploying onto ARM-powered servers owned by Apple, specifically for applications to be used on MacOS & iOS devices.
I couldn't champion your bulleted points harder. Honestly, if I had a say in it, any tech writer working on developer documentation should be able to code/build/perform/use whatever task or api they're documenting without the help of an engineer. They should be able to read and understand code, and they should be willing to do so, even more so than the average engineer using some library code. They should be capable of understanding a library deeply and synthesizing and summarizing that understanding for users of the library.
Just as tech writers in the medical field need to know quite a bit about medicine, tech writers in software should be required to know quite a bit about engineering software. There's plenty that do, but there's also quite a few that don't--I think it's a side effect of the field's relative youth.
I really wish more writers would code and do exactly the things you mention, such as implement robust code sample testing, etc.
The ideal technical writer, at least for software engineering documentation, is a hybrid of a traditional technical writer and a software engineer[^1].
[^1]: This excludes user-facing software documentation, which is essentially a totally different field than those that deal with writing for developer or engineer audiences.
I'm not sure why this is, but I suspect that it's an combination of higher pay and an interest in writing code over writing documentation.
In my experience I would say that a good SWE will attempt to write good documentation, as having to answer questions in the future about how stuff works over and over takes more time than just documenting things properly the first time.