To be fair, if I submit changes and don’t notice I added .vscode / .idea / my_notes.txt / .DS_Store / .swp then it was a sloppy job and I shouldn’t expect the project to adapt to ignore every possible garbage file so that I can continue carelessly “git add .”-ing
I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?
> it's positioning itself as a drop-in replacement for SQLite
While SQLite is often used for comparison (“SQLite for OLAP”), I’ve never seen DuckDB market itself as a “drop-in” replacement. Where did you see that?
> my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences
I have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality.
e.g.
- (a) chore: update some_module to include new_func
- (b) feat: Add new_func to handle XYZ case
Where:
(a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles.
(b) is using the correct "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language.
This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.
I was never very good on FPS games, but during pandemics I would play often with friends.
One day I pop up a practice map in cs:go where one of the challenges is shooting a fixed target after it turns green. If you don’t do it within 250ms or something (nothing crazy in terms of human reaction time), then you don’t score.
I was flabbergasted to see myself miss every single time. My friend even told me “dude, are you pretending? How are you so slow?”
So the next day I got a new mouse and what do you know, I’m actually responding in time, and scored most of the time when the rectangle went green. Just the mouse was not registering it fast enough.
Of course, that didn’t translate into such a huge boost in actual gameplay, but it’s impressive how that made me consistently miss. Likely it had some crazy 50ms+ lag.
> Only at small scales are full stack engineers valuable.
Seems like the ideal career is to start somewhere big and successful enough that allows you to specialize (after some poor generalists sabotaged their own careers by making it a thriving environment for specialists). Because even small scale businesses think they should start by hiring specialists.
It depends on your workflow. I sometimes find myself alt-tabbing multiple times to copy stuff over. Othertimes I accidentally overwrite my clipboard and lose some text that I was writing. Being able to recover it from the history is nice.
I use Pasteapp on macOS and FastKeys on Windows, which comes with other useful stuff, such as a shortcut for controlling volume by using the mouse scroll wheel on the right edge of the screen, macros, and a text-expander. The ones I use the most are:
I assume that’s why some open source maintainers don’t bother either - if you haven’t even looked at your diff before submitting then why should they?