/me cries in range locks and mutexes
114 karma · joined February 21, 2014
https://pko.ch/
openpgp4fpr:7cf89adcda4cb27d18a943e4f6b4b93498a0c85d
[ my public key: https://keybase.io/pkoch; my proof: https://keybase.io/pkoch/sigs/pTAgxZGL55JuwoQtwte-63GtR0Y9gUM6GdDKFaPN-T8 ]
Don't push solutions from the outside. It's the "we're here to save you from yourselves" problem all over again. Instead, ask latin people what they want.
If you ask me, I want latin. Not latino, not latina.
> [...] AMD now has a market share of 31.3% (up from 28.5% in Q4 2021) versus Intel's 68.7% (down from 71.5%)
That's not "grabbing over 30%" in my book. It's grabbing 2.8%.
This is known to be great project management advice _and_ terrible relationship advice.
For interpersonal relationships, signaling misalignment early, directly, openly, with a sympathetic and reconciling demeanor, has been the best choice for me. Can't find sources anymore, sorry.
For projects, I won't expend more effort than what I have to.
Where does the project work stop and the interpersonal work starts, that's a vague art that demands a bit of intuition.
> Not 5 years later, and when it is someone else's code. Just don't.
That's precisely when you rewrite more: when the initial context is gone.
> Initialisms are no better than single char var names.
Correct.
> No one later is going to know you started naming "SmartFooProcessingThing" as "sfpt" and when they search for it in millions of lines of the codebase, they are gonna come up empty and waste time.
They're not meant to be grepped for. They're meant to be local, fleeting, names for something.
> There is nothing you should be finding "satisfying" in a non-obvious piece of code.
There is. When you understand it, it's satisfying. Or so has been my experience. There's also the frustration of "why was this left like this in the first place", but sometimes it's merely a matter of preference.
Please note that I'm advocating for rewriting and throwing away things you don't understand, not for leaving puzzles for others to relish on.
> And if you are working on team, there should be nothing "in your native style". Don't be that person.
Indeed.
The first source I found: https://archive.vn/q3VVx
Obligatory reference, given the aesthetic: https://archive.vn/mIwG0
My rule of thumb is to avoid variable names that are only used once. Instead, use something like pipeline operators, flow(), etc.
Another preference I have is to use initialisms. Might feel dumb at first, but eventually you realize (or I did, at least) that it matters more how things are "braided together" than having perfect names, and your editor prolly highlights all the uses of the variable where you have your cursor.
But, as always, prefer consistency with the rest of the team, even if you feel the rule is dumb. Don't proselytize. If the style really gets in your way to understanding the code, rewrite it and throw it away. There's something elucidating (and satisfying) in seeing a non-obvious piece of code in your native style.
Bam. Right in the kisser. This is the essence of it.
`git config --global merge.conflictStyle diff3`
If you ever wanna go back to the command line, your life will be much easier.
Looking for feedback!