If the last 9 months have shown us anything, it's that long-running government institutions are a lot easier to kill than we thought. And the idea of archive.org being under the control an administration like the current one in the US is pretty frightening. They would have absolutely zero qualms about deleting and changing that data.
That's the main problem with evented servers in general isn't it? If any one of your workloads is cpu-intensive, it has the potential to block the serving of everything else on the same thread, so requests that should always be snappy can end up taking randomly long times in practice. Basically if you have any cpu-heavy work, it shouldn't go in that same server.
Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.
> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI
For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well worth it. Stuff like bootstrapping new environments, some database-related work, etc.
I think everyone's got a different threshold for where returns start diminishing sharply. While I'm squarely in the "don't waste time micro-tweaking your editor" camp, there are some little bits of shortcuts and tooling that made me much more fluent at code-editing with very little investment. One example that stands out is the multi-cursor support that Sublime Text popularized (and which I use all the time in vscode now). It eliminates a good 80% of repetitive typing, or symbol refactoring that would have involved clunking through menus in old IDEs, and makes experimentation that much quicker. Feels fundamental, like copy/paste shortcuts which everyone knows now.
Whoa. That article says that SpaceX does tender offers twice a year?! That's so much better than 99% of private companies, it makes it almost as liquid for employees as a public company.
For sure, I'm not meaning to denigrate IMSLP, as it's a great project that offers access to so much material that's otherwise a pain to get to. I was just trying to make the distinction that when I want the highest-quality materials I can find for performance or study, that's not where I'll find them. But it's wonderful for quick easy access, invaluable for browsing and making finds when you're far from any university library etc.
Take from a musicologist and semi-professional performer: IMSLP is great for finding quick scores of random stuff, but the editions are often pretty shoddy, like either super outdated with weird editorial decisions that no one's agreed with for the last 50 years, or someone's totally amateur transcription full of errors and equally weird decisions. Treat it like you might treat Wikipedia as a research source (ok as an initial point of entry, but soon you want to dig into the real sources).
Yeah, our experience with Triplebyte really fluctuated a ton over the years. Made some hires pre-vetted by them who were real badasses and contributed a lot, but then there were periods when they sent us numerous candidates who could barely squeeze out a line of code and clearly must have gamed their process somehow. Feels like they were searching for some sustainable growth model and never managed it.
I work somewhere with plenty smart engineers, and plenty of in-house golang expertise. I've seen several small internal tools rewritten from Python to Go, and contributions by the wider team totally dropped off. It used to be absolutely trivial for anyone to make changes, and the "deployment" of such scripts was basically "get the code reviewed and merge it." Now there's a whole Bazel song and dance, compilation as part of the dev cycle, producing binaries for distribution, and it's introduced just enough friction that people no longer make the little tweaks that used to be dead simple. Say what you will about loosey-goosey dynamic languages, but they work superbly for things like CLI tools.
"Many teams in the industry constantly rewrite parts of their code. Not because they keep figuring out better ways of approaching the problem but because nobody on the team has an accurate mental model for how it works and how the code fits in with the rest."
This part rings very true, as someone who's been through plenty of rewrites / "make module X not suck" projects. A side observation here is that usually the original author (sometimes long-departed or departing) understands very well the limitations/flaws of the original system/implementation, but can be excluded from the design of the replacement for any number of misguided reasons. Trying not to bruise the ego of an early employee, thinking that they wouldn't agree with any changes, whereas those are often the people in the best position to guide a rewrite, and often would love the chance to fix some of the decisions they had to make originally.
Distracting Slack noise. I'm always a little annoyed when people do this and litter public channels. If you feel strongly about communicating your status changes all day, set your personal status - if someone wants to communicate directly with you, they can see that you're "out to lunch until 1:30EST! :foodemoji:" or whatever, but it's not proactively notifying everyone else who doesn't care.
From your other replies here you sound a bit burned out. 220 is easily within the reach of devops people in the modern software industry, and certainly not just at the big-name tech companies. But you do have to work for _some_ kind of decently-funded company if you want it as a salary rather than doing your own thing (consulting etc).
This past weekend I found myself in a mall in the East Bay (Bishop Ranch in San Ramon) and holy carp was it bumping with people, like a mall from before the before times. A big open central courtyard with families hanging out all over this fake grass, kids riding the escalator to gawk at people from the second level, I was like "what year is this?" A lot of the shops and restaurants were more bougie than those of past malls, there was a big Williams Sonoma, eating options included The Slanted Door, Mendocino Farms, Delarosa Pizza, so a far cry from the Sbarro and Cinnabon style of the classic mall. Maybe that's their secret.
What a bizarrely arrogant (condescending) way to formulate arguments.
"It is okay to feel provoked by this statement. As pointed out previously: you have probably invested a lot of time in Python. You will be inclined to justify and defend that investment. I would urge you to take some time to think about this and try to calm your urge to come up with counter-arguments. Let it sink in and try to be open to the possibility that this is how many users experience software written in Python."
I've been exercising quite regularly for decades, including a good amount of running alongside weights and other resistance and cardio. I love it, and hope I don't ever have to stop, but I've never experienced any sort of "runner's high" or big reaction to exercise, even after very hard or long workouts.
It wasn't just coding, it was also a lot of design/art resources. Going from 256->16 colors would look terrible with automatic dithering. My recollection is that there were a few Sierra titles made for VGA that also supported EGA and that it looked like someone had gone through each screen by hand to make the low-color ones look acceptable-ish.
Agreed. Personally I'm always grateful when someone joins and brings along a good up-to-date idea of how our particular languages/frameworks are used and taught by the rest of the world. It's so easy for a big internal codebase to devolve over time into a bunch of weird patterns, and forcing some newcomer/outsider perspectives onto it is a great corrective force.
I remember this too, from our 4th-grade "G&T" math teacher telling us the story. Although I use the formula so rarely that I don't keep it memorized, whenever it does come up, I think back to that day in class and that moves the gears enough that I can derive it empirically pretty quickly from small-number examples and the knowledge that it involves two consecutive numbers.
Forgive me if I'm stating the obvious, but it's a perverse incentive from the company's point of view. By the time the employee has gotten to the stage of getting actual offers from other companies, they've already gone through all the friction of the job hunt; at that point, the path of least resistance is in fact for them to leave the current job, otherwise they have to go through the new process of getting a counter-offer from their employer, with all the risks that involves too.