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.
- 98
- 1
PaperclipPerfector
5mo ago
(text post)
1885 thread views
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.
Jump in the discussion.
No email address required.
Notes -
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
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
mainprod. 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.
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.
Definitely agree. One of the more challenging parts of my job is having to be the guy who who says, "Okay, you want this app to be HA... but why? If you can justify this to me and tie it to some positive business outcome that merits the extra engineering hours spent, we can do this. Otherwise, no." I've only ever worked on understaffed teams and so I've always had to be extremely judicious when allocating engineering effort. Most ICs want to do this kind of thing because it's cool, or "best practice," or they see it as a career builder/educational opportunity. FWIW in 1:1s I ask what their career growth goals are and actively try to match them with work that will help them progress -- so I'm not entirely unsympathetic to their wishes).
It also just seems a lot easier than it really is. There's the whole Aphyr Jepsen series where he puts a bunch of different distributed databases to the test that everyone knows are supposed to be good and correct and they fall apart miserably. Almost every single one. It's bad enough that people don't really understand the CAP theorem's tradeoffs, but the real world systems are even worse because they can't even live up to what they claim to guarantee.
If you really think your application has outgrown the directory tree of .json files or the SQLite instance, show me how you plan to deal with failures and data consistency issues. It's not trivial and if you think it is I'm not going to let you drive.
I feel like this is the unstated rationale for using every single cloud provider's API
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link