In my family we have 3 fridges, 2 washers and 2 dishwashers, and our experience a bit different than the rest of the thread.
The fridges are dead-silent and working great for 7+ years. Washers are also nice, washing for a bit too long but don't wear the clothes down and have better stain removal performance than their peers, and dishwashers are extremely slow and not designed for European market. Their baskets are not suitable for our dishes, we can't fill them efficiently even.
So, from experience their fridges are A-OK, washers are great with some caveats, but dishwashers are not good.
My first choice is still BSH group and Beko, but Samsung is acceptable if required, but LG? Ain't nobody got time for that.
It’s pretty well known in the US that LG washers perform better and have a far better parts and service network than Samsung. You think whatever you want though.
I'm not in the US though. The models, their performance and service networks are way different.
I have replaced shock absorbers and power switch of a 15 year old Beko washing machine last year, and it cost me 6$ plus workmanship to get genuine parts installed in 20 minutes.
I bet that won't be very possible over there, though.
My Samsung fridge worked fine for ten years and then broke down. Apparently it was the first generation of some new compressor or something and it was known to be problematic. The new ones come with an extra long warranty on that bit
The fridges we have at least 10 year warranties on the compressor, that's right. Considering the last fridge we had worked for ~20 years, I'm eager to see how planned obsolescence will play on these, yet they work pretty nicely.
My own Siemens fridge is with me for ~14 years, as well.
Trump yesterday said (paraphrasing) "I won't be pacing the AI. Instead I'll be supercharging it and making it Super Intelligence. This is too awesome to stop, and I like it, so no pacing".
If I remember correctly, the reason why Scientific Linux was RHEL based instead of Debian because RedHat was a company and can pay them for services.
We used to run it on our Grid nodes, and while it was not bad, it was not that smooth, either. It was a little kludgy but worked if you didn't diverge from the happy paths much.
Now Debian has Extended Long Time Support via Freexian, I believe CERN has enough confidence to use Debian instead of RH family, and that will make lives of some people way easier. Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
I realize I'm veering a bit off-topic :), but I've used Debian for a long while, but I do wonder how is that deb is more sophisticated than rpm?
The one feature I remember (a long time ago) rpm being able to install the different versions of the same package, although I suppose this in practice would only work for packages made for this, and libraries would usually be such packages. With debs this means the version number needs to be embedded to the package name with some developer-chosen precision.
This is still true from what I see, but in both families of distributions this is not a big requirement anymore. In my Debian based systems, libx264 is the only thing which requires multiple versions needs to be installed from what I remember.
On the other hand, RPM still doesn't know about reverse dependencies, automatically/manually installed packages, version holds, etc.
Either one is advanced enough to handle a big distribution and have their advantages w.r.t. each other, but I still prefer .deb as a person who works with both. Also, .deb can encode much more information about the software package it contains.
> .deb is a really good package manager, and is arguably more sophisticated than RPM.
Perhaps. I wouldn't argue either way, but dpkg still maintains its "data base" of installed and available packages/files as plain text files rather than using a DB format like sqlite (which one might chose for such today) or Berkeley DB (back when). The performance difference is negligible today on fast hosts with NVMe backed storage, but fairly annoying when using lesser machines with slower storage, e.g. RPi with root fs on a SD card.
I don't know the reasons behind the design decisions of apt. I know its workings up to a point, but not the history behind them.
On the other hand, I have been using Kingston Canvas Go SD cards on my Raspberry Pi boards for a fairly long time now, and these cards' random access speed is above and beyond of other, older cards while not being expensive.
Quite possibly! It was always a pleasure to see the ATLAS jobs running in a process list on an OpenStack hypervisor. We supported Lancaster University for compute (amongst others!).
You can pay companies just fine to support Debian.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
It's so bad. Coming back to RHEL (new client requirement) after sitting mostly on Debian for years is such a bizzare experience.
You want to install a PostgreSQL database, it doesn't even initialize it, you need to manually do DB init and the rest of the dance.
You want to run DRBD, sorry, we didn't bother to pick that kernel compile option, you can add extra repository for that. But hey, it's the kernel module, which means now you have to enroll cert in Secureboot, and that requires actual KVM access to the VM for someone to confirm it so now I'm on meeting with customer's IT just so they click some buttons in VM's boot process.
Even some common utilities are not in main repos but need EPEL
RedHat has a bad habit of dropping support for things not because they need maintenance but because they're just old.
I once installed a Sun workstation with AMD processor (Athlon64?) and nForce (4?) chipset. The ethernet card was there but it didn't initialize, why? Because RedHat EOLd the kernel module. Why? Because.
Reinstalled the thing with Debian after fighting it for 30 minutes or so, and the thing worked happily ever since.
> You can pay companies just fine to support Debian.
Yes, but this sentence didn't convince who was making these decisions back at CERN, approximately 20 years ago! I'm not even convinced that it was that possible and painless 20 years ago.
We agree about the rest of us, but I still ask why about EPEL stuff while writing salt recipes.
Update system, install EPEL, update system, install creature comforts is a such a bizarre dance to make while I can just write a one long apt command and get a better system in 30 seconds.
...and aptitude. Yes, that TUI thing. It's magnificent.
Subsection titles, and how the text flows. When I read these kinds of LLM-Powered posts, I feel the same thing. Like remembering the taste of some canned food which was not great, but I had to consume to stay alive. It feels like junk food, not optimized to taste great, but doesn't reek of machine oil either. A price-optimized, slightly unhealthy substance which is somewhat compatible with my body because of food engineering magic.
These posts are not only a waste of time, but it also makes me feel deceived and betrayed. Why this is important? Because it's the honest take and bears the load of the reality of the post.
Please, don't make me read something you didn't write.
Disclosure: This post, incl. llm-sounding paragraph is typed by a human. All of the keystrokes are 100% human and made possibe by burning ATPs and firing tiny lightning bolts across some brain cells. No humans are harmed or GPU hours are burned in this comment.
Total water consumption: 50ml of cold spring water, because I'm thirsty.
I just don't see the "LLM-speak" here at all, for example. And I'm very tired of people who throw around the LLM-power critique as an easy criticism when there's no clear basis for it. It's lazy and stupid.
There are certain styles for a post like this that some people may not like but things like subheads and what would be, by historical standards somewhat clipped writing are just how writing in this content is mostly encouraged theese days. I'd just add that when people do post long-form New Yorker pieces there's plenty of whining about getting to the point.
I think this mostly boils down to experience with writing styles. I am an avid reader, albeit mostly read in Ukrainian/Russian, but I can confidently tell whether some paragraph was written by Platonov or Nabokov or Zhadan or Sorokin; even when the guys are stylizing their texts (Sorokin does this all the time) there are still subtle things in how text is composed that tell you who wrote it. If my reading menu was mostly contemporary blogs, probably I would be less sensitive to distinct writing styles.
The first tech book I did with a publisher, I was pretty much told that I needed to break things down more with subheads and the like. And I was already doing some writing of whitepapers and blogs with my then-employer which had a somewhat similar structured style. Certainly very different from Dickens, Trollope, Collins, etc.
I'm not making a value judgement, but modern writing on technical topics has generally been steered toward digestible formats whether or not LLMs are involved.
Until I left, I was on social media and style committees at my former employer and there was a lot of data-based evidence around keeping things (in various multimedia formats) shorter and easier to consume. In fact, we mostly got away from writing white papers at all in favor of shorter pieces.
I don't disagree with you that contemporary technical writing, editing
and technical blogs were converging to what is known as llm style even before provisioning of llms. In the end, llm
were trained on these recent writing and recent blogs and this is why similarity exists. Still one can find some technical writing that stands aside and has very distinct style without compromising on clarity/digestability, i.e. Martin Fowler, Armin Ronacher, Michell Hashimoto write very differently from each other and Claude, but their content is always sharp and very much digestable. Take this paragraph by Claude
> Scientific Linux gave the scientific community its own implementation of a RHEL-compatible computing environment. More importantly, it kept alive the people, processes, infrastructure, and institutional knowledge needed to maintain one.
> That capability had option value. You might not need to exercise the option this year, or even this decade. It becomes valuable when the assumptions underneath your primary platform change. Those assumptions changed surprisingly quickly.
Can't imagine this lengthy style with paraphrases coming from Hashimoto or Fowler. Yes, it can appear not only in llm writing, but also in some heavily edited o'reilly book, sure, but I miss the times when tech blogs and o'reilly books were different.
Also, when you consider the age difference between the two, Wireguard is OpenVPN plus the learnt lessons.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
Before OpenVPN there was IP-in-IP encapsulation, which is as simple as a VPN can get (no encryption, but that hadn't been invented yet). Wireguard is basically IP-in-UDP plus encryption. You know what else is basically IP-in-UDP plus encryption? IPsec, and it really sucks, for the same reasons OpenVPN does.
I'll personally pay (and do pay) for good development tools. I prefer free software tools primarily due to ethical and philosophical reasons (and I also want my code doesn't depend on any tool which can't be obtained in the future), but I have a couple of non-blocker, high quality, yet closed source tools in my arsenal.
> if your employees do not care (they are optimising for salary & time spent not code quality)...
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
They don't care about maintainability because they're not going to be debugging it at 1am on Friday night but mainly because if something is wrong they have lots of people below them to blame for it.
Developers, however, are still responsible for the code! We must review the AI....all 80k lines of code it generated yesterday. If we don't then we are at fault. And we must go full throttle of course. So ....not be picky and retrograde about accepting what is generated.....
IOW we know who is going to get screwed and it isn't them.
Yeah but I mean, what is their compensation based on? I'm genuinely pretty curious about the point you're making here. I don't know anything about underwriting or how that profession works or how it is analogous to what you see as the future for software developers. But it seems interesting and possibly insightful.
I often have to ask myself if I’m asking for something different because of preference or need. I don’t really know what others are doing but I see this comment a lot about needing to always correct agents. I can’t figure out if it’s an exaggeration or not because once I’ve planned how I want something done I pretty much have zero need to intervene.
Impossible to know without doing a detailed comparison. Are you using the same LLMs? Are your criteria for correcting the output the same? Are you working on similar code? Are your plans and prompts the same?
It's fine to have preferences. The biggest problem with bikeshedding is the time spent (wasted) debating. But you don't have to debate the AI, you just tell it your preferences, and ideally encode them so that they are repeatable.
Of course it's fine to have preferences. I think you missed the nuance. Bikeshedding implies the time is wasted because the topic wasn't important in the first place. The color of the bike shed, as it were, has nothing to do with the storing of the bikes.
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
No I understand the nuance. But it's only bad to have preferences about things that barely matter if you waste time on them. You don't have to fight the llm, you just tell it what you prefer and it does that, that's what's great about them. (If it is not listening to your directives, then you have other problems.)
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
Directing an AI's work is not "fighting it". You keep characterizing it that way, but it's the wrong characterization. "Implementer" is not blurry at all. Humans are responsible for the things they implement, whether or not they use AI tooling to do that implementation.
Is that my characterization? This subthread is about how it’s so time consuming fixing every little thing the AI does to be just like you would have done. My challenge to that sentiment is “give it some freedom, don’t micromanage it.” That’s all.
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
Without going and re reading the whole thread, I'm pretty sure that both of your comments that I replied to included this "fighting the AI" characterization. It's certainly fair that you didn't start the thread about it but were just taking the premise of the sub thread. But I just disagree with that whole premise. I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like, and there is no long slack thread about whether I'm right about any of the things I've written into those rules, the AIs are happy to do as I've asked.
I think this entire analogy about being a manager of a team of agents that is in vogue is completely misguided. Have I always been the manager of a team of bash scripts? No. These tools are way more capable, but they are still just tools that I'm using to do my own work, they are not people that I'm delegating responsibility to.
> I think what's nice about these tools is that I can just write a document that says things like "prefer immutability" and then I neither need to micromanage nor accept code I don't like
Why are we even arguing then? You and I agree. Did I ever say "don't share a single preference with the AI"? You set the guardrails and preferences and the AI follows them. This is how it's always worked so it's reasonable for me to assume that people "fighting the AI" have already done this and are being overly pedantic about the output. Otherwise it wouldn't be eating up inordinate amounts of time...
> Have I always been the manager of a team of bash scripts? No.
No. You're not even remotely close here. Let's revisit this once you've figure out how to have a team of bash scripts implement 100k lines of code and build entire systems in 2 weeks based on high level instructions and requirements shared in context and prompts. You have responsibility at a different level and scale in an AI native workflow.
> From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Trends over time will drive more observable changes. If a whole generation of programmers picks up bad habits that their managers don't care about (think very junior), that will take some time to play out. It's like children's literacy. You don't notice overnight, but a decade of neglect and you have a reading problem in kids.
Yes, this is why it's good that we're having these debates. We should keep having them. Personally, I am not yet convinced that this is a real problem. But I also haven't yet worked on a team with people who have entered the field in the last few years.
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I think that's true but it's a special case. AI is here to stay and with AI coding IS faster and quality is better than ever before. Ideally you want your luddite fired along with the slop generators and keep the ones who are using AI and taking their time to deliver a maintainable code.
"Luddites" can just be the ones pointing out the Emperor's new clothes have a big hole in them. Removing them is just ensuring that whatever mistakes you're making get reinforced.
> ... with AI coding IS faster and quality is better than ever before.
Is this claim based on something?
I'm not against or "for" AI (whatever that means), I try to use it as effectively I can, but for me it's not at all obvious that quality is better than ever before.
Speed I can buy, especially in new projects and utilities, but quality? At least I haven't seen this in practice, if anything I'm just seeing more code, issues, PR's and pressure ==> more slop, more bugs, less quality.
You can always say "skill issue" and "process issue", but that's partly my point here, AI doesn't magically solve this.
Presumably it is based on that person's personal experiences, like your own comment and all the other comments here?
Speaking for myself, based on my own personal experiences, quality is by far the bigger advantage of these tools. It has never ever been easier to write automated tests and to automate tedious manual validation. I'm running my code through like 10x more paces than I ever did before, because I can just say "hey try running this in these twenty different ways" (including with browser automation, if that's relevant), without needing to either do the tedious steps to run all that or to take the time to write a script to do it, and to compile and attach the findings to the PR. This saves me hours to days of work on validation, but the reality is that I just wouldn't have spent that time in the past, I just stopped at a lower bar for quality, because I couldn't justify the ROI for spending all that time on it. But now the ROI is huge, so it's a no brainer.
If people are not taking advantage of this, then yes, that is literally a skill issue.
For some reason this reminds me A LOT of past discussions about microservices, most wonderful on paper and forever debated, but I've never seen it work out perfectly in practice, for me it's mostly been a cluster F in most companies that adopted them.
Currently I see AI similarly, in theory perfect, in practice I don't see the claimed effects. So yes, skill issue, but skills are relevant and your company probably can't hire a rockstar team (if that matters in the future).
But your comment on personal experiences was very good! Spot on, we are all biased, easy to forget. Thank you for that.
> If people are not taking advantage of this, then yes, that is literally a skill issue.
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
The octopus you just described sounds to me like an excellent example of what having the ability to more easily do tedious validation is most useful for. If you know that the "environment keeps on working", there must be some way for you to observe that fact. And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes. I find it so much easier to do this exact kind of thing now. Or, "easier" really isn't the right word. It's that the activation energy is low enough now that I'm able to do a lot of things up front that I used to rely on runtime monitoring to validate.
I guess YMMV, and it's not magic, but for me it totally changes the calculation on when it makes sense to automate something (like that chart from the old xkcd about how many times you'll do the thing and how long it takes to automate) in a way that means I'm doing a bunch of things that are useful for quality that just would never have passed the bar in the past.
> I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
> deploying and testing on real world is much easier and faster than letting loose an ML model on it.
No this is what you're not getting. It is "doing the things I would do to deploy and test in the real world, but faster and in the background while I do other things", it is not "letting loose an ML model on it". This is the new capability. If you have any process like "do {action}, wait until {something}, check {something}, determine if it matches expectation", it is now possible to run that loop way more times in way more variants without either spending the time on it synchronously oneself or writing a script to do it. (If you do that specific action loop often enough, it's probably worth writing the script anyway, but that's also much quicker to do now.)
The AI doesn't need training on the domain, it just needs to be told "these are the things I would do, please do them for me and report back".
I'm sympathetic to not everything being nail-like, but I really think you're leaving a lot of chips on the table if you can't imagine any of this kind of action-check-evaluate loop you have that you could offload.
I'm saying you could do more things. Instead of waiting until a new thing is merged so that it can be deployed and waiting for monitoring to catch issues, you could be deploying pre-merge to testbeds, using different variants of the code or different configurations of the whole system or different inputs to exercise edge and corner cases. Maybe it's too complex of a system to set up that kind of testbed or simulation? Well, it's easier to do that now too! I can spin up and down environments, either with containers on my workstation, or in cloud deployments, that I would have not attempted in the past, because it would have taken me too long to set them up. But now it doesn't take that long, and I find it super valuable to be able to try more things out. (Cost is still a real constraint, I'm not saying that constraints magically no longer exist.)
Obviously I have no idea what your work looks like! But what I'm saying is that time savings are not just time savings. There can be a point at which the time savings bring you under an "activation energy" such that it unlocks a new capability, not just a speedup. And some of those unlocked capabilities can be directed toward improving the quality of software. And I think that's awesome and useful, is my prevailing point here. I won't claim that it will usher in an industry wide improvement in quality or anything, but for me personally, I'm making better software more quickly now, and I'm very pleased that I can do that.
I fully agree with this point about quality. I am doing so much more testing than I used to, because I have so much more time to do it, and it's so much easier to automate the more tedious kinds of validation.
Maybe it's true that lots of people aren't taking advantage of this and are shipping trash, but that's their own problem, and there have always been people who do the job poorly.
That's true, but it doesn't have to stay in this form.
> with AI coding IS faster and quality is better than ever before.
Citation needed, because the last study I read about was painting a completely different picture about code quality. Also, just because the AI pulling and remixing code from a known repository with high quality doesn't mean your code will be at the same quality automatically. Passing tests is not enough.
> Ideally you want your luddite fired along with the slop generators.
The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this. AI doesn't know your history and trade-offs. These guys do, and can guide you to clear.
AI can't.
Believing that AI will create bug-free code from start is believing that Rust is the silver bullet.
The reason that we can (not that everyone, or even most people will) create higher quality software now is that it is now much easier to try out a bunch of edge and corner cases, which would have previously often required a prohibitive amount of time to set up and run. It's a dream! I can certainly believe that people aren't taking advantage of this, but they should be!
But I totally agree with you about the measurement problem. I think it's a very difficult time to be a hiring and firing manager.
> The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this.
This is exactly what I said in my top comment. This is a huge problem.
"Just do everything to hold things together, and let me abuse you without complaint" is exactly the kind of patronizing sentiment that infests the tech adjacent scene these days.
The answer to that is "Fuck you, no. I have worth, and you will respect it". Gilded Age paternalisms are not something that needs to be brought back into vogue unchallenged, especially when the intent is to keep the rabble quiet, and the checks rolling in and up.
No, the luddite is the person in one bad location on the continuum, opposite the AI psychotic on the other bad end of the spectrum. The person holding everything together is the one applying wisdom to the use of tools for the things they are good at while avoiding the things they are bad at, rather than blindly following one ideology or its opposite.
Sorry, but you're distorting my framing of the term in my original comment.
I labeled the person who uses AI to generate code and uses their brain and wisdom about the system to refine that code as the luddite since they will work slower when compared to other "higher performers" who don't care about the code quality.
In my framing I'm aware that the person is not a luddite per-se, but will look like it since they will be slower while trying to create better code, albeit using AI in the process as well.
Citing myself:
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
Chances are high the luddite is the one with the deepest understanding about the product and the code base - the one who is actually passionate about the project and actually cares.
Maybe? This does not seem to be in evidence to me. In my experience thus far, this seems to be way more of a personality and ideology split than a depth of understanding split. On my teams thus far, I've seen the deepest experts land on opposite sides of this question.
That could be the case. But if other companies figure out a way to deliver good code with AI, then the company with the luddites is going bankrupt. Luddites are better than slop generators, but both are worse against a developer with AI who actually cares and has a deep understanding of the code base and programming.
Well, and that's how you get enshittification everywhere. Everyone just cares about time to market, consumers are left to drown among a sea of slop, and honest businesses go down because they cannot stand a chance against slop peddlers flush with VC money.
Enshittification happens after the company was quick to deliver a working solution. They successfully captured the market, killed off the competition and now they are ready to start milking the customers who have no other choice.
AI slop can actually help with this, because it reduces the cost of replacing their enshittificated software.
The reason its hard to dethrone Facebook, Instagram, YouTube, Twitch, etc. Is not because it's hard to recreate the software (it may or may not be) it's because of network effects, budgets, etc.
And unless you have ownership level stake in the company, you *shouldnt* care about what happens downstream of selling labor to the company. Yes, I highly recommend 8 and skate.
Ive seen soooo many people burnt out, or "ive given years to the company and i got hit with layoffs", or "$200 software would have saved $1000000 when I brought it up to them". And companies will throw you away the MOMENT your usefulness is gone, even if just perceived. So, use them just as much as they use you.
And that idea of slacker is ALSO a way to generate more money for you, by slyly withholding or slowing work. I didnt get my paltry 3% last year. Inflation up 15% or whatever stupid number. But I can control how much work I do, so my effective wage/hour stays with inflation.
Save your caring for your personal projects, nonprofits you help at, your and family/friends labor you help with.
With some. You insisted, so let's get into the details.
1. Caring about the company when you are a worker and not owner?
Yes and no. I don't care about the company. I do care about what I do. It's a self-respect matter. I do good work not because I'm a slave to company, but because of self respect. My deal is simple: "I'll do my best to produce the best artifact and push the company further as long as it doesn't conflict with my personal principles, you'll buy that time for that amount of money".
I have a simple, foundational rule: I'll sleep sound at night, and this rule is rooted in my ethics. So, I don't shortchange anyone, incl. my employer. If terms change between us, we will discuss, but this probability is not a reason to do shitty work (or optimize for money, or which sugarcoated absurdity others name this).
2. Companies will throw away/layoff people with no notice?
Yes, this is bad. This is life. It's not nice, fair or acceptable, but without unionization, you can't act against this. So, you either try to change this or you just accept it. Realities of work life is not a predicament to shortchange your employer again.
This is as absurd as saying "I'll die anyway, why do all these things? I can just die on-demand".
Meaningless...
3. Work slowage (work-to-rule) as a counter to low/no pay raises in accordance to general inflation
We can accept that, but you all shall really unionize. It's not scary. Try organizing. It's a force multiplier.
4. Invest emotional and physical labor in ventures you gain completely out of
Everybody should have hobbies either productive or unproductive. I can't find the question.
There are companies where you can spend years doing as you describe. More and more, though, you’re competing with people who care even though they don’t own, put in the same effort YoY, and invest in their job. Companies love these employees.
So I guess it really depends on your values and what you want out of life. If you enjoy hobbies and time outside of work, sure find a job where you can coast. Don’t get frustrated when you get laid off just find another place to work. Etc.
Plenty of people want to grow within the industry and build a career, though. And many have what we call basic self-respect and care about how they are perceived.
> and aims to drive time to market metrics down aggressively with AI.
Go fast and break things has been a mantra for how long?
I think a lot of the laments about "good" code are really about "ownership" - and as someone who spent most of my working career in OTHER peoples code bases I have seen some things. There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
The increased cadence from AI is just speed running to the legacy code base.
The answer: express the concern, and reiterate it after every issue that arises because of increased complexity. Start building a plan on how to "unravel" the mess, how to migrate things in place, how to start drawing boundaries in your systems. The system is designed to reward heroes who fix problems - you want to be super man who stops the bridge from falling apart, not the engineer who pushes the costly fixes it before it does.
> Go fast and break things has been a mantra for how long?
Practically since eternity, but just as we learnt to manage current rate of "fast" and "breakage", somebody attached a solid booster behind us. So we're trying to understand what happened and what's happening and what will happen.
> I think a lot of the laments about "good" code are really about "ownership"
People owning what they did, have responsibility and initiative about doing better is always a good thing, yes.
> and as someone who spent most of my working career in OTHER peoples code bases I have seen some things.
I can understand that, I'm sorry you had to go through this.
> There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
My codebases are as great as my knowledge. I love when someone reads my code and points where I f'ed up. I also love to show what I did has achieved something I was aiming for and discuss how to achieve it betterer.
> The system is designed to reward heroes who fix problems...
And this is the problem. Because I work silently and diligently build something looking unimpressive while working like an atomic clock without any problems.
I have paid a relatively big price for a software which does a simple thing: Drawing diagrams. The application? It's called OmniGraffle Pro. That simple looking program drawing diagrams can do flowcharts to scaled architectural or industrial diagrams and everything in between.
Try replicating it with a couple of agents. Not the capabilities, but the performance, stability and dependability and sustainability as well.
Same is true for my favorite text editor on macOS, BBEdit, or IDE of choice, Eclipse. I can increase the number of examples.
These tools are valuable not because they are expensive. They are valuable, or indeed priceless, because of the polish they have. The small features make no sense for a beginner or how they cope when things get absurdly haywire.
Immediate features make us excited and they are easier to replicate because they are visible, but things like performance, dependability, error recovery or the small tweaks they have gone through in the last decade are not, and this is what matters.
We're exploring computing via AI again, and we act as that we did nothing in the last 60 years or so. Software and computing is much deeper than it looks at the surface, and we'll learn this in a very very painful way, again.
This. I happily pay for IntelliJ software (even though basically everything else I use is FLOSS). It is not really this feature or that feature of WebStorm that makes it worth while, but just that 40+ hours of the weeks it just works. For normal stuff, for edge cases, small projects, big repos. When I need something, it just works (with out me needing to fiddle with an agent to build me some brittle scripting that will kinda work today, but break tomorrow....).
The fridges are dead-silent and working great for 7+ years. Washers are also nice, washing for a bit too long but don't wear the clothes down and have better stain removal performance than their peers, and dishwashers are extremely slow and not designed for European market. Their baskets are not suitable for our dishes, we can't fill them efficiently even.
So, from experience their fridges are A-OK, washers are great with some caveats, but dishwashers are not good.
My first choice is still BSH group and Beko, but Samsung is acceptable if required, but LG? Ain't nobody got time for that.
reply