site banner

Friday Fun Thread for November 1, 2024

Be advised: this thread is not for serious in-depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.

1
Jump in the discussion.

No email address required.

I'm in my 40s and believe I'm finally hitting my stride as a young cranky old man. What did it?

Working at a company full of Python developers using Google Cloud.

OMFG I do not care about

  • Kubernetes
  • Terraform
  • cloud triggers
  • Celery jobs
  • Python in general
  • anything that ends with .yaml
  • Docker

It's not because I don't know these technologies and can't handle it. It's because they're stupid. They seem like they were some half-baked approach done by someone barely competent at the task they were given and bam they're now the industry standard and we all need to use it and everyone frowns at you like you're an idiot if you think people shouldn't be forced to huff that original barely competent developer's farts all day every day.

Well, fuck that and fuck you if you agree with them. We should not tolerate the simplest things taking 100ms (or 5 seconds) or taking 100MB (or gigabytes) or 10 approved PRs.

I'm going knee-jerk write everything I possibly can in C++ from now on. I'm pushing straight to main prod. I don't care if it's not memory safe or difficult to reason about or not "best practice". I will use indomitable volition to solve the problem and when I do it'll be so much faster and I get to really dig in and be cranky and old and superior. Behold, this actually takes only 50 micros and uses 5MB of RAM and the Hertzner server costs 1/10th and the overall cost is 1/100th and this is right and good and just. While you're entering day three debugging some inscrutable GCP error I'm shipping.

I am elite and I know how computers work and this is how you do it. Sorry if you can't keep up, young whipper snapper :sunglasses: :muscle_arm: :smug_smirking_face:

Get. Off. My. Lawn.

Everything you listed except Celery is how I got into tech and make six figures now, lol. I don't know how computers work** since I don't have a CS degree and don't do tech stuff for fun (anymore), but I agree that a lot of people use the tools you listed terribly (especially Terraform and k8s, wtf). But I'm curious what your objections are to the tools you listed. How would you do things differently? Usually when I run into someone who pooh-poohs those tools, they're the sort of person who wants to write their own epic genius 1337 codegolf in-house tool that has zero documentation, is full of idiosyncracies, and will become someone else's pain in the ass when they leave the company in a year. And then it's a part of the workflow that I have to use/work with/work around/slowly start making plans to sneakily deprecate. I dunno, I'm in my mid 30s. Maybe in a few years I'll start to get crusty too.

**by this I mean I have only basic knowledge about DSA, time/space complexity, Linux internals, etc. compared to turbo nerds who spend every weekend contributing to OSS for fun

ETA: One thing that I think is lost on a lot of engineers is the value of legibility. Terraform might suck, but you can explain what it does to some dumb non-technical stakeholder or some mid/low-quality engineer. It has tons of docs, and there are lots of slick videos explaining it on YouTube. HCL sucks, and it reinvents a lot of basic programming concepts but worse (for_each), but it's pretty easy to get started with.

There's also the "nobody ever got fired for buying IBM" factor. As a manager, part of my job is pushing for new/better tooling. If it's something mainstream and there are case studies or tons of threads about it or some Gartner bullshit or whatever, I can budget approved easier. What I pick is almost certainly not the optimal tool/software, but I have to get shit done and I can't let perfect be the enemy of good.

This also comes into play with public cloud (touched on by @ArjinFerman). I've never worked anywhere that has fully optimized cloud spending, there's always tons of waste. But after the corporate card is attached to the AWS account, I can provision servers/containers/clusters when I need to, and I only get yelled at about billing once a year as long as nothing ever gets out of hand. Is it wasteful, inefficient, and dumb? Yes, but that's just a reflection of the wasteful, inefficient, and dumb nature of the vast majority of human organizations. It's not a technical problem.

tl;dr a lot of the devops/infra people know these tools are dumb/inefficient but the alternatives are endless red tape or deadlock.

Usually when I run into someone who pooh-poohs those tools, they're the sort of person who wants to write their own epic genius 1337 codegolf in-house tool that has zero documentation, is full of idiosyncracies, and will become someone else's pain in the ass when they leave the company in a year.

To use a toy example, discussing one aspect: lets say you have an app that needs to be up all of the time. A simple solution is to set up the app on one box and a standby on the next box. If it goes down, you simply respond and assess and confirm yes, the primary is down. Lets start the standby.

People absolutely cannot resist looking at this and saying well why do that when you can have the standby take over automatically. And yes I get it that's a reasonable desire. And yes, you can do that, but that model is so much more complicated and difficult to get right. There are frameworks now that help with this, but the cost of setting up an app now is still an order of magnitude higher if you want this kind of automation.

Unfortunately, the modern distributed computing environment is organized around the idea that everything needs to be as high availability as Google search or YouTube. This is the default way of standing up an app.

Maybe your business has one big bread and butter app that needs this, and by all means go ahead, but businesses also have like 100x as many apps that are just support or bean counting tools that absolutely don't need this that you kind of get pulled into setting up the same way. It becomes so difficult to set up an app that teams lose the vocabulary of even proposing that as a solution to small problems.

A simple solution is to set up the app on one box and a standby on the next box. If it goes down, you simply respond and assess and confirm yes, the primary is down. Lets start the standby.

Then the standby goes down, or doesn't start. Your next move? You start debugging shit when people around you run with their hair on fire and scream bloody murder at you, the system is down over 2 kiloseconds and you still didn't fix it yet, are you actually sent from the future to ruin as all?

And note that this will definitely happen at 3am, when you are down with the flu, your internet provider is hit by a freak storm and your dog ate something and vomited over every carpet in your house. That's always how it happens. It never goes the optimistic way. And then you realize it'd be cool if you had some tools that can help you in these situations - even it it means paying a little extra.

a bulk of my experience is in quant trading where every minute we were down cost tens of thousands. we actually did engineer a lot of systems the way I described just because they were so much easier to reason about and took much less effort to stand up and maintain

They are easier to reason about up to a point. Which a typical HFT trading setup will probably never cross, but a lot of other companies frequently do.

yes, and if we reach that point we will introduce the complex multi-master thing

but most things never reached that point