asterisk_
To get _truly_ self driving UIs you need to read the mind of your users. It's some heavy tailed distribution all the way down. Interesting research problem on its own.
We already have adaptive UIs (profiles in VSC anyone? Vim, Emacs?) they're mostly under-utilized because takes time to setup + most people are not better at designing their own workflow relative to the sane default.
It seems the above poses another question; is diabetes just confounding other underlying condition(s)?
Further, if most of the patients suffered from type 2 diabetes, it would likely correlate with older age in which case higher fatality rates are to be expected.
I was unable to find this info publicly available, but diabetes being one of the "2+ underlying conditions" seems probable.
The entirety of engineering is premised upon leveraging powerful abstractions; cf. the reason we're not still coding via electric charge.
Edit: To expand on the analogy: "A two-person startup already uses twenty-eight other tools" [1].
You perform the task of vision 100% of the time driving. From a purely probabilistic standpoint, even assuming highly accurate ML, the relatively infrequent database updates still make for a sensible prior.
This is somewhat adjacent to what Gary Marcus has been arguing, and I think it makes a lot of sense; there seems to be no compelling reason to rely exclusively on primitives (i.e. vision) when good priors are easily accessible.
As for idea rediscovery I'm personally happy with the setup I devised for myself so I can only suggest trying to emulate something similar. If you're interested, some guiding principles I follow:
1. My note-taking app (Vim, but could also be the browser or anything else) is constantly open in the background, and I have a keyboard shortcut to show/hide.
2. I maintain an index document of sorts (with TODOs, recent thoughts, outward links). This is frequently updated and I don't think too much about categorization.
3. Either Markdown `#` headers or `*` are mapped to Vim folds, which allows me to use `zm` and `zr` to quickly expand and collapse document outlines.
4. Treat tags as a "brain-dump". Just quickly come up with some keywords before starting to write the note. If you do that, I find even simple tools such as ctags and grep immensely help with future rediscovery.
5. Backups are on GitHub so I have the double convenience of both tracking document history, as well as being able to access all notes from mobile.
It's served me well thus far; most commercial note-taking apps will handle (4) and (5), while (1) is easy to resolve (e.g. AutoHotkey on Windows) so there's probably no need to make drastic changes to your setup if you wish to try it out.
It's an area I've recently been researching and they do seem to be gaining a significant amount of traction. If anyone is interested in additional reading material, I can suggest the very recent GNNs: Models and Applications (slide deck available on the website) [0].
There is also a fairly comprehensive GitHub repo on [1], though I personally haven't given it a detailed look yet.
[0] http://cse.msu.edu/~mayao4/tutorials/aaai2020/
[1] https://github.com/benedekrozemberczki/awesome-graph-classif...
I've long been interested in the domain of "personal knowledge engineering" and this clearly seems a common thread within our community. As a brief overview of the "SOTA:"
* Emacs and Vim users skew towards Org-mode or Vim wiki.
* Roam Research is sort of a recent web-based alternative.
* There's a lot of competition in the domain of fully-fledged note taking apps. Evernote has long been viewed as a king of note-taking but lost its edge over time (bad editor, bugs, lack of attention to their users). Memex seems to be gaining popularity even though their software looks somewhat buggy at the moment.
* Otherwise, people naturally develop their own (similar) systems. I myself have independently developed a custom-made Vim wiki before starting research into this topic. It basically consists of a few grepping/Vim aliases to search/create Markdown in a `~/.notes` folder, backed up to GitHub. `mod+-` is bound to an i3 sratchpad where Vim is constantly open to `~/.notes/index.md`. This drastically reduces friction when making new notes.
In any case, seems interesting that a lot of the personal note-taking systems have separately adopted similar principles to what Zettelkasten proposes:
1. Heavy reliance on tagging
2. Some sort of deep linking
3. Preference to making small, independent "knowledge chunks"
Do you have some specific examples the people you spoke to frequently criticize regarding Harari?
Assuming you trust your unit tests, you can claim a passing test suite means: (1) given current understanding, the code is most likely correct and (2) based on the same assumption, other developers agree that the code is most likely correct, for the current version of the program
I personally believe randomness has a place (fuzzing), but should stay semantically distinct from unit testing for the above reasons.
Did you try to find an effective way to combat the lack of motivation, or was it just a matter of returning back to the office?
Would you agree most lonely remote workers also tend to be younger?
It's somewhat unfortunate that we don't have additional data on the respondents since it may provide interesting insight (e.g. confounders that immediately spring to mind are country of residence and marital status), but there's a natural tendency to drift towards "exploitation" of existing relationships as one gets older as opposed to "exploring" new ones.
For instance, Doist's founder [1] cites being able to spend time with his son every morning as a major advantage.
In any case an even greater push towards remote work seems inevitable, especially as the tech workforce grows older.
The summary says it well:
> don’t over-invest (financially and technically) but also don’t try and outrun the liabilities
(0. The debugging approach can depend on a person's mental model)
1. Readability - even for a beginner, the method name should give a fair indication of what the code does. If the method name doesn't give a good indication, then the name should be changed. Otherwise, the comment is redundant.
2. Staleness - imagine a commit which changes the behavior of Engine::Compositing::onFrame(Deltatime) to only notify some of the components about the new frame (comment currently states "// Notify all components about the new frame"). Presumably, this commit should only change the internals of the onFrame method. However, because of a redundant comment, the person who changed the onFrame method now also has to find all its invocations and possibly update many comments.
My personal preference is commenting only domain-specific code chunks (example: [1]). These code chunks are usually put as close to the implementation as possible.
This way, whenever someone wishes to change the code, the person (1) immediately notices reasons behind the implementation (and may decide against modifying the code if he/she was unaware of these details) and (2) can modify the comment right away in case domain-specifics have changed in the meantime.
I'm curious to hear your or someone else's opinion against this argument?
[1] https://github.com/tkukurin/lesshint-intellij-plugin/blob/ma...