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
What is this place?
This website is a place for people who want to move past shady thinking and test their ideas in a
court of people who don't all share the same biases. Our goal is to
optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.
The weekly Culture War threads host the most
controversial topics and are the most visible aspect of The Motte. However, many other topics are
appropriate here. We encourage people to post anything related to science, politics, or philosophy;
if in doubt, post!
Check out The Vault for an archive of old quality posts.
You are encouraged to crosspost these elsewhere.
Why are you called The Motte?
A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently,
it's an element in a rhetorical move called a "Motte-and-Bailey",
originally identified by
philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial
but high value claim to a defensible but less exciting one upon any resistance to the former. He likens
this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for
the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired
propositions to which one retreats when hard pressed."
On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.
New post guidelines
If you're posting something that isn't related to the culture war, we encourage you to post a thread for it.
A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts
such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a
submission statement. A submission statement is required for non-text sources (videos, podcasts, images).
Culture war posts go in the culture war thread; all links must either include a submission statement or
significant commentary. Bare links without those will be removed.
If in doubt, please post it!
Rules
- Courtesy
- Content
- Engagement
- When disagreeing with someone, state your objections explicitly.
- Proactively provide evidence in proportion to how partisan and inflammatory your claim might be.
- Accept temporary bans as a time-out, and don't attempt to rejoin the conversation until it's lifted.
- Don't attempt to build consensus or enforce ideological conformity.
- Write like everyone is reading and you want them to be included in the discussion.
- The Wildcard Rule
- The Metarule
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.
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
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
More options
Context Copy link
More options
Context Copy link