> everyone understands a different part of git and has slightly different ideas of how things should be done
This was a big problem that bugged me too, so for every team I've worked with I've created a few scripts for the team's most common version control operations.
Most devs, including me, are pretty lazy so they'd all rather run this script than go to Stack Overflow to figure out git arcania.
This helps standardize conventions too: Feature branches/linear DAGs/topic branches/dev branches/prod branches/whatever weird thing a team does they all just do that using the script so it's standardized.
(2) $region_Y'ers do things in a way I find unusual and/or distressing
(3) The cause must be a character flaw shared by all $region_Y'ers (<insert stereotypes of choice here>).
and your statement is still valid about this formula.
I think we tend to preferentially notice them when we're in one of the two regions involved, but in general the world (and so the internet) is full of this sort of semantically null comparisons about culture and stereotypes. I've started seeing these as idle chatter akin to "Hey, look at that weirdly painted bus". At most I'd respond with "oh heh cool" but I'm not going to spend any more of my energy trying to explain choices of bus colors to anyone.
Replying here because this matched my train of thought well.
I'm actually really curious to know if anyone has first-hand knowledge of a tinkerer (by this blog's definition) getting their work published.
As the GP said, understanding the rules is one thing, but demonstrating their understanding is another. And as you said, matching the style seems to be more important than the value of work that is demonstrated.
I see the value in matching terms, jargon, style etc just so the reviewers can standardize their thought processes. But as someone who's been a tinkerer for ages now it's hard to change styles for no immediate benefit.
This thread is somewhat framing this as ethics vs salary, but what I found most useful in your statement was the (somewhat implicit?) thought that there is often no ethical way to earn a salary for some programmers.
While this has not been true in my personal experience, I must say that I've been very fortunate in life. I can totally understand and see how this may be true for some programmers.
I wonder if, as an industry, there was a better way for us to handle such situations.
This is the most intuitive introduction to Kalman filtering that I've ever seen. Even just reading that part was the most enlightening 2-minutes of my entire month. Kudos to the author!
I don't understand enough about the ad business to answer this myself. If there's a legitimate reason to allow 3p scripts to run code - it would seem like creating a domain specific language that Google safely translates into JS would be so much better. Allowing 3Ps to run arbitrary JS just seems so shockingly wrong.
No amount of manual auditing can catch malicious code. It's way too complex for a human to parse.
Is there a legitimate business need that anyone's aware of to have code run in Ads? If so, why not use a DSL?
I'm not a legal expert and don't understand EULAs at all. I expected a "Datacenter" to be defined at some point but I didn't see a definition in the EULA.
How should one interpret this? Is a research cluster a datacenter? How about a rack of a few dozen machines I built by hand? I've been in university research groups that had both options.
Somewhat maddening to have a single line in the EULA that's so open to interpretation.
"Medrano worked with Urton over the next several months and the two compiled their findings into a paper which will be published in the peer-reviewed journal Ethnohistory in January. Medrano is the first author on the paper, indicating he contributed the bulk of the research, something Urton notes is extremely rare for an undergraduate student"
I read that to mean there's more, but it'll be published in Ethnohistory.
Which, coincidentally, is my main complaint with Make: It's way too easy to write shitty Makefiles. There are way too many wrong ways to do things. Arguably this is a community problem and not a tool problem, but it doesn't change the fact that most Makefiles are written badly.
I used Make professionally for 5 years and have since moved to other tech stacks that don't require Make but have tools that are far worse in every other way (cough Ant cough). But IMO the reason they win out is they are far less flexible, so there are fewer ways to do things, so they work better in aggregate.
Build tooling is something that most devs look at very rarely, so they never build expertise. Ergo, build tooling shouldn't require expertise.
If my theory holds out, I feel Gradle will become the new Make in a few years or a decade - very powerful but too many wrong ways to do things.
There's a more embedded/low-power device friendly language called NesC that's embedded in a (mildly popular) distro called TinyOS. https://github.com/tinyos/nesc
The compiler for TinyOS produces whole-program-optimized, statically linked binaries, which alone is worth it to me.
Perhaps there are degrees of dystopian-ness (not a real word?), and some people might consider our current degree more acceptable than others.
IMO the only thing that matters at the end is whether people _care_ that something like this is wrong and want to fix it, or if they treat it as as "outliers gonna outlie" so they choose not to care.
Without that level of concern, people who don't easily fit in to the mainstream find their lives increasingly considered less and less important.
Agreed there's a fine line. I somehow find myself a little further along the spectrum - Perhaps I'm jaded from dealing with too many recruiters who are trying to check boxes.
If I really thought this job was worth my time, I would've updated my resume to say UNIX and Linux, and then clarified during the first interview with a technical person.
So if the alternative was Scala I can see why Go may have helped tighten things up a bit.