yallpendantools

Err...have you actually asked someone to get into a Cessna?

Also, "fear of heights" is a totally valid excuse. Fear is a gut reaction and may have nothing to do with one's justified true beliefs. Eg., I know spiders on probability won't harm me but there simply won't be any amicable co-existence between me and any arachnid.

Last I heard it was 10 or 11 but definitely not 0x3.

At the end of the film "Only Lovers Left Alive", Tom Hiddleston's vampire character comments on an artist they found performing in a bar in Tangier "I hope, for her own sake, she doesn't make it big."

I feel similarly blessed nowadays. I did try to play the fame game with my Github projects but I could never find a problem that enough people cared for to get any kind of traction. Or maybe I really just suck at marketing. Either way, I find myself still fulfilled when doing my personal projects. They are not "side hustles" or a "home lab" or a "software factory". They're really just small projects that solve a problem for me. A lot of it also has to do with my very specific decade-old daily personal driver running Linux; my reticence to guarantee support for Mac and Windows (beyond what Node or Python ships by default) could not be helping my case.

And that's fine! Software with an audience of 1 but really fits in seamlessly with my lifestyle. Plus, if I want to change something, I can do so with zero consideration for other platforms. The reason why I wanted to learn to program in the first place is because I wanted the computer to do what I want it to do. Bend to my will ye golem of bits!

Can you elaborate how this sanitizes input on a password field? What unsanitary password input does it prevent?

I think statement from TFA basically boils down to "stop enforcing maxlengths on passwords, neither in the form field nor the DB". I'm no security expert but I'm a `correct horse battery staple`-adherent so if anything, password fields should have a minimum length, not maximum. Short passwords should be what's considered dirty.

It's like watching flat earthers launch yet another experiment to prove the earth is flat. We already know the outcome, including the subsequent press release that has the words "very promising" and "flawed assumptions" in the same sentence. But this "flat earther" has billions to burn and enough clout to keep investors and the media in the carousel for the better part of the next few years.

I've been doing martial arts for more than 20 years, some in TMA, some in modern boxing/kickboxing. I have yet to meet an "out of touch Kung Fu master" in person. Nobody thinks they can clear the bar or win in a ruleset they haven't trained for. I mean I don't deny Frank Dux, George Dilman, and the DUST guy exist, nor do I support their claims. It's just that they are larger-than-life personalities to start with and I haven't met them in person.

Similarly, most of the programmers skeptical about AI---me included---don't really do so out of a threat to a domain we've mastered. The problem is, models, to this day, need supervision so they understand requirements, so they know where to properly look for prior art, so that they "understand" the existing architecture. That includes you, Claude. Our kung fu has been six months away from obsolescence since roundabouts 2022 and in 2026 they even rehired a bunch of out-of-touch kung fu masters.

> The introduction chronicled the evolution of swordsmanship and martial arts in general from pragmatic battlefield necessities to sports, historical curiosities, and hobbies.

Eh? Martial arts has always been a mix of utility and cultural artifact.

Greco-Roman wrestling flourished in a/alongside of military utility. Greeks and Romans had swords, shields, spears, bows and arrows. Boxing also traces its history all the way back to the Greeks.

Japanese, Korean, and Chinese arts developed in a society with, also, swords, shields, spears, bows and arrows. Notably these cultures often included weapons training ("kobudo" in Japanese) in their curriculum but that did not phase out the empty-handed aspect of the art.

Catch wrestling developed among sailors who would not be strangers to guns and rifles.

BJJ developed, well, today.

There has always been a component of sportsmanship and self-improvement in martial arts. Carmack misreads this introduction, methinks.

[MIGHT HAVE INACCURATE IMPLICATIONS BUT PRESERVED FOR POSTERITY:]

In Germany I don't think that counts. "Software Engineering" as a title isn't regulated (as kcexn is asking for). The German term "Softwareentwickler" more literally translates to "Software Developer" (as opposed to "Ingenieur") but I don't see companies having problems translating that in job posts and even contracts to "Software Engineer". I've never seen "Softwareingenieur" used tbf.

Getting into Germany as a Software Engineer (for app development) is also as relatively frictionless as it gets in comparison to more-traditional engineering fields.

Verdi is the German trade union so they have to make these kinds of distinctions about which professions they can represent. Don't quote me on this one but I think Verdi represents very little of the modern "app development" software engineers. I guess those who work for more traditional German industries like auto-manufacturing can fall under their umbrella.

---

[LESS INACCURATE EDIT AND MY THOUGHTS IN LESS WORDS:]

In Germany "Ingenieur" (Engineer) is a loaded term with legal implications so "Software Engineer" is "Softwareentiwickler" (Software Developer) instead. But really this is an HR sleight-of-hand trick. At the end of the day, getting into professional Softwareentwicklung is the same in Germany as in elsewhere that calls it "Software Engineering" (and IMO is what kcexn was asking about anyway).

I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those requirements that don't even need to be said.

Anecdata time...

There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla.

The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win.

After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs.

The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent.

After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go.

Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.