1. Good design is innovative
     2. Good design makes a product useful
     3. Good design is aesthetic
     4. Good design makes a product understandable
     5. Good design is unobtrusive
     6. Good design is honest
     7. Good design is long-lasting
     8. Good design is thorough down to the last detail
     9. Good design is environmentally-friendly
    10. Good design is as little design as possible

     1. Good design is innovative
        UNIX innovated by simplifying Multics -
        throwing away ring security and PL/I's memory safety features.
        Linux innovated by cloning UNIX, giving it away for free,
        and avoiding the lawsuit that sidelined BSD.
     2. Good design makes a product useful
        Yet somehow people managed to use UNIX anyway.
     3. Good design is aesthetic
        UNIX threw away clear, long-form command forms and kept
        short, cryptic abbreviations like "cat" (short for "felis cattus") 
        and "wc" (short for "toilet").
        Its C library helpfully abbreviates "create" as "creat",
        because vowels are expensive.
     4. Good design makes a product understandable
        See #3
     5. Good design is unobtrusive
        That's why UNIX/Linux enthusiasts spend so much time
        configuring their systems rather than using them.
     6. Good design is honest
        The UNIX name indicates it is missing something 
        present in Multics. Similarly, "Linux" is the
        gender-neutralized form of "Linus".
     7. Good design is long-lasting
        Like many stubborn diseases, UNIX has proven hard to eradicate.
     8. Good design is thorough down to the last detail
        UNIX/Linux enthusiasts love using those details
        to try to figure out how to get Wi-Fi, Bluetooth,
        and GPU support partially working on their laptops.
     9. Good design is environmentally-friendly
        Linux recycles most of UNIX's bad ideas, and many
        of its users/apologists.
    10. Good design is as little design as possible
        Linux beats UNIX because it wasn't designed at all.

Yes, it did some things right, but also did plenty of them bad, lets not worship it as the epitome of OS design, cloning it all the time without critical thinking.

Alone the fact that its creators went on to design Plan 9, Inferno, Alef, Limbo and Go, shows even they moved on to better approaches.

Also to note that outside FOSS circles worshiping UNIX, no one cares about said philosophy, including commercial UNIX vendors.

I think you're confusing "different" with "better", and you're confusing someone'small almost personal experiments implemented as proof-of-concept projects as actually being improvements.

I mean, Plan 9 was designed with a radical push for distributed computing in mind. This is not "better" than UNIX's design goals, just different.

Nevertheless, Plan 9 failed to gain any traction and in practice was pronounced dead around a decade ago. In the meantime, UNIX and Unix-like OSes dominate the computing world still up to this day. How does that reflect in your "better approaches" assertion?

The argument on the Go programming language is particularly perplexing. The design goal of Go has nothing to do with the design goal of C. Their designers were very clear in how their design goals was to put together a high-level programming language and tech stack designed to improve Google's specific problems. This wasn't C's design requirements, were they?

https://go.dev/talks/2012/splash.article

> We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.

Go is basically Limbo in a new clothing, Limbo took up the lessons on Alef's design failure.

They could have designed their C++ wannabe replacement in many other ways.

Only rule 7. and 9. are measurable and not purely subjective.

If you design for an ephemeral state, it doesn't make sense to be long lasting.

3D printing a door handle that perfectly fits my hand, my door, the space it moves in and only lasts until I move to another house can be the ultimate perfect design _for me_.

I'd see the same for prosthetic limbs that could evolve as the wearer evolves (e.g. growth up or ages) or what they expect from it changes.

https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...

https://en.m.wikipedia.org/wiki/Unix_philosophy

> The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators

Nobody says "we want to build complicated, sprawling, unclear, unmodular and rigid code", so this isn't a statement that sets UNIX apart from any other design. And if we look at the competing space of non-UNIX platforms, we see that others arguably had more success implementing these principles in practice. Microsoft did COM, which is a much more aggressive approach to modularity and composable componentization than UNIX. Apple/NeXT did Objective-C and XPC, which is somewhat similar. Java did portable, documented libraries with extensibility points better than almost any other platform.

Many of the most famous principles written down in 1978 didn't work and UNIX practitioners now do the exact opposite, like:

• "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features" yet the --help for GNU grep is 74 lines long and documents 49 different flags.

• "Don't hesitate to throw away the clumsy parts and rebuild them." yet the last time a clumsy part of UNIX was thrown away and rebuilt was systemd, yielding outrage from people claiming to defend the UNIX philosophy.

About the only part of the UNIX philosophy that's actually unique and influential is "Write programs to handle text streams, because that is a universal interface". Yet even this principle is a shadow of its former self. Data is exchanged as JSON but immediately converted to/from objects, not processed as text in and of itself. Google, one of the world's most successful tech companies, bases its entire infrastructure around programs exchanging and storing binary protocol buffers. HTTP abandoned text streams in favor of binary.

Overall the UNIX philosophy has little to stand apart other than a principled rejection of typed interfaces between programs, an idea that has few defenders today.

Implementation simplicity meant one important thing: Unix could be quickly developed and iterated. When Unix was still new, this was a boon and Unix grew rapidly, but at one point backward compatibility had to be maintained and we remained with a lot of cruft.

Unfortunately, since implementation simplicity and development speed nearly always took precedence over everything else, this cruft could be quite painful. If you look at the C standard library and traditional Unix tools, they are generally quite user hostile. The simple tools like "cat" and "wc" are simple enough to make them useful, but most of the tools have severe shortcomings, either in the interface, lack of critical features or their entire design. For example:

1. ls was never really designed to output directory data in a way that can be parsed by other programs. It is so bad that "Don't parse ls" became a famous warning for shell script writers[1].

2. find has a very weird expression language that is hard to use or remember. It also never really heard about the "do one thing well" part of Unix philosophy and decided that "be mediocre at multiple things" is a better approach. Of course, finding files with complex queries and executing complex actions as a result is not an easy task. But find makes even the simplest things harder than they should be.

A good counterexample is "fd"[2]. You want to find that has a "foo" somewhere in its name in the current directory and display the path in a friendly manner? fd foo vs find . -name 'foo' -Printf "%P\n". What to find all .py files and run "wc -l" on each of them? fd --extension py --exec wc -l (or "fd -e py -x wc -l" if you like it short). "Find requires you to write find . -name '*.py' -exec wc -l {} ;". I keep forgetting that and have to search the manual every time.

Oh, and as a bonus, if you forget to quote your wildcards for find they may (or may not!) be expanded by the shell, and end up giving you completely unexpected results. Great foolproof design.

3. sed is yet another utility which is just too hard to learn. Most people use it as mostly as a regex find-and-replace tool in pipes nowadays, but its regex syntax is quite lacking. This is not entirely sed's fault, since it predates Perl and PCRE which set the modern standard for regular expressions that we expect to more or less work the same everywhere. But it is another example of a tool that badly violates the principles of good design.

The Unix Haters Handbook is full of many more examples, but the reality is that Unix won because other OSes could not deliver what their users needed fast enough. Unix even brought some good ideas to the mass market (like pipes) even if the implementation was messy. We now live under the shadow of its legacy, for better or worse.

But I don't think we should idolize the Unix philosophy. It is mostly a set of principles ("everything is a file", "everything is text" and "each tool should do one job", "write programs to work together") that was never strictly followed (many things in UNIX are not files, many commands do multiple jobs, most commands don't interact nicely with each other unless you just care about opaque lines). But most importantly, the Unix philosophy doesn't extend much beyond designing composable command line tools that handle line-oriented text for power users.

[1] https://mywiki.wooledge.org/ParsingLs

[2] https://github.com/sharkdp/fd

Why?

Maybe it's meant in an artistic sense, but under an engineering one I just don't see it.

"We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."

There are very real drawbacks to relying on other people's solutions to your problems. Sometimes they are outweighed by the hassle of implementing your own solution, but in many cases they do not.

> > Why?

> a "good design" is indeed innovative in some way

Proof by repetition, I guess? You haven't answered the question in any meaningful way, just repeated the original assertion. It's still as unsupported as it ever was.

Sometimes the things we consider already solved can be solved better with nuances that maybe weren't considered before.

innovative vs useful, understandable vs honest, long lasting vs thorough, aesthetic vs unobtrusive,

What?

https://www.vitsoe.com/us/about/good-design#good-design-is-i...

> Everything is a file

To me it could be:

Something accessible via a file descriptor that can be read from and/or written to. Feel free to add some other details like permissions, as needed.

Perhaps they should allow for folders as well, since a complex piece of hardware undoubtedly needs to expose multiple files to be robust, but the underlying intention was to create a standardized way of interacting with hardware.

Sectors on disk, switches, analog devices like a speaker, i2c and other hardware ideas all need to be read from or written to in some form to be useful

The most common example of soemthing almost all programs interact with universally is BSD sockets. In Plan9, which goes out of its way to follow this everything is a file philosophy, TCP/UDP connections are actually represented as files. You open a file and write something to it to create the connection, and then you read or write to other files to read the streams, and you write again to the control file to close the connection. On the server side, you similarly write to a control file to start accepting packets, and monitor a directory to check for new connections, and so on.

Note that "file" here has a pretty clear definition: anything that can be interacted with using strictly the C FILE api - open()/read()/write()/close().

Calling that a "file" is ... a humongous stretch, to put it mildly.

> Xorg

I guess it didn’t say pleasing?

“Good design is as little design as possible” ok cool but I have 30 different feature requests coming in every week from actual users, that doesn’t really help me make concrete design decisions

“Good design is aesthetic” whose aesthetic? Aesthetic is extremely cultural and arbitrary, my designers are fighting over whether a photorealistic leather texture is more aesthetic than a gradient texture background, how does that help?

“Good design makes a product useful” uh yeah okay I’ve never had a design problem that was solved by someone saying “you know what, we should just make this product useful” “oooh right how did we not think of that”.

I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable in my 15+ years working as a designer.

“Good design is as little design as possible”

What you create should be a natural flow of what your clients needs to do. Don't go and add lot of options like a plane cockpit. Which usually means try to find the common theme and adding on top, and also clamping down on fantasy wishes

"Good design is aesthetic"

I'd take the definition of pleasing instead of beautiful for the term. When learning to draw, an often given advice is just to focus and detail only a single part of the whole picture, everything else can be left out. So discussion over a single thing is usually meaningless. If it's not going to be the focus point of interaction, as long as it meshes into the whole, no one care about the exact details.

“Good design makes a product useful”

Usability is a whole field, and you can find the whole corpus under the HCI (Human Computer Interaction) keyword. Focus on meeting this baseline, then add your creativity on top.

> I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable

It's kinda like Philosophy, you have to understand what it means for yourself. It's not a cake recipe to follow, but more of a framework from where to derive you own methodology.

Or do, because you're designing a plane cockpit :)

If you're working on a piece of software, how likely is it that people are regularly comparing it to the most effective alternative alternative means to accomplish the same task, and the revert course of it turns out you've actually created a more convoluted and time consuming path to the same outcome? Often times, software just adds gets in the way and makes life less easy than it would have been otherwise.

The opposite of these principles is often easier to reason about. For example, people attempting to make "better" versions of Hacker News seem to rarely be aware of these, and when they post to Show HN, hopefully realize that the way it is is hard to beat because it follows at least some of the principles. To make something better, you'd absolutely need to follow similar principles more effectively.

It depends; A/B testing sorta does that at the very granular level. Not so much at a high level.

You write software for a company so someone will give them money for it or so the company can save money

Everything else takes a backseat to that core mission. The first goal when writing software is to efficiently get to a point where one of those goals can be met.

It makes no sense to polish software if you are going to run out of money before it gets released, management cuts funding or you can’t find product market fit to convince investors to give you money depending on what your goal is.

Code doesn’t always need to be long lasting, you can’t predict how the market will change, how the underlying platform will change, when a better funded competitor will come in and eat your lunch, etc.

Good design doesn’t need to be “innovative”. It needs to fit within the norms of the platform or ecosystem it is part of.

I write little utilities for my parents, games for my son, a web shop for my wife. I write social spaces for myself and my friends. I write tools for myself.

I write software for strangers on the internet. I write software when I’m drunk, to test myself. Sometimes I write software simply for the joy of writing it, and it never runs again after that first “ah, finally!” moment. Aah, time well spent.

Equating “writing software” with “fulfilling business goals” is…quite depressing. Get outside! Feel the sunshine on your face! Write your own image-processing DSL, just for the sheer unbridled hell of it! Learn Nim! Why not?

(Ok, maybe skip the last one)

As someone who learned Nim as my first "serious" programming language, I do recommend to learn Nim. It is a delight to write and read.

Before I found Nim I looked at C, C++, Python and all of them full of cruft - old bad decisions that they're stuck with and forced to keep in the language. And it makes them a nightmare to learn.

In C there seems to be hundreds of subtly different OS-dependent APIs for every simple thing.

C++ was designed by mad scientist and extended to the point where even c++ developers have no idea what part of the language you should use.

Python is the messiest mess of OOP with non-existent documentation that is actually readable. Just to find how to do anything in Python I need to look at sites like stackoverflow and find outdated solutions for Python 2, deprecated functions and giant third party libraries. Yeah you don't learn Python nowadays, you forced to learn Python + NumPy + Pandas + Python Package Distribution (hell).

I had fun learning Nim, though.

Huh? Surely you don’t expect docs to answer generic questions like, “how do I flatten a nested list?”

Pandas (and Polars!) is an excellent library that serves specific needs. One of those is not doing basic file parsing. I’ve seen comments advocating its usage for tasks as simple as “read a CSV file in and get the Nth column.” The same goes for NumPy – powerful library that’s ridiculously over-used for things that are trivially solvable by stdlib.

Or even staying inside and spending time with family

In my original comment:

whoever else shows up while drinking soda (I go down to hang out not always to drink) and listening to bad kaorake.

Hmm. I run a solo-founder SaaS business. I write software for my customers so that they can improve their workflows: essentially, work faster, with fewer mistakes, and make work easier. My customer pay me money if my software improves their lives and workflows. If it doesn't live up to the promise, they stop paying me money.

Most of Dieter Rams's design rules very much do apply to software that I write. I can't always afford to follow all of these rules, but I'm aiming to.

And while I don't always agree with antirez, his post resonated with me. Many good points there.

Incidentally, many of the aberrations he mentioned are side-effects of work-for-hire: if you work for a company and get a monthly salary, you are not directly connected to customers, do not know where the money comes from, and you are not constrained by time and money. In contrast to that, if you are the sole person in a business, you really care about what is the priority. You don't spend time on useless rewrites, you are super careful with dependencies (because they end up costing so much maintenance in the future), you comment your code because you do so much that you forget everything quickly, and you minimize complexity, because simpler things are easier to build, debug and maintain.

So your goal is to write software so that customers will give you money because they see that your software is valuable to them. How does that conflict with what I said? That’s the goal of every legitimate company.

I work in consulting. I work with sales, I am the first technical person a customer talks to on a new engagement and when they sign the contract, I lead the implementation and work with the customer. I know exactly where the money comes from and what the customer wants.

If a developer is not close to the customer and doesn’t have as their focus the needs of the business, they are going to find themselves easily replaced and it’s going to be hard to stand out from the crowd when looking for a job

Everybody still can write software however you like just don’t expect to earn money on that.

We had our own internal load balancer, web servers, mail servers, ftp servers to receive and send files, and home grown software.

Now I could reproduce the entire setup within a week at the most with some yaml files and hosted cloud services. All of the server architected is “abstracted”. One of the things he complains about.

As far as backwards compatibility, worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is. Even back in the mid 2000s there was over a dozen ways to represent a string when programming and you had to convert back and forth between them.

Apple has been able to migrate between 5 processors during its existence by breaking backwards compatibility and even remove entire processing subsystems from ARM chips by removing 32 bit code compatibility.

This is my personal bugbear, so I’ll admit I’m biased.

Infrastructure abstractions are both great and terrible. The great part is you can often produce your desired end product much more quickly. The terrible part is you’re no longer required to have the faintest idea of how it all works.

Hardware isn’t fun if it’s not working, I get that. One of my home servers hard-locked yesterday to the point that IPMI power commands didn’t work, and also somehow, the CPUs were overheating (fans stopped spinning is all I can assume). System logs following a hard reset via power cables yielded zero information, and it seems fine now. This is not enjoyable; I much rather would’ve spent that hour of my life finishing the game of Wingspan.

But at the same time, I know a fair amount about hardware and Linux administration, and that knowledge has been borne of breaking things (or having them break on me), then fixing them; of wondering, “can I automate X?”; etc.

I’m not saying that everyone needs to run their own servers, but at the very least, I think it’s an extremely valuable skill to know how to manage a service on a Linux server. Perhaps then, the meaning of abstractions like CPU requests vs. Limits will become clear, and disk full messages will cause one to not spam logs with everything under the sun.

Windows is a shitshow beacuse the leadership is chaotic, dragged all around all the time, never finishing nothing well. They only survived because of backward compatibility! Building on the unlikely success in the 90s.

Also, why do I have to install new software in every couple of months to access my bank account, secure chat, flight booking system, etc., etc., without any noticable difference in operation and functionality. A lot of things unreasonably becoming incompatible with 'old' (we are talking about months for f's sake!!) versions. That's a nuisance and erosion of trust.

Web actually excels here because you can use service workers to manage versioning and caching so that backwards compatibility is never a concern.

Anything providing something like Linux with a polished surface and support for the tools of the rest of office IT (e.g. MS Word) was going to blow Windows away in this area.

So the success of OSX here is no surprise.

But the native way of doing it was VbScript with the Windows Script Host.

Are you talking about security updates?

Presumably a security update would mean a difference in operation somewhere. They were probably referring to the updates that just exist to add ads, promos, design changes, etc.

At least with iOS, iOS 18 supports devices introduced since 2018 and iOS 16 just got a security update late last year and that supports phones back to 2017.

I imagine a simple architecture where each application has its own crappy CPU some memory and some storage with frozen specs. Imagine 1960 and your toaster gains control over your washing machine. Why are they even in the same box?

Does it really make sense in 2025 to use Quicken (?) with a dialup modem that calls into my bank once a day to update my balances like I did in 1996?

Imagine 1960 and your toaster gains control over your washing machine. Why are they even in the same box?

Imagine in 2002 your MP3 Player, your portable TV, your camera, your flashlight, your GPS receiver, your computer you use to browse the web, and your phone being the same device…

Well, the modern hot garbage Intuit forces people to use takes 5-15 seconds to save a transaction, 3-5 seconds to mark a transaction as cleared by the bank, it sometimes completely errors out with no useful message and no recourse other than "try again", has random UI glitches such as matched transactions not being removed from the list of transactions to match once matched (wtf?), and is an abject failure at actually matching those transactions without hitting "Find matches", because for whatever reason the software can't seem to figure out that the $2182.77 transaction from the bank matches the only $2182.77 transaction in the ledger. That one really gets my goat, because seriously, WTF guys?

Not to mention the random failure of the interface to show correct totals at random inopportune moments.

Oh, and it costs 5x as much on an annual basis.

I sure would take that 1996 version with some updated aesthetics and a switch to web-based transaction downloading versus the godawful steaming pile of shit we have now- every day of the week and twice on Sunday. Hands down.

This idea that we've made progress is absolutely laughable. Every single interaction is now slower to start, has built-in latency at every step of the process, and is fragile as hell to boot because the interface is running on the framework-du-jour in javascript.

Baby Jesus weeps for the workflows forced upon people nowadays.

I mean seriously, have none of you 20-somethings never used a true native (non-Electron) application before?

What kills me about Intuit is that they _can_ make decent software: TurboTax. Obviously, I’d rather the IRS be like revenue departments in other countries, and just inform me what my taxes were at EOY, but since we live in lobbyist hell, at least Intuit isn’t making the average American deal with QuickBooks-level quality.

It’s not like the non-SaaS version of QB is any better, either. I briefly had a side business doing in-person tech support, and once had a job to build a small Windows server for a business that wanted to host QB internally for use. Due to budget constraints, this wound up being the hellscape that is “your domain controller is also your file server, application server…” Unbeknownst to me at the time, there is/was a long-standing bug with QB where it tries to open ports for its database that are typically reserved by Windows Server’s DNS service, and if it fails to get them, it just refuses to launch, with unhelpful error logs. Even once you’ve overcome that bizarre problem, getting the service to reliably function in multi-user mode is a shitshow.

> I mean seriously, have none of you 20-somethings never used a true native (non-Electron) application before?

Judging on the average web dev’s understanding of acceptable latency, no. It’s always amusing to me to watch when web devs and game devs argue here. “250 msec? That’s 15 screen redraws! What are you doing?!” Or in my personal hell, RDBMS. “The DB is slow!” “The DB executed your query in < 1 msec. Your application spent the other 1999 msec waiting on some other service you’ve somehow wrapped into a transaction.”

I think it should have been obvious from my list of complaints that I was doing something a little more involved than "checking my bank balance".

I don’t even know what you’re asking.

https://100r.co/site/computing_and_sustainability.html

Or much technology at all. If you use anything that is 1000 years old, it's probably been maintained or cared for a lot during those 1000 years

It's alarming how often the answer isn't a confident "yes".

Python for example makes breaking changes in minor releases and seems to think it's fine, even though it's especially bad for a language where you might only find that out runtime

It's a bit like asking why the army needs tanks when horses worked well the previous war

I wouldn't blame it on security, as many of them do.

...or if it is true, this mass security issues emerging from their design, then the situation is even worse than just being lazy ignorant bastards.... or perhaps the mass security problems are related to this incompetence as well?... oi!

All of that has been solved by the web at this point.

You say Windows is a shit show, but as someone who has developed a lot on both Windows and Linux, Linux is just as much a shit show just in different ways.

And it's really nice being able to trust that binaries I built a decade ago just run on Windows.

If drivers are "standard" then low quality drivers full of bugs and security vulnerabilities proliferate and only the OEM can fix them because they're closed source, but they don't care to as long as the driver meets a minimum threshold of not losing them too many sales, and they don't care about legacy hardware at all or by then have ceased to exist, even if people are still using the hardware.

If there is no driver standard then maintaining a driver outside the kernel tree is a pain and more companies get their drivers into the kernel tree so the kernel maintainers will deal with updating them when the driver interface changes, which in turn provides other people with access to fix their heinous bugs.

It's clear that something more aggressive needs to be done on the mobile side to get the drivers into the kernel tree because the vendors there are more intransigent. Possibly something like right to repair laws that e.g. require ten years of support and funds in escrow to provide it upon bankruptcy for any device whose supporting software doesn't have published source code, providing a stronger incentive to publish the code to avoid the first party support requirement. Or greater antitrust enforcement against e.g. Qualcomm, since they're a primary offender and lack of competition is a major impediment to making it happen. If Google wanted to stop being evil for a minute they could also exert some pressure on the OEMs.

The real problem is that the kernel can't easily be relicensed to directly require it, so we're stuck with indirect methods, but that's hardly any reason to give up.

Right to repair laws as you suggest might do something to shift the incentives of vendors in these markets; I don't think they're ever going to "see the light" and suddenly decide they've been doing it wrong all these years (because measured in commercial consequences, they haven't)...

The individual vs. the group.

Where I agree with the author is the need to keep individual tinkering possible.

However, generalizing anyone's idiosyncratic tastes is impossible.

I have a legally-purchased copy of Return to Castle Wolfenstein here, both the Windows version and the official Linux port.

One of them works on modern Linux (with the help of Wine), one of them doesn't.

I wrote some specialist software for Linux round about 2005 to cover a then-business need, and ported it to Windows (using libgtk's Windows port distributed with GIMP at the time.) The windows port still works. Attemping to build the Linux version now would be a huge ordeal.

I would consider myself an Apple evangelist, for the most part, and even I can recognize what's been lost by Apple breaking backwards compatibility every time they need to shift direction. While the philosophy is great for making sure that things are modern and maintained, there is definitely a non-insignificant amount of value that is lost, even just historically but also in general, by the paradigm of constantly moving forward without regard for maintaining compatibility with the past.

They could have stuck with x86 I guess. But was moving to ARM really a bad idea?

They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time. When 32 bit code ran it had to load 32 bit version of the shared linked library and 64 bit code had to have its own versions.

No, including an interpreter like they did (Rosetta) was an alternative. The "alternative" really depends on what the goals were. For Apple, their goal is modern software and hardware that works together. That's antithetical to backwards compatibility.

>They could have stuck with x86 I guess. But was moving to ARM really a bad idea?

I don't think I ever suggested that it was or that they couldn't have...

>They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time.

Yes, and, in doing so, they killed any software that wasn't created for a 64-bit system. Again, for even a purely historical perspective, the amount of software that didn't survive each of the instanced transitions is non-negligible. Steam now has an entire library of old Mac games that can't run on modern systems anymore because of the abandonment of 32-bit without any consideration for backwards compatibility. Yes, there are emulators and apps like Wine and CrossOver than can somewhat get these things working again but there's also a whole subsection of software that just doesn't work anymore. Again, that's just a byproduct of Apple's focus on modern codebases that are currently maintained but it's still a general detriment that so much useable software was simply lost immediately because of these changes when there could have been some focus on maintaining compatibility.

The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.

That was the sane reason that Jobs made it almost impossible to port legacy text based software to early Macs. Microsoft jumped onboard developing Mac software and Lotus and WordPerfect didn’t early on.

But today you would have to have emulation software for Apple //es, 68K, PPC and 32 bit and 64 bit x86 software and 32 bit and 64 bit ARM (iOS) software all vying for resources.

Today because of relentlessly getting rid of backwards compatibility, the same base OS can run on set top boxes, monitors (yeah the latest Apple displays have iPhone 14 level hardware in them and run a version of iOS), phones, tablets, watches and AR glasses.

Someone has to maintain the old compatibility layers and patch them for vulnerabilities. How many vulnerabilities have been found in some old compatible APIs on Windows?

I don't see that as a downside; I see it as a strength. Why should everyone have to get on the library-of-the-year train, constantly rewriting code -- working code! -- to use a new API?

It's just a huge waste of time. The forced-upgrade treadmill only helps Apple, not anyone else. Users don't care what underlying system APIs an app uses. They just care that it works, and does what they need it to do. App developers could be spending time adding new features or fixing bugs, but instead they have to port to new library APIs. Lame.

> Someone has to maintain the old compatibility layers and patch them for vulnerabilities.

It's almost certainly less work to do that than to require everyone else rewrite their code. But Apple doesn't want to spend the money and time, so they force others to spend it.

They don't want all new interfaces with all new buttons and options and menus.

People get used to their workflows and they like them. They use their software to do something. The software itself is not the goal (gaming excepted).

I'm not suggesting that things should never be gussied up, or streamlined or made more efficient from a UX perspective, but so many software shops change just to change and "stay fresh".

There is room for both. But if you are a gamer, the Mac isn’t where you want to be anyway. Computers have been cheap enough for decades to have both a Windows PC and a Mac. Usually a desktop and a laptop.

I have done all of this myself with on prem servers that I could walk to. I know exactly what’s involved and it would be silly to do that these days

Also, when you have 32 bit and 64 bit code, you have to have 32 bit and 64 bit versions of the framework both in memory and on the disk.

This is especially problematic with iOS devices that don’t have swap.

(and Apple shipped a gig of high-def screenshot and other garbage it cares so much about having frameworks on disk)

And it’s not just about disks it’s about memory.

Not entirely, there are other reasons too

But we should respect semantic versioning. Python is a dreadful sinner in that respect.

There is no perfection here, but the correct way to reason about this is to have schema-based systems where the surfaces and state machines are in high level representations and changes can be analyzed automatically without some human bumping the numbers.

Linux is a far bigger shit show. At least at the platform level. Windows is a lesser shitshow at the presentation layer

It’s more about x86. Using an x86 laptop feels archaic in 2025. Compared to my M2 MacBook Air or my work M3 MacBook Pro.

The only thing that makes MacOS much better for me is the ecosystem integration

From the user PoV, isn't that one of those things that are irrelevant? The users, even the very technical ones, neither know nor care that the computer they are using is x86 or ARM or ...

You might say that the battery life is part of UX, so, sure, I get that, but while, in practice, battery life on the M1/M2/M3/M4 is superior, as a trade-off the user gets a limited set of software that they can run, which is also part of the UX.

So the user gets to choose which UX trade-off they want to make.

I personally care because I travel a lot and I need a laptop. For non gamers of course Mac desktops including the new base Mac Mini is good enough.

The upcoming Nvidia Linux AI boxes are interesting.

I don’t think that’s really an x86 vs ARM things. That’s a red herring.

There’s like 3 big factors at play.

1. x86 vs ARM 2. Apple Silicon Engineers vs others 3. Apple’s TSMC node advantage

I think the x86 vs ARM issue is a relatively small one. At least fundamentally.

I’m not saying iPhones are any better. It came out in the Epic trial that 90% of Apple’s App Store revenue comes from games

Linus Torvalds. But what does he know, eh?

In reality pretty much no Android phone runs a stock upstream Linux. They all have horrible proprietary modified kernels.

So no, Android isn't even Linux in the narrow technical sense of the kernel it runs.

(The Android userland, of course, is an entirely different OS that has nothing at all whatsoever to do with Linux or any other flavor of UNIX, current or historical.)

We’re to reinvent the wheel for ourselves instead of relying on huge dependency trees, yet new languages and frameworks (the most common form of wheel reinventing) are verboten.

The only way I can think to meet all these demands is for everyone (other than you, of course) to stop writing code.

And I gotta say, a part of me wishes for that at least once a day, but it’s not a part of me I’m proud of.

In my opinion, vents are fine amongst friends. Catharsis and all that. But in public they stir up a lot of negative energy without anything productive to channel it to (any solutions, calls to action etc). That sucks.

Also what you call "negative energy" I would often call "rightful criticism on non-distilled thoughts that have internal controversies".

The writing style is reminiscent to this famous text (not written in jest, you have to understand that most of these statements depend on a context that is for you to provide):

"Property is theft." -- P.J. Proudhon

"Property is liberty." -- P.J. Proudhon

"Property is impossible." -- P.J. Proudhon

"Consistency is the hobgoblin of small minds." -- R.W. Emerson

OP indeed has mutually exclusive phrases. If we ever get to the "extremely directs facts/proofs" then things get super easy, of course.

99% of the problem when working with people is to even arrive at that stage.

I predict a "well, work somewhere else then" response which I'll just roll my eyes at. You should know that this comes at a big cost for many. And even more cannot afford it. Literally.

I did not find the article illuminating one bit. I agree with some of the criticisms wholeheartedly, mind you, but the article is just a rant.

Which comments might those be? Be concrete.

You also didn't give any example as I asked, you are happy just generalizing so it's not really interesting to engage with you, is what I am finding.

Software written in C continues to be riddled with elementary security holes, despite being written and reviewed by experts. If anything the push to rewrite is too weak, we have known about the dangers for decades at this point.

We aren't destroying software, it was never all that. The software of the 90s was generally janky in a way that would never be tolerated today.

https://github.com/microsoft/garnet

I think we're doing fine.

Circa 1982 or so (and some years before) IBM was shipping mainframe software written in Assembly that anyone could build or modify. They had a bug database that customers could access. Around the same era Unix was shipping with source code and all the tooling you needed to build the software and the OS itself.

So maybe compared to some of that we're doing worse.

Also from 2000: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

So I think we knew around that time what patterns were good ones... But sure, lots of software organizations didn't even use source control and failed Joel's test miserably.

EDIT: And sadly enough many orgs today fail Joel's test as well. We forgot some things that help make better software.

The source control system I had at one job around that time was a dvcs! At a different one, the source control system had its own filesystem was generally insane. It had its own fulltime maintainer sort of like tptacek's build person.

The big difference, really, was that all this software cost a lot of money compared to now where it mostly does not.

But still, I think we can do better. That story you shared highlights a gross inefficiency and diminishing of agency that comes from dependencies.

It's fitting a messy, real world process, to the virtual, reduced (because formalism) computing world backed by failable, messy hardware components through an error-prone, misunderstanding-prone of programming.

So much failure points, and no one is willing to bear the costs to reduce them.

Sometimes it is valid to not reinvent the wheel. Sometimes wheel needs to be reinvented to learn. Both actions are done. Sometimes the decision was right. Sometimes not.

Overall as a whole we are creating things, more than we are destroying. I don't see the need to take a negative stance.

Writing a new green field project using 10.000 npm dependencies for an electron based front end is shockingly easy. But how do you keep that running for the next 15 years? Did the project need npm? Or a web browser? How do all the layers between the lamguage of choice and the bare metal actually behave and can you reason about that aggregate accurately?

The field has come to a point where a lot of projects are set up with too many complexities that are expedient in the short term and liabilities in the long term.

The current generation of junior devs grows up in this environment. They learn that these mistakes as "the right thing to do" when they are questionable and require constant self-reflection and reevaluation. We do not propagate a hacking culture enough that values efficiency and simplicity in a way that leads to simple, efficient, stable, reliable and maintainable software. On a spectrum of high quality craftsmanship to mass-produced single use crap, software is trending too much to the latter. It's always a spectrum, not a bunary choice. But as a profession, we aren't keeping the right balance overall.

I started a job in manufacturing a few months ago and having to think that this has to work for the next 20 years has been a completely different challenge. I don't even trust npm to be able to survive that so web stuff has been been an extra challenge. I landed on lit web components and just bringing it in via a local CDN.

I definitely use npm (or rather pnpm) because I know it will allow me to build whatever I want much faster.

How much complexity is actually required? What changed in software in the last 20 years so that the additional bloat and complexity is actually required? Hardware has become more powerful. This should make software less reliant on complicated optimizations and thus simpler. The opposite is happening. Why? What groundbreaking new features are we adding to software today that we didn't 20 years ago? User experience hasn't improved that much on average. In fact, measurements show that systems are responding more sluggishly on average.

Intrinsic complexity of the problems that software can solve hasn't really changed much as far as I can see. We add towers of accidental complexity on top that mostly aren't helpful. Those need to be questioned constantly. That isn't happening to the extent that it should. Web-based stuff is the poster child of that culture and it's hugely detrimental.

Backends handling tens / hundreds of thousands or more of concurrent users rather than locally deployed software on a single machine or a small server with a few 10s of users?

Mobile?

Integration with other software / ecosystems?

Real time colaboration amoung users rather than single user document based models?

Security?

Cryptography?

Constant upgrades over the web rather than shipping CDs once a year?

I'll pass on AI for the moment as it's probably a bit too recent.

Software can be distributed onto client machines and be kept up to date. That was first solved with Linux packages managers more than 25 years ago.

Before mobile we had a wide range of desktop operating systems with their own warts.

TLS 1.0 was introduced in 1999. So cryptography already a concern back then.

So what is really new?

A few of them aren’t decisions any individuals have control over. Most coders aren’t jumping onto new languages and frameworks all the time; that’s an emergent group behavior, a result of there being a very large and growing number of programmers. There’s no reason to think it will ever change, nor that it’s a bad thing. And regardless, there’s no way to control it.

There are multiple reasons people write software fast rather than high quality. Because it’s a time/utility tradeoff, and time is valuable. It’s just a fact that software quality sometimes does not matter. It may not matter when learning or doing research, it may not matter for solo projects, it may not matter for one-off results, and it may not matter when software errors have low or no consequence. Often it’s a business decision, not an engineering decision; to a business, time really is money and the business wants engineering to maximize the utility/time ratio and not rabbit hole on the minutiae of craftsmanship that will not affect customers or sales.

Sometimes quality matters and time is well spent. Sometimes individuals and businesses get it wrong. But not always.

Fair point: each one of us can think about the balance and understand if it's positive or negative. But an important exercise must be accomplished about this: totally removing AI from the complexity side.

Most of the results that neural networks gave us, given the hardware, could be recreated with a handful lines of code. It is evident every day that small teams can rewrite training / inference engines from scratch and so forth. So AI must be removed from the positive (if you believe it's positive, I do) output of the complexities of recent software.

So if you remove AI since it belongs to the other side, the "complicated software world" what gave us, exactly, in recent times?

AI has the potential to make the situation much worse, as many laypeople confer it an air of "authority" or "correctness" that it's not really owed. If we're not careful, we'll have an AI-driven Idiocracy, where people become so moronic that nobody can do anything about the system when it takes a harmful action.

It needs to be noted that the average person's lot didn't improve until 150 years later. There's no reason why technology can't be decided by democratic means rather than shoved in our faces by people that just want to accumulate wealth and power.

I often work with people who refuse to use software unless it's so well known that they can google for stackoverflow answers or blog walkthroughs. Not because well-known software is stable or feature-filled; no, they literally are just afraid of having to solve a problem themselves. I'm not sure they could do their jobs without canned answers and walkthroughs. (and I'm not even talking about AI)

This is why I keep saying we need a professional standards body. Somebody needs to draw a line in the sand and at least pretend to be real adults. There needs to be an authoritative body that determines the acceptable way to do this job. Not just reading random people's blogs, or skimming forums for sycophants making popular opinions look like the correct ones. Not just doing whatever a person feels like, with their own personal philosophy and justification. There needs to be a minimum standard, at the very least. Ideally also design criteria, standard parts, and a baseline of tolerances to at least have the tiniest inkling if something is going to fall over as soon as someone touches it. Even more should be required for actual safety systems, or things that impact the lives of millions. And the safety-critical stuff should have to be inspected, just like buildings and cars and food and electric devices are.

The lunatics are running the asylum, so that's not happening anytime soon. It will take a long series of disasters for the government to threaten to regulate our jobs, and then we will finally get off our asses and do what we should have long ago.

I’d like to have standard professional certification because I could use it as proof of the effort I put into understanding software engineering that many ICs have not. But I think that many people have “that’ll do it” values and whatever professional context you put them in, they will do the worst possible acceptable job. The best you can do is not hire them and we try to do that already — with LeetCode, engineering interviews, and so on. That effort does work when companies make it.

(Safety critical work is, in fact, inspected and accredited like you would wish, and I have seen the ugly, ugly, terrifying results inside the sausage factory. It is not a solution for people who don't care or don't have a clue, in fact it empowers them)

Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)

https://www.youtube.com/watch?v=ZSRHeXYDLko

Software technology is in decline despite appearances of progress. While hardware improvements and machine learning create an illusion of advancement, software's fundamental robustness and reliability are deteriorating. Modern software development has become unnecessarily complex, with excessive abstraction layers making simple tasks difficult. This complexity reduces programmer productivity and hinders knowledge transfer between generations. Society has grown to accept buggy, unreliable software as normal. Unless active steps are taken to simplify software systems across all levels, from operating systems to development tools, civilization faces the risk of significant technological regression similar to historical collapses.

Unfortunately my stance is that fundamentally things won't change until we get hit with some actual hardware limitations again. Most devs and people in general prefer a semblance of a working solution quickly for short-term gains rather than spending the actual time that's needed to create something of high quality that performs well and will work for the next 30 years. It's quite a sad state of affairs.

With that said I'm generally optimistic. There is a small niche community of people that does actually care about these things. Probably won't take over the world, but the light of wisdom won't be lost!

Users have now been taught that $10 is a lot to pay for an app and the result is a lot of buggy, slow software.

Those big software packages are sold to admins anyway.

Realistically only about 5% or so of my former colleagues could take on performance as a priority even if you said to them that they shouldn't do outright wasteful things and just try to minimize slowness instead of optimizing, because their entire careers have been spent optimizing only for programmer satisfaction (and no, this does not intrinsically mean "simplicity", they are orthogonal).

Disclaimer: Take everything below with a grain of salt. I think you're right that if this was an easy road to take, people would already be doing it in droves... But, I also think that most people lack the skill and wisdom to execute the below, which is perhaps a cynical view of things, but it's the one I have nonetheless.

The reason I think most software can be faster, better and cheaper is this:

1. Most software is developed with too many people, this is a massive drag on productivity and costs.

2. Developers are generally overpaid and US developers especially so, this compounds for terrible results with #1. This is particularly bad since most developers are really only gluing libraries together and are unable to write those libraries themselves, because they've never had to actually write their own things.

3. Most software is developed as if dependencies have no cost, when they present some of the highest cost-over-time vectors. Dependencies are technical debt more than anything else; you're borrowing against the future understanding of your system which impacts development speed, maintenance and understanding the characteristics of your final product. Not only that; many dependencies are so cumbersome that the work associated with integrating them even in the beginning is actually more costly than simply making the thing you needed.

4. Most software is built with ideas that are detrimental to understanding, development speed and maintenance: Both OOP and FP are overused and treated as guiding lights in development, which leads to poor results over time. I say this as someone who has worked with "functional" languages and FP as a style for over 10 years. Just about the only useful part of the FP playbook is to consider making functions pure because that's nice. FP as a style is not as bad for understanding as classic OOP is, mind you, but it's generally terrible for performance and even the best of the best environments for it are awful in terms of performance. FP code of the more "extreme" kind (Haskell, my dearest) is also (unfortunately) sometimes very detrimental to understanding.

Outside of really edge case stuff like real time low level systems software optimizing performance is not that hard and I've worked with many engineers over my long career that can do it. They just rarely have the incentive. In a few particular areas where it's critical and users are willing to pay software can still command a premium price. Ableton Live is a good example.

> Outside of really edge case stuff like real time low level systems software optimizing performance is not that hard and I've worked with many engineers over my long career that can do it. They just rarely have the incentive. In a few particular areas where it's critical and users are willing to pay software can still command a premium price. Ableton Live is a good example.

This seems like a generous take to me, but I suppose it's usually better for the soul to assume the best when it comes to people. Companies with explicit performance requirements will of course self-select for people capable of actually considering performance (or die), but I don't take that to mean that the rest of the software development workforce is actually able to, because I've seen so, so many examples of the exact opposite.

It's a self-perpetuating issue: people build stuff saying "it won't/can't last 30 years" for various reasons (money, time, skill, resources, expectations, company culture, business landscape etc). So then software doesn't last 30 years for those same various reasons.

The idea that we think systems did used to last longer is probably some survivor bias. However, software that has survived decades was probably created with a completely different set of methodologies, resources and incentives to modern software.

Writing bad code to just get past the next sprint or release is madness.

We swap JS frameworks constantly, but when we’ll reach a good paradigm, we’ll stick with it. At one point, React might be the final framework, or rather, one of its descendants.

Develop a good vm that can either be part of the browser or can be easily launched from it and get all of the browser/OS makers on the same page.

We only have what we have because of a lack of real leadership.

When the c++11 abi break happened it was a big pain in the ass, but once MSVC decided in 2015 that they were going to stop breaking ABI I think it was the stability that c++ needed to fossilize…

Spoken as a C++ fan.

I am aware that capitalism essentially dictates externalising cost as much as possible, but with software- much for the same reason capitalism loves it (a copy is cheap and can be sold at full price despite being constructed just once) means that these externalities can scale exponentially.

Teams in particular is an outlier as in most cases it is essentially forced on people.

It doesn't dictate externalising cost as much as possible unless you have a very short-term view.

Short-term view businesses get eaten pretty quickly in a free capitalist system.

People forget that half of capitalism's advantage is the "creative destruction" part - if businesses are allowed to fail, capitalism works well and creates net value.

I'm writing software with the assumption that it'll be used for at least 30 years there, with a lot of guard rails and transparency/observability mechanisms, because I know the next person working there will thank me.

Premature optimisation is bad, but there’s now so many devs who don’t do _any _ at all. They don’t improve any existing code, they’re not writing software that is amenable to later optimisation, inefficient architectures and unnecessary busywork abounds.

Are we surprised that years of “product first, bug fixes later, performance almost never” has left us with an ecosystem that is a disaster?

The fact that people don't stay long enough in companies or work on a long project themselves to see the fruits of their labour down the line is a point that is discussed in some of the other comments here in this thread. I agree with it as well. In general if you job hop a lot you won't see the after effects of your actions. And the industry is such that if you want to get paid, you need to move. To reiterate - it's a sad state of affairs.

That’s really the entirety of the issue, right there.

People aren’t just accepting bad software, they’re paying for it, which incentivizes a race to the bottom.

It’s like “The War on Drugs,” that looks only at the suppliers, without ever considering the “pull,” created by the consumers.

As long as there are people willing to pay for crap, there will be companies that will make and sell crap.

Not only that, companies that try to make “not-crap,” will be driven out of business.

That's easy to stop. Disallow warranty disclaimers.

The EU has something like this, the Cyber Resilience Act, and it has an exception for FOSS.

We are fixing it up by refactoring - many through adding abstractions.

I’m sure code with bad abstractions can scale poorly, but I’m not clear how code without abstractions can scale at all.

That's quite unrelated to abstractions. It's just poorly written code, for whatever reasons may have led there.

And I’d rather work in a codebase where the owners are constantly doing such refactors than not.

mechanical shit was local, electronic shit is global, not comparable at all

The first half of the 20th century excelled in mechanical destruction. Thus far, the electronic age has been much less bloody.

Since they mentioned nukes it seemed like an obvious example where local things can be catastrophic.

The theoretical risk of electronic things malfunctioning in some global way that they mentioned has never resulted in any nuclear weapons being deployed, but we've actually seen the local mechanical approach they disregard be devastating.

Imagine if a company had been able to systemize the whims of a paranoid regime, allowing them to track and spy on their citizens with impunity in secret, and the population became so inured to the idea that it became an accepted facet of their culture.

Or what if a political party dominated a state and systematized a way to identify and detect oppositional thought, stamping it out before a counterculture could ever arise. Maybe that thought was tied to a particular religious, ethnic, and/or cultural group.

What if these companies are here today, selling those products to the highest (nation-state) bidders, and the methods they're employing to keep the conceptual wheels turning at scale rely on filtering that selects for candidates who will gladly jump through abstract hoops set before them, concerned only with the how and never the why of what they're doing.

Think about what happens when two people video call each other from opposite sides of the world. How many layers of hardware and software abstraction are they passing through, to have a reliable encrypted video conversation on a handheld computer where the majority of the lag is due to the speed of light? How much of that would you like to remove?

I would venture an alternative bogeyman - "move fast and break things" AKA the drive for profits. It's perfectly possible (as illustrated above) to reliably extract great performance from a tower of abstractions, while building those abstractions in a way that empowers developers; what's usually missing is the will to spend time and money doing it.

Aside, he's treated like a celebrity in the game developer niche and I can't understand why.

Depending on what tech you use it can be easier or harder to do as well. I'm making a game with Love2D now, which has made supporting Mac and Linux rather trivial so far, although I've run into challenges with mobile platforms and the web even though it support them (it does work, but it takes more low-level glue code to support native phone features, and the web doesn't seem to be well maintained and my game is throwing webassembly errors currently when I try to run it).

And my previous game (which is on the backburner for now) was made with Monogame, and while that technically has support for Mac and Linux (as well as mobile), I've had quite a few issues even just getting the Mac version working well, like issues with resolution, rendering 3D properly, getting shaders not to break, etc. And they haven't kept up with the latest Mac updates the past few years and have had to make a special push to try to get it caught back up. I've probably sunk a good 20+ hours trying to get it working well before putting that aside to work on the actual game again and I still might have to rearchitect things a bunch in order to get that working.

Meanwhile Unity would probably be pretty dirt simple to port, for the most part, but it comes with other tradeoffs, like not being open source, and trying to pull a stunt a couple years ago where they pulled the rug out from under developers with changing licensing to something aggressive (that convinced other developers to port their games away from the platform), etc.

And there's Godot, which seems to be getting more support again (which is great, I even considered it or my current game, I just like coding in Love2D a bit better), but if you ever want your game on consoles you have to pay a third party to port your games to consoles for you.

The guy you linked makes their own engine (and to be fair, so does Jonathan Blow, who you're critiquing), which is great, but not everyone wants to get that low level. I would rather spend more time focusing on building the games themselves, which is already hard enough, rather than spending all that time building an engine.

It was for that reason that I spent several years focused on board game design instead (as I can make a working game with drawing on index cards and some colored plastic cubes in less than an hour), although that has its own frustrations with significant hurdles to get your game signed by publishers as an unknown designer (I did get one signed four years ago, and it's still not released yet), and large financial risks being made for manufacturing and distribution.

Edit: Also the person you linked to isn't even sure it was financially worth it to support all of those platforms, they just do it for other reasons:

"Do you make your money back? It’s hard to say definitely which could mean no. Linux and macOS sales are low so the direct rewards are also low. ...For Smith and Winston [their current game] right now I don’t think it’s been worth it financially (but it will probably make it’s money back on Launch)"

I haven't watched that talk by Blow yet so maybe he covers my concern.

I think you have to be mindful of incentives structures and constraints. There's a reason the industry went down the path that it did and if you don't address that directly you are doomed to failure. Consumers want more features, the business demands more stuff to increase its customer base, and the software developers are stuck attempting to meet demand.

On one hand you can invent everything yourself and do away with abstractions. Since I'm in the embedded space I know what this looks like. It is very "productive" in the sense that developers are slinging a lot of code. It isn't maintainable though and eventually it becomes a huge problem. First no one has enough knowledge to really implement everything to the point of it being robust and bug free. This goes against specialization. How many mechanical engineers are designing their own custom molding machine in order to make parts? Basically none, they all use mold houses. How many electrical engineers are designing their own custom PCB(A) processing machines or ICs/components? Again, basically none. It is financially impossible. Only in software I regularly see this sentiment. Granted these aren't perfect 1-to-1 analogies but hopefully it gets the idea across. On the other hand you can go down the route of abstractions. This is really what market forces have incentivized. This also has plenty of issues which are being discussed here.

One thought that I've had, admittedly not fully considered, is that perhaps F/OSS is acting negatively on software in general. When it comes to other engineering disciplines there is a cost associated with what they do. You pay someone to make the molds, the parts from the molds, etc... It's also generally quite expensive. With software the upfront cost to adopting yet another open source library is zero to the business. That is there is no effective feedback mechanism of if we adopt X we need to pay $Y. Like I said, I haven't fully thought through this but if the cost of software is artificially low that would seem to indicate the business and by extensions customers don't see the true cost and are themselves incentivized to ask for more at an artificially low price thus leading to issues we are currently seeing. Now don't misread me, I love open source software and have nothing but respect for their developers; I've even committed to my fair share of open source projects. As I've learned more about economics I've been trying to view this through the lens of resource allocation though and it has lead me to this thought.

In game development, whenever we go with highly abstract middleware, it always ends up limiting us in what we can do, at what level of performance, how much we can steer it towards our hardware targets, and similar. Moreover, when teams become so lean that they can only do high level programming and something breaks close to the metal, I’ve seen even “senior” programmers in the AAA industry flail around with no idea how to debug it, and no skills to understand the low level code.

I’ve seen gameplay programmers who don’t understand RAII and graphics programmers who don’t know how to draw a shape with OpenGL. Those are examples of core discipline knowledge lost in the games industry. Aka what we have now, we might not know anymore how to build from scratch. Or at least most software engineers in the industry wouldn’t. It cannot end well.

Building your own in my exp is a better idea — then you can at least always steer it, improve and evolve it, and fix it. And you don’t accidentally build companies with knowledge a mile wide and an inch deep, which genuinely cannot ship innovative products (technically it is impossible).

I’m not even sure if this is true anymore. We got new features foisted on us most of the time.

I no longer think that's true. Instead, I think consumers want reliability, but more features is a way to justify subscription pricing segregation and increases.

I play games with known bugs, and on imperfect hardware, because I unwilling to pay more. Some experiences are rare, so I tolerate some jank because there aren't enough competitors.

One example: Newbies shouldn't reinvent the wheel. I think they should use the tools, that are available and common in the given context. When they want to tinker, they should write their own compiler. But they shouldn't use that in production.

Another: Backward API compatibility is a business decision in most cases.

Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.

I strongly disagree. They should, and fail and try again and fail. The aim is not to reinvent the wheel, but to understand why the wheel they're trying to reinvent is so complex and why the way it is. This is how I learnt to understand and appreciate the machine, and gave me great insight.

Maybe not in production at first, but they don't reinvent the wheel in their spare time either. They cobble up 200 package dependency chains to make something simple, because that’s what they see and taught. I can write what many people write with 10 libraries by just using the standard library. My code will become a bit longer, but not much. It'll be faster, more robust, easier to build, smaller, and overall better.

I can do this because I know how to invent the wheel when necessary. They should, too.

> Another: Backward API compatibility is a business decision in most cases.

Yes, business decision of time and money. When everybody says that you're losing money and time by providing better service, and lower quality is OK, management will jump on it, because, monies.

> Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.

I think Antirez is spot on. We're destroying software. Converting it to something muddy and something for the ends of business, and just for it.

I'm all with Antirez here. Software came here, because we developed the software just for the sake of it, and evolved it to production ready where needed. Not the other way around (Case in point: Linux).

Often that "saving money" is just externalizing the cost onto your users. Especially in mobile development. Instead of putting in the tiny amount of effort it takes to continue support for older devices, developers just increase the minimum required OS version, telling users with older hardware to fuck off or buy a new phone.

Another example is when you don't take the time to properly optimize your code, you're offloading that cost onto the user in the form of unnecessarily higher system requirements.

This is why I believe slow cooked software. Works better, easier on the system, and everyone is happier.

Growing up in the 80s and 90s I understand viscerally how you feel, but this take strikes me as willfully ignorant of the history of computers, and the capitalist incentives that were necessary for their creation. The first computer and the internet itself were funded by the military. The PC wouldn't have existed if mainframes hadn't proved the business value in order to drive costs down to the point the PC was viable. Even the foundational ideas that led to computers couldn't exist with funding—Charles Babbage's father was a London banker.

I think a lot of what you are reacting to is the failed promise of free software and the rise of the internet, when the culture was still heavily rooted in 60s counter-culture, but it hadn't crossed the chasm to being mainstream, so it was still possible to envision a utopian future based on the best hopes of a young, humanitarian core of early software pioneers operating largely from the sheltered space of academia.

Of course no such utopian visions ever survive contact with reality. Once the internet was a thing everyone had in their pocket, it was inevitable that software would bend to capitalist forces in ways that directly oppose the vision of the early creators. As evil as we thought Microsoft was in the early 90s, in retrospect this was the calm before the storm for the worst effects of tech. I hear Oppenheimer also had some regrets about his work. On the plus side though, I am happy that I can earn enough of a living working with computers that I have time to ponder these larger questions, and perhaps use a bit of my spare time to contribute something of worth back to the world. Complaining about the big picture of software is a fruitless and frustrating endeavour, instead I am interested in how we can use our expertise and experience to support those ideals that we still believe in.

I take issue with your use of the word "utopian" being used in this context. Its not a lost cause to see the world from the perspective of making the world better, by finding our way though this with a better mindset on the future.

And while you are taking the time to ponder these questions because you earn enough to take the time, the world is burning around you. Sorry if my tone is harsh, but these kinds of statements really rub me the wrong way. It feels like you are saying everything that is happening is how its suppose to be and I am strongly against that. We have enough of that perspective, we really don't need it, IMHO.

This gentle motivation is good, because it allows me to look inside and be rational about my ambitions. I won't go to a blind crusade, but try to change myself for the better.

Because, I believe in changing myself to see that change in the world.

Completely and unjustifiably false.

So basically they shouldn’t learn the prod systems beyond a shallow understanding?

Agree. That statement/sentiment though doesn't refute the point that it's destroying software.

They absolutely should, or they will never even get to understand why they are using these wheels.

Fun fact, try to question modern web developers to write a form, a simple form, without a library.

They can barely use html and the Dom, they have no clue about built-in validation, they have no clue about accessibility but they can make arguments about useMemo or useWhatever in some ridiculous library they use to build...ecommerces and idiotic crud apps.

Why? We should stop saying others how they want to write/use their code ASAP.

Many established technologies are a total shitstorm. If it is ok to use them, it is ok if somebody wants to use their own compiler.

When it comes down to it, whatever works best and is usually the most simple, non-breaking, used to win out. That decision has been disconnected from the value creators to the value extractors. It is impossible to extract value before value is created.

Additionally, programming is a creative skill no matter how hard they try to make it not one. Creativity means trying new things and new takes on things. People not doing that will harm us long term.

Generally speaking, because that’s very likely to end up being “pushing for rewrites of things that work”, and also a case of not “taking complexity into account when adding features”, and perhaps in some cases “jumping on a new language”, too.

This is an imagined scenario, but the likelihood of someone easily replacing a working compiler in production with something better is pretty low, especially if they’re not a compiler engineer. I’ve watched compiler engineers replace compilers in production and it takes years to get the new one to parity. One person tinkering and learning how to write a compiler almost for sure does not belong in production.

For example, my own "Almost C" compiler[1] is 1137 lines of code. 1137! Can it ever reach "parity" with gcc or even tcc? No! That's specifically not the goal.

Do I benefit strongly for having a otherworldly simpler toolchain? hell yeah.

The key is scope, as always. Established projects have, by virtue of being community projects, too wide a scope.

[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...

If someone would hand me a project, that is full of self invented stuff, for example a PHP project, that invented its own templating or has it's own ORM, I would run. There is laravel, slim or symfony, those are well established and it makes sense to use them. There are so much resources around those frameworks, people who posted about useful things, or packages that add functionality to those. It just doesn't make sense to reinvent the wheel for web frameworks and thousands of packages around those.

Writing software is standing on the shoulders of giants. We should embrace that, and yes one should learn the basics, the underlying mechanisms. But one should make a difference between tinkering around and writing software, that will be in production for years and therefore worked on by different developers.

The JavaScript world shows how to not do things. Every two years I have to learn the new way of building my stuff. It is annoying and a massive waste of resources. Everyone is always reinventing the wheel and it is exhausting. I understand why it is like this, but we as developers could have made it less painful, if we would embrace existing code instead of wanting to write our own.

I’m in games we even rewrite standard libraries (see EASTL) so that they are more fit for purpose.

Of course, it’s your preference. And that is fine. But I don’t think it speaks to the situation in many tech companies.

Those who do not know history are doomed to repeat it. Or re-re-reinvent Lisp.

There was this anecdote about storm lamp or something. New recruit comes to a camp and sees old guard lighting lamps are turned upside down and lit sideways with a long stick. But he knows better, he tells them and they smirk. First day he lights them the optimal way with a lighter. He's feeling super smug.

But next day he finds the fuse is too short to reach so he takes the long stick...

Few months later, he's a veteran, he's turning lamp upside down using lighter sideways, with a long stick.

And the fresh recruit says he can do it better. And the now old guard smirks.

I'm sure I'm misremembering parts, but can't find the original for the life of me.

This is such a perfect point, no one would have invented the "tank chain" if reinventing the wheel was not allowed.

There are instances where this is good advice, but when they turn into rigid rules, bad software is the inevitable result.

And do you really need to write your own library and implementation of SMTP?

Reinventing the wheel where it makes sense is still allowed. But one should think first about the reasons, in my opinion.

Since flagged, but it's also highly relevant here, since it shows this isn't someone who's interested in serious thoughts or discussion about the merits of his arguments, just hot takes and cheap shots. Whatever he may have done in the past, I see no reason why he should be taken seriously here.

—

†) Please interpret my words literally and in your favor.

Now everyone is a “celebrity”and hubris is at an all time high.

I’ve been in tech for 25+ years and never heard of this person until now but it’s not the first time I’ve heard similar talk.

These maxims strike me more as bitter senior neck beard developer complains about the rest of his team in a passive aggressive way at the work lunch table before COVID.

If you’re a celebrity, we don’t need your snarky complaints. We need you using your “celebrity” to make things better.

Wohpe is probably the novel that sold the most copies in the recent years italian sci-fi history. This summer a new short story of mine will be released by the most important italian sci-fi series.

Meanwhile you need to post this from a fake account. What you can show me, of your accomplishments, with your real name? Here to listen, with genuine interest.

So you cannot "destroy" software. But you can have fast food versus slow food, you can have walkable cities or cars-only cities, you can have literate or illiterate society etc. Different cultures imply and create different lifestyles, initially subjective choices, but ultimately objectively different quality of life.

The author argues for a different software culture. For this to happen you need to create a viable "sub-culture" first, one that thrives because it acrues advantage to its practitioners. Accretion of further followers is then rapid.

The young grow old and complain about change. The cycle of life continues.

Frequent job hopping: lack of pay upgrades because software is considered a cost center

I could go on but in reality it’s a disconnect between what business thinks the software is worth as opposed to what the engineer wants to do with it.

You can say software is an art but commodity art doesn’t make much money. In reality, the ad driven software has greatly inflated salaries (not complaining but it’s reality). Now it’s going to be an ai bubble. But your rank and file business doesn’t care what software bubble is happening but unfortunately they are bound by the costs that come with it.

Have you seen the process that happens in defense or medical equipment industries. You probably won’t complain.

If you didnt have degree requirements and certification bodies for:

* accountants

* engineers

* doctors

* lawyers

What do you think hiring might look like?

Do you think they would build a hiring process to validate to the best of their ability your aptitude of the core fundamentals- except worse than certification and education bodies?

I would presume so at least.

Realistically, licensing boards are there to protect their members, and rarely do political things against people in the same body with unpopular opinions. You have to be catastrophic for most boards to do anything about you: Just like a police union will defend a union member that has committed gross negligence unless the evidence is public.

When you hire a doctor for something actually important, you don't look at the certification body: You look at long term reputation, which you also do in software. Only the largest of employers will leetcode everyone as a layer of fairness. In smaller employers, direct, personal references replace everything, which is what I'd go with if I needed an oncologist for a very specific kind of cancer. The baseline of aptitude from the certification body doesn't matter there at all.

Have you ever done any of the various IT certs?

Doctors also go to school for 8 years and then do residencies. Lawyers go to school for 7. Are you proposing that?

Its called “being out of touch” I believe

When done correctly it absolutely adds business value and should not make it harder to adapt or change, that's the point of good engineering. The problem is that you need years, if not decades, of technical experience to see this, and it's also a hard sell when there is no immediate "impact". It's basically something that happens because consumers don't know any better, so then it becomes low priority for making profit... at least until a competitor shows up that has better software and then it has a competitive edge, but that's a different matter.

I keep hearing how 10x engineers make their companies millions upon millions but they only get paid a fraction of that. How does that even make sense as a fair exchange? Not to mention is completely unfeasible for most people to have this kind of impact... it is only possible for those in key positions, yet every engineer is tasked with this same objective to increase company value as much as possible. There's just something very wrong with that.

> All of the things I listed I could do - project management, backend developer or a cloud engineer - I would say I’m only slightly better than average if that

I completely acknowledge this is a valid way to run a business, but the context here is how this sort of career progression is preventing the specialization of engineers in their domain and contributing to the widespread of software problems. Instead of investing in good engineers that specialize in their domain, companies move them away from engineering into more of an entrepreneur mindset by tasking them with adding value to the business directly, which is not something that you do as an engineer (it's nowhere in a CS degree, aside from say some electives).

A good metaphor here is a football/soccer team. What companies are doing is telling the goal keeper that he needs to score goals because more goals means winning. The team wants to win so everyone on the field has to score a goal. That obviously doesn't make sense even though the premise is true. You want a team composed of specialists and the more they specialize in their domain and work together the more you win. Even though there are only two or three offensive players that are scoring the goals, everyone is contributing to the success of the team if they specialize in their domain. Similarly, just because talking to clients and selling the product is directly contributing to the revenue of a business it doesn't mean that engineering at a higher level has no value.

And once again to stress the context here, companies can do whatever they want, but having engineers progress through their careers by moving AWAY from engineering is precisely why there is so much bad software out there. Letting engineers create better software should result in more profit in the long term, just probably not in the short term, and it's also hard for non-technical people to manage. So it is what it is.

Engineering is not only the physical labor. Aircraft engineers and building engineers don’t spend most of their time doing hands on work.

https://www.careerexplorer.com/careers/engineer/

Designing and Planning: Engineers are responsible for designing and planning systems, structures, processes, or technologies. They analyze requirements, gather data, and create detailed plans and specifications to meet project objectives. This involves considering factors such as functionality, safety, efficiency, and cost-effectiveness.

When doing construction work, who adds more value?

The general contractor? (Staff software engineer),

The owners of the plumbing, electrical, and HVAC companies assuming they have the actual skills (senior level developers). The owners of the plumbing companies could very well be making more than the general contractors. This is where you can specialize and the sky is the limit.

The actual certified workers (mid level developers). This is the level that the completely head down people are. No matter how good they become at being a hands on plumber , there is a hard ceiling they are going to hit at this level.

The apprentices (juniors)?

I work in consulting. I am currently a staff architect (true - IC5) over a hypothetical project (not a real project). I know the project is going to need a cloud architect, a data architect , and a software architect. They are all specialists at their jobs and are all going to lead their “work streams”. They are all IC4s

I expect each architect to take the high level business objectives and work with the relevant technical people on both sides and lead their work along with some hands on keyboard work.

They will each have people under them that are not customer facing at all. While I know all of the domains at some level, I’m going to defer to their technical judgement as long as it meets the business objectives. I did my high level designs before they came on to the project. Was my design work, figuring out priorities, risks, making sure it met the clients needs, discussing trade offs, etc not “engineering”?

Each level down from myself IC5 to junior engineers (IC1) is dealing with less scope, impact and ambiguity. There is no reason that the architects shouldn’t get paid as much as I do. They bring to the table technical expertise and depth. I bring to the table delivery experience, being able to disambiguate, and breadth.

No, but software is inherently different because you can leverage existing software to create more software. Every airplane has to be created individually, but software that already exists can be extended or reused by just calling functions or in the worst case copy/pasting.

> The actual certified workers (mid level developers). This is the level that the completely head down people are. No matter how good they become at being a hands on plumber , there is a hard ceiling they are going to hit at this level.

Yes, with hardware this can be the case as there is a small number of ways to build something. With software there is no ceiling, and the proof here is AI. We might soon see general intelligence that just codes anything you want. This means software can be designed to automate virtually anything in anyway shape or form, but it requires more and more expertise.

> I did my high level designs before they came on to the project. Was my design work, figuring out priorities, risks, making sure it met the clients needs, discussing trade offs, etc not “engineering”?

I agree what you're outlining is how the industry works. Perhaps the core of the issue here is how software engineering was modeled after other kinds of engineering with physical limitations. Software is closer to mathematics (arguably it's just mathematics). You can of course still design and plan and delegate, but once the role starts dealing with the high level planning, scheduling, managing, etc., there is less of a requirement for the technical details.

I've worked with architects that didn't know the specifics of a language or design patterns, not because they're bad at engineering but because they had no more time to spend on those details. These details are crucial for good software that is reliable, robust, extensible, etc. Junior and even mid level engineers also don't know these details. Only someone that has been hands on for a long time within a domain can hone these skills, but I have seen so many good engineers become senior or tech leads and then forget these details only to then create software that needs constant fixing and eventually rewriting.

I'm a senior myself and have no choice but to engage in these activities of planning, scheduling, etc., when I can clearly see they do not require technical expertise. You just need some basic general knowledge, and they just are time consuming. My time would be better spent writing advanced code that mid-level and junior level can then expand on (which has happened before with pretty good success, accelerating development and eliminating huge categories of bugs). Instead I have to resort to mediocre solutions that can be delegated. As a result I can see all kinds of problems accumulating with the codebase. It's also really hard to convince the leadership to invest in "high level" engineering because they think that you create more impact by managing an army of low to mid-level engineers instead of leveraging properly written software. I'm convinced that it does add value in the long term, it's just a hard sell. Ultimately I guess it comes down to the type of org and the business needs, which often does not include writing software that will not break. Most companies can afford to write bad software if it means they get to scale by adding more people.

That’s true. But when I put my “software engineering”, “cloud engineer”, or “data engineer” (theoretically) hat on, I can only do work of one person. No matter how good I am at any of it, I won’t be producing more output than someone equally qualified at my own company. Distributing software does have zero marginal cost more or less and that’s why we get paid more than most industries.

but I have seen so many good engineers become senior or tech leads and then forget these details only to then create software that needs constant fixing and eventually rewriting.

This is just like both my general contractor analogy and my real world scenario. As an “staff architect”, I come up with the initial design and get stakeholder buy in. But I defer to the SMEs the cloud architect, the data architect and the software architect who still eats, sleep and breathe the details in their specialty.

Just like the owners of the plumbing company, HVAC company and electrical company are the subject matter experts. The general contractor defers to them.

In the consulting industry at least, there are two ways you can get to the top, by focusing on depth or breadth. But in neither case can you do it by being staff augmentation (the plumber, electrician, or HVAC person), you still have to deal with strategy.

> You just need some basic general knowledge, and they just are time consuming

Knowledge isn’t the issue, it’s wisdom that only comes with experience that I assume you have. Going back to the hypothetical large implementation. It involves someone who does know architecture, development and data. No matter how good your code is, high availability, fault tolerance, redundancy, even throughput comes from the underlying architecture. Code and hands on implementation is usually the least challenging part of a delivery.

Its knowing how to deal with organizational issues, managing dependencies, sussing out requirements, etc

There's really way too many developers that care way more about the code than the product, let alone the business.

It ends up like fine dining, where 99% of the times a big Mac would've been tastier and made the customer happier, but wouldn't justify the effort and price.

I'm sorry but I don't buy it.

I've been way too close way too often with lisp and Haskell or many other niches (I know well both Racket/Scheme and Haskell btw) the people that care that much about this correct and reliable and extensible software care about the code more than they care about the products.

That's why the languages that breed creativity and stress correctness have very little, if any, killer software to show when PHP/Java has tons of it.

First, hardware has improved consistently, outpacing any need for optimal software. Second, the end user does not know what they really want from software until it is provided to them, so most people will easily put up with slow, laggy and buggy software until there is a competitor that can provide a better experience. In other words, if companies can make money from making bad software, they will, and this is often what happens because most people don't know any different and also hardware becomes more and more powerful which alleviates and masks the defects in software.

I think there is also another big factor, which is that businesses prefer to scale by adding more people, rather than by making better software. Because they want to scale along human engineers, they tend to prefer low-tier software that is easy to pick up by the masses, rather than the high-level specialized software that is a hard skill to acquire. This is understandable, but is also the reason why software is so slow in advancing forward compared to hardware (and by the same token, hardware engineers require more specialization).

An alternative but dangerous approach is to make it known you’re looking elsewhere for work. Don’t do that if it’s relatively easy to replace you, and definitely assume the management thinks it’s easy to replace you, especialy if you haven’t been talking to your boss. ;) But there is the chance that they know you’re valuable and haven’t given you a raise because you seem content and they believe they have the upper hand - which may or may not be true.

When I left a company for increased compensation, which funny enough has only been 3x in almost 30 years across 10 jobs, it’s been between a 25%-60% raise. It’s almost impossible for any manager to push that kind of raise for anyone without a promotion.

Even at BigTech promotions usually come with lower raises than if you came in at that level.

Don’t do that if it’s relatively easy to replace you, and definitely assume the management thinks it’s easy to replace you, especialy if you haven’t been talking to your boss.

Everyone is replaceable. If you are at a company where everyone isn’t replaceable, it’s a poorly run company with a key man risk. I never saw any company outside of a one man company or professional practice where one person leaving was the end of the company.

Very true! Though isn’t it also normal in that case for HR to be recommending inflation raises at least? The exception might be if you came in at a salary that’s higher than your peer group and/or high for the title range. Parent’s problem could be that - either peer group correction or not possible for manager to raise at all without a promotion by company rules. There’s lots of reasons I can imagine, but in any case I wouldn’t expect a change with status quo, right? If you haven’t been talking to your boss, continuing to not talk to your boss is unlikely to change anything.

Bad software keeps happening because businesses can afford it, as well as hardware improvements. It's a combination of consumers not knowing what they are missing and hardware advancements allowing for bad software to exist.

If you aren’t writing software with the customer and business in mind, why are you doing it? That’s what you are getting paid for.

That said, AI is about to change all this... but ironically this justifies my position. If software can be so powerful such that you can have a general intelligence that can do almost any cognitive task... then it follows that all this time engineers can also engineer clever systems that can add a lot of value to the company if engineered correctly.

There is no ceiling of how much performance and value can be squeezed out of a software system, but this never happens because businesses are not investing in actual engineering but rather in technical entrepreneurs that can bring something to market quickly enough.

There is no “implicit value” of software to a company. The only value of a software to a company is whether it makes the company money or saves the company money. That’s it, there is no other reason for a company to pay anyone except to bring more value to the company than they cost to employ them.

If software can be so powerful such that you can have a general intelligence that can do almost any cognitive task... then it follows that all this time engineers can also engineer clever systems that can add a lot of value to the company if engineered correctly.

It’s just the opposite. If AI can do any of the coding that a software engineer can do and I am not saying that’s possible or ever will be, what’s becomes even more important are the people who know how to derive business value out of AI.

> There is no ceiling of how much performance and value can be squeezed out of a software system

That may be true. But what’s the cost benefit analysis? Should we all be programming in assembly? Should game developers write a custom bespoke game engines and optimize them for each platform?

The implicit part is that if you engineer a good system then it saves money with less bugs and breaks less, and also makes money by allowing faster development and iterations.

There are plenty of examples here. I could point at how the PlayStation network just went down for 24 hours, or how UIs are often still very laggy and buggy, or I can also point at companies like Vercel that are (I assume) very valuable by providing a convenient and easy way to deploy applications... the fact that there are many SaaS out there providing convenience of development proves that this adds value. Despite this businesses are not having their engineers do this in-house because somehow they don't see the immediate ROI for their own business. I would just call that lack of vision or creativity at the business level, where you can't see the value of a well engineered system.

Businesses are free to run their company in whichever way they please, and they can create crappy software if it makes them money, but the point is that when this is industry-wide it cripples the evolution of software and this is then felt by everyone with downtimes and bad experiences, even though hardware is unbelievably fast and performant.

> Should game developers write a custom bespoke game engines and optimize them for each platform?

This is a good example actually. Most companies that want full creative control are making their own engines. The only exception here is Unreal (other smaller engines are not used by large companies), and from what I can tell the Unreal engine is an example of great software. This is one of those exceptions where engineers are actually doing engineering and the company probably can't afford to have them do something else. Many companies could benefit from this, but it's just not as straight line from the engineering to profit and that's kind of the root of why there is so much bad software out there.

Part of “meeting requirements” is always RTO, RPO, the availability requirements, latency, responsiveness, etc.

Why care about quality or maintainability if you are gone in year or two anyway...

He works as a highly-skilled tech, at a major medical/scientific corporation. They have invested years of training in him, he brings them tremendous value, and they know it. He was just telling me how he used that value to negotiate a higher compensation package for himself. Not as good as if he swapped jobs, but he really has a sweet gig.

People who stay, take Responsibility for the code they write. They will need to face the music, if it doesn't work, even if they are not responsible for maintaining it.

They are also worth investing in specialized training, as that training will give great ROI, over time.

But keeping skilled people is something that modern management philosophy (in tech, at least) doesn't seem to care about.

Until corporations improve the quality of their managers; especially their "first-line" managers, and improve their culture, geared towards retaining top talent (which includes paying them more -but there's a lot more that needs doing), I can't, with good conscience, advise folks not to bounce.

If your main motivation for working is to exchange your labor for the maximum amount of money possible, I don’t see how that is the positive outcome you think it is.

I personally wouldn’t leave my current job if another one for $100K more fell into my lap. But the “unlimited PTO” where the custom is to take at least 5-6 weeks off during the year not including paid holidays and it being fully remote is hard to beat.

I mean pretty much exactly what you said.

I apologize for being unclear.

I’m a founder for 10 people and this is the first thing we think about. Except for low performers; except that youngsters need a variety of experience to be proficient at life; except that the team is not performing well(1). 25% or 30% increases for half the workforce are frequent.

(1) The biggest remark from management coaches is that giving raises lowers employee performance, which I can fully witness in my company. It’s not even good for morale. I’m just happy that people exit the company fitter and with a girlfriend, even a kid and sometimes a permanent residency, but business-wise I’ve been as good as a bad leader.

I’m reaching the sad conclusion that employees bring it upon themselves.

My friend could double his salary, moving almost anywhere else, but he gets a lot of perks at his work, and is treated extremely well by his managers.

They just gave him a rave review, and that did more to boost his willingness to stay, than a 10% raise. He will still negotiate a better salary, but is more likely to be satisfied with less than he might have, if they tried to treat him badly.

Treating employees with Respect can actually improve the bottom line. They may well be willing to remain in difficult situations, if they feel they are personally valued.

I know this from personal experience. When they rolled up my team, after almost 27 years, the employee with the least tenure had a decade. These were top-shelf C++ image processing engineers, that could have gotten much higher salaries, elsewhere.

The problem is our current form of corporate culture. Employees don't feel like they matter, there efforts are a cog in a wheel. If you get a raise in this type culture, it only matters to the bottom line and there is no incentive produce because the employee is already unhappy in the first place.

Change your business culture and these problems will disappear, IMHO.

We also have a 401K match with an immediate vest.

If they would care then job hopping would not exist. If staying at s company would be more. Beneficial to your salary, why would you ever want to change company, if you are otherwise happy?

Coming up with a neat API that turns out to be difficult to modify in the future, or limiting in ways you didn't imagine would when writing it is a good learning experience.

Or seeing how long a system can survive growing usage -- Maybe a simple hack works better than anyone expected because you can just pay more for RAM/CPU each year rather than rebuild into a distributed fashion. Or the opposite, maybe there's some scaling factor or threshold you didn't know existed and system performance craters earlier than predicted.

This is the root problem. None of the problems the GP pointed up were created by software developer.

Now, if you want to know the consequences, it causes an entire generation of people that don't really know what they are doing because they never see the long-term consequences of their actions. But again, it's not the software developers that are causing this, nor are they the ones that should fix it.

FOSS doesn't have these problems.

FOSS is certainly guilty too.

It fosters a culture where everyone can hack something together, and where everyone is knowledgeable enough to make responsible use of technology.

Working as a for-hire developer doesn't let you experience all of that because you're building a product that someone else wants you to build. No wonder one does not give a shit about writing good software at that point! You've taken all the fun and personal fulfillment out of it!

We can build anything we put our mind to -- but most of us are too busy churning out CRUD boilerplate like factory workers. That's depressing.

The complexity/dependency graph of a random application now-a-days is absolutely insane. I don't count everything in this, including the firmware and the OS like Muratori does in his video[1], but it is close enough. The transitive dependency problem needs to be solved. And we need to do something about Bill/Guido taking away all that Andy gives.

I consider the OS (Win32 API, Linux syscalls) to be the only hard dependency for anything I write in C. Tend to avoid libc because of distribution issues. But you have no control over this layer once you switch over to Java/Python.

The only thing you can then do is stop depending on every library out there to avoid writing a couple of hundred lines of code specific to your situation. It definitely increases the maintenance burden. But dependencies are not maintenance-free either. They could have the wrong API which you have to wrap around, or will break compatibility at random times, or become abandonware/malware or have some security flaw in them (rsync had a major security vulnerability just last month).

My personal max line count for a useful project that does one thing is 5-10KLOC of Java/JS/Python. It is something I can go through in a couple of hours and can easily fix a few years down the line if I need to.

[1] The Thirty Million Line Problem (2015) https://youtu.be/kZRE7HIO3vk

Then, PL creators whose language isn’t even at 1.0 light the fuse.

If all people were identical and everyone was on the same level, things would be different. But that is not how the real world works.

    - never ending upgrades
    - unstable ui, unstable ecosystems
    - fix it later
    - shallow business models (subscriptions, freemium, adinfested)
    - social everything (it used to be that my computer was a little escape space where and when i wanted, now i'm tethered to the web noise)

'We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels.'

and this

'We are destroying software pushing for rewrites of things that work.'

But generally speaking I grok it.

The problem, IMO, is globally applying either rule.

I think about this a lot. A general purpose approach is easy to hop between shallow solutions to many problems. So technologists love to have a few of these on hand, esp because they job hop. They're well known and managers love to say "why not just use XYZ".

But it's obvious that a fine tuned hand crafted solution (possibly built from a general one?) is going to significantly out perform a general one.

I am unable to reconcile these two seemingly contradictory takes in the article (rest of it I concur with):

"We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."

"We are destroying software pushing for rewrites of things that work."

By rewrite do you mean 1-to-1 porting the code to another language because reason is: faster/easier/scalable/maintainable/_____ (insert your valid reason here)?

There are dozens of homelab solutions for this (homepage, heimdall, etc.) but none of them was simple enough, framework-free or able to run completely offline (or even from cache).

Being able to code something that fits into a couple of screenfuls of text and does 99% of what I need still feels like “the right way”.

I think the situation (loosely, wasting time spinning your wheels by modernizing things that are actually fine the way they are and may be made worse by adopting "hot new thing") looks worse when you see it through that lens than it actually is throughout the industry as a whole. There are plenty of opportunities for modernization and doing some of the things described in this article that actually make some sense when applied to appropriate situations.

In other words, I totally understand the vibes of this post, it's one of the reasons I don't work in the parts of the industry where this attitude is most prevalent. I would never feel the push to write a post like it though because the poster is I think being a bit dramatic. At least that's the case looking at the industry from my (id argue broader) vantage point of being an expert in and working quite a bit with "legacy" companies and technologies that maybe could stand to have a new UI implemented and some tasteful modern conventions adopted at least as options for the end users.

This post reads as a description of how the wheels come off the wagon if you don't do things well.

With the evolution of AI agents, we'll all be virtual CTOs whether we like it or not, mastering scale whether we like it or not. We need to learn to do things well.

Managerial genius will be the whole ball of wax.

Without a spec, the world falls into disarray and chance, next you need QA tests, and security auditors, and red teams, salespeople, solutions engineers, tech support, training, and a cascade of managers who try and translate "want" into "does" and "when" and to understand and accept the results. Architects and seniors who are both domain experts and skilled coders as the single truth on what the GUI is even supposed to mean. Taking on varying levels of risk with contracts, hires or expanding and contracting the previously mentioned R&D units. That's not software anymore, that's consulting. It's so expensive and unsustainable that it's only a matter of time until you're the leg that gets gnawed off, which is inevitably the result, when burn and panic (or other negative factors) leads you away from turning pain points (like issues, training, or difficult usage) into ice cubes for a cocktail.

We're destroying software when we think documentation does not matter.

I was going to phrase it: We are destroying software by neglecting to documenting it and its design decisions.

With each new language and new library, there's a chance to do it better. It's quite a wasteful process, but that's different from things getting worse.

Software engineering is far from a monoculture.

Maybe what I’ve seen change over the years is the strategy of “pull a bunch of component systems together and wire them up to make your system” used to be more of an enterprise strategy but is now common at smaller companies too. Batteries included frameworks are out, batteries included dependencies in a bunch of services and docker images are in.

It’s true many people don’t invent wheels enough. But there are a lot of developers out there now…

I am reminded of howto guides that require downloading a scaffolding tool to set up a project structure and signing up with some service before even getting to the first line of code.

You might say "I don't need to be able to propose a solution in order to point out problems", and sure, but that's missing the point. Because by pointing out a problem, you are still implicitly asserting that some solution exists. And the counter to that is: no, no solution exists, and if you have no evidence in favor of your assertion that a solution exists, then I am allowed to counter with exactly as much evidence asserting that no solution exists.

Propose a solution if you want complaints to be taken seriously. More people pointing out the problems at this point contributes nothing; we all know everything is shit, what are you proposing we do about it?

You give an engineer ownership and let them learn from their own mistakes, rise to the occasion when the stakes are high. This presumes they will have the last word on changes to that sand box that they own. If they want to rewrite it — that's their call. I'm the end they'll create a codebase they're happy to maintain and we will all win.

(And I think they'll be a happier engineer too.)

Weird take.

Um, no you're not.

> And the counter to that is: no, no solution exists,

If that's the case, it's probably helpful to know it.

> we all know everything is shit, what are you proposing we do about it?

Give up on whatever doomed goal you were trying to reach, instead of continuing to waste time on it?

> We are destroying software with an absurd chain of dependencies, making everything bloated and fragile.

> We are destroying software by always thinking that the de-facto standard for XYZ is better than what we can do, tailored specifically for our use case.

> We are destroying software mistaking it for a purely engineering discipline.

> We are destroying software claiming that code comments are useless.

> We are destroying software by always underestimating how hard it is to work with existing complex libraries VS creating our stuff.

This one begs the question: "What is 'fast'?". I mean, is it high-performance, or quickly-written? (I think either one is a problem, but "quickly-written" leads to bad software, and overly-optimized software can be quite hard to maintain and extend).

> We are destroying software trying to produce code as fast as possible, not as well designed as possible.

> We are destroying software by jumping on every new language, paradigm, and framework.

Whilst I largely agree with the premise of the post, some of these points feel a little bit dissonant and contradictory. We can have stability and engineering quality _and_ innovation. What I think the author is trying to target is unnecessary churn and replacements that are net-worse. Some churn is inevitable, as it’s part of learning and part of R&D.

That culture usually starts at the top if you have it in your company, but occasionally you will just be lucky enough to have it in your team.

So before you write some software, you describe it to your team in a document and get feedback (or maybe just your manager).

If you don't do this, you don't really have a software design culture at your company. My rule was basically that if a piece of software required more than 1 Jira ticket, then create a doc for it.

Legacy systems are born from rushing into implementation to feel productive rather than understanding the problem. Slow is smooth. Smooth is fast.

If asked to implement a templated dictionary type, many C++ programmers will write a templated class. If they want to be responsible, they’ll write unit tests. But the simplest way is:

template<typename Key, typename Value>

using Dictionary = std::vector<std::pair<Key, Value>>;

It is trivially correct and won’t have any edge cases which the tests may or may not catch.

Some programmers would consider this implementation beneath them. In just 800 lines, they could build the type from scratch and with only a few months’ long tail of bugs.

When I do a git blame of something coherent, that worked well in production, that I wrote years ago, almost none of my original code survived, every line is now written by a different person. That's the entropy of software systems left unchecked. It was not really rushed, there was a ton of time debating design before a single line was written.

Many of these have been an issue since I started programming many decades ago on minis. Seems as the hardware gets more powerful we find ways to stress out the hardware more and more. This making your list true to a greater extent year after year.

BTW, I like your WEB Site format a lot!

Yet: https://x.com/antirez/status/1885994950875046164

The reality is that man's "unnecessary complexity" is another's table stakes feature. The post isn't entirely without merit, but most of it reads like a cranky old timer who yearns for a simpler time.

Also I'm very enthusiastic with modern AI and definitely open to new things that make a difference. The complexity I point my finger to, in the post, is all unnecessary for software evolution. Actually it prevents going forward making it better because one have to fight with the internal complexity or with a culture that consider innovation rewriting the software with X or using Y.

Take for example the web situation. We still write into forms, push "post" buttons. Now we trigger millions of lines of code but the result is basically the same as 20 years ago.

To me this is the most sure way to identify the adults from the children in the room. People that can actually program, strangely enough, aren’t bothered by programming.

This one packs a lot of wisdom.

I'm not a masochist; they're often built on top of components, e.g. my IDE uses the Monaco editor. But working on these tools gives me a sense of ownership, and lets me hack them into exactly the thing I want rather than e.g. the thing that Microsoft's (talented! well-paid! numerous!) designers want me to use. Hacking on them brings me joy, and gives me a sense of ownership.

Like an idealised traditional carpenter, I make (within reason) my own tools. Is this the most rational, engineering-minded approach? I mean, obviously not. But it brings me joy -- and it also helps me get shit done.

Or, more generally, the fact that most of what the software industry produces is much more in line with “art” than “engineering” (especially when looked at from a Mechanical Engineer or Civil Engineer). We have so much implementation flexibility to achieve very similar results that it can be dizzying from the standpoint of other engineering fields. consider

Setting up uv, Dockerfiles, GitHub Actions, Secrets etc. took me basically the whole day. I can very much relate to "We are destroying software with complex build systems."

People tend to adapt to technology by becoming more lazy, putting less effort in understanding. Look at how after of calculators became common, we got generations of people who struggle to do basic math.

You'll also find that most people do the same stuff they would have done without a calculator still without a calculator. The advantage now is when they do reach for the calculator they aren't working with perhaps 2 digits precision like the slide rule that preceded them or having to tabulate large amounts of figures to maintain precision.

Do you have any data behind this claim?

> When developers become too dependent on AI to "assist" them in coding, they're more likely to be unable to debug "their own" code as they won't have a full grasp/understanding of it.

Again, do you have any evidence that this happen?

(This is an allusion to Kernighan’s lever.)

What is it about software that causes us to search for aesthetic qualities in the instructions we write for a machine? Ultimately the problems we’re solving, for most of us, will be utterly meaningless or obsolete in ten years at most.

That illusion has been lifted a little harshly for a lot of people over the past year or so. I still enjoy software-as-craft but I don't hold any false belief that my day job does.

He makes very good points. But he missed one. We are destroying software(or anything else) by waiting till something goes wrong to fix it. ex: Software Security, US Food Standards and their relation to the health of it's citizens, etc...

> We are destroying software by no longer caring about backward APIs compatibility.

Come on, who believes this shit? Plenty of people care about API backwards compatibility.

> We are destroying software pushing for rewrites of things that work.

So never rewrite something if it "works"? There are plenty of other good reasons to rewrite. You might as well say "We are destroying software by doing things that we shouldn't do!"

> We are destroying software claiming that code comments are useless.

No we aren't. The crazy "no comments" people are a fringe minority. Don't confuse "no comments" (clearly insane) with "code should be self-documenting" (clearly a good idea where possible).

Worthless list.

My take: SemVer is the worst thing to happen to software engineering, ever.

It was designed as a way to inform dependents that you have a breaking change. But all it has done is enable developers to make these breaking changes in the first place, under the protective umbrella of “I’ll just bump the major version.”

In a better universe, semver wouldn’t exist, and instead people would just understand that breaking changes must never happen, unless the breakage is obviously warranted and it’s clear that all downstreams are okay with the change (ie. Nobody’s using the broken path any more.)

Instead we have a world where SemVer gives people a blank check to change their mind about what API they want, regularly and often, and for them to be comfortable that they won’t break anyone because SemVer will stop people from updating.

But you can’t just not update your dependencies. It’s not like API authors are maintaining N different versions and doing bug fixes going all the way back to 1.0. No, they just bump majors all the time and refactor all over the place, never even thinking about maintaining old versions. So if you don’t do a breaking update, you’re just delaying the inevitable, because all the fixes you may need are only going to be in the latest version. So any old major versions you’re on are by definition technical debt.

So as a consumer, you have to regularly do breaking upgrades to your dependencies and refactor your code to work with whatever whim your dependency is chasing this week. That callback function that used to work now requires a full interface just because, half the functions were renamed, and things you used to be able to do are replaced with things that only do half of what you need. This happens all the god damned time, and not just in languages like JavaScript and Python. I see it constantly in Rust as well. (Hello Axum. You deserve naming and shaming here.)

In a better universe, you’d have to think very long and very carefully about any API you offer. Anything you may change your mind on later, you better minimize. Make your surface area as small as possible. Keep opinions to a minimum. Be as flexible as you can. Don’t paint yourself into a corner. And if you really, really need to do a big refactor, you can’t just bump major versions: you have to start a new project, pick a new name (!), and find someone to maintain the old one. This is how software used to work, and I would love so much to get back to it.

Which is just fine when it is a non funded free software project. No one owes you anything in that case, let alone backwards compatibility.

It’s not an automatic outcome of free software either. The Linux kernel is famous for “we don’t break user space, ever”, and some of Linus’s most heated rants have come from this topic. All of GNU is made of software that doesn’t break backwards compatibility. libc, all the core utilities, etc, all have maintained deprecated features basically forever. It’s all free software.

Forbidding breaking changes isn't going to magically make people produce the perfect API out of the gate. It just means that fixes either don't get implemented at all, or get implemented as bolt-on warts that sow confusion and add complexity.

Or others may say: "There are software, and there are things remind people of software".

I think that writing software for an employer has always kind of sucked. There's never enough time to improve things to the state they should be and you're always one weird product feature from having to completely mess up your nice abstraction.

I do feel like writing hobby software is in a great state now though. I can sit down for 30 minutes and now with Cursor/LLM assistance get a lot of code written. I'm actually kind of excited to see what new open source projects will exist in a few years with the aid of the new tools.

Isn't this kind of ironic?

Arguing against 10x complexity & abstractions, with 1x coding :-)

This idea is getting the causality arrows backwards. I'm not talking up AI because I'm in AI - I'm in AI because I believe it is revolutionary. I've been involved in more fields than most software devs, I believe, from embedded programming to 3d to data to (now) AI - and the shift towards Data & AI has been an intentional transition to what I consider most important.

I have the great fortune of working in what I consider the most important field today.

> But for me, and many others, the joy of programming is in doing the programming. There is not a more outcome-driven modality that can bring us joy. And we either reject the premise or are grieving that it might eventually be true.

This is an interesting sentiment. I certainly share it to some extent, though as I've evolved over the years, I've chosen, somewhat on purpose, to focus more on outcomes than on the programming itself. Or at least, the low-level programming.

I'm actually pretty glad that I can focus on big picture nowadays - "what do I want to actually achieve" vs "how do I want to achieve it", which is still super technical btw, and let LLMs fill in the details (to the extent that they can).

Everyone can enjoy what they want, but learning how to use this year's favorite library for "get back an HTML source from a url and parse it" or "display a UI that lets a user pick a date" is not particularly interesting or challenging for me; those are details that I'd just as soon avoid. I prefer to focus on big picture stuff like "what is this function/class/file/whatever suppoed to be doing, what are the steps it should take", etc.

We continue to add complexity for the sake of complexity, rarely because of necessity. We never question adding new things, yet there's always an excuse not to streamline, not to remove, not to consolidate.

We must deliver new features, because that is progress. We must never remove old systems, because that harms us. We must support everything forever, because it's always too costly to modernize, or update, or replace.

It doesn't matter if the problem doesn't exist, what matters is that by incorporating this product, we solve the problem.

We must move everything off the mainframe and onto servers. We must move every server into virtual machines. We must move every virtual machine into AWS. Every EC2 instance into a container. Every container into Kubernetes. Into OpenShift. We must move this code into Lambda. Do not question the reasoning or its value, it must be done.

How did our budget balloon in size? Why are our expenses always going up? Why is our cloud bill so high? We must outsource, clearly. We must hire abroad. We must retain contractors and consultants. We need more people with certifications, not experience.

Why is everything broken? Why is our data leaking into the public realm? How did we get hacked? We must bring in more contractors, more consultants. That is the only answer. We don't need internal staff, we need managers who can handle vendors, who can judge KPIs, who can identify better contractors at cheaper costs year after year.

Why is the competition beating us? What vendor should we go with to one-up our competition? We must consult the Gartner report. We must talk to other CIOs. We must never talk to our staff, because they don't understand the problem.

We don't like our vendor anymore. They raised prices on us, or didn't take us to that restaurant we liked for contract negotiations, or didn't get us box seats for that event this year. They must go. What do you mean we can't just leave AWS this quarter? What do you mean we can't just migrate our infrastructure to another competitor? That proprietary product is an industry standard, so just move to another one. What are we even paying you for?

We checked all the boxes. We completed all the audits. We incorporated all the latest, greatest technologies. We did everything we were told to. So why aren't we successful? Why aren't we growing?

...ah, that's why. We didn't incorporate AI. That must be it. That will fix it all.

Then we'll be successful. Then everything will work.

And sometimes the reverse problem is what is destroying software: being unwilling to push for rewrites of things when they desperately need one. I think we may have over indexed on "never rewrite" as an industry.

> We are destroying software mistaking it for a purely engineering discipline.

And I'm also seeing this the other way: engineers are beginning to destroy non software things, because they think they can blindly apply engineering principles to everything else.

I just tried to develop a simple CRUD-style database UI for a mechanical hobby project. Being on the backend/systems side of the spectrum, for the UI I decided "yeah, considering I work on a Mac now, and there's no such thing as WinForms here, let's quickly throw together something small with python and tkinter". God, that was a mistake and lead to both suffering and lost days which I did not work on the main project on.

How is it that in 2025, we still do not have some sort of Rapid Application Development tool for Mac? How do we still not have some sort of tool that allows us to just drag a database table into a window, and we have basic DB functionality in that window's app? Jobs demonstrated that capability in the NeXT demo, Visual Studio has been doing it for decades, so has Delphi. But on Mac?

Swift is a train wreck, tkinter is like painting a picture with yourself being blindfolded, Qt does a lot of things right, but has a funky license model I am not comfortable with - and has pain points of its own.

I eventually coughed up the 100 bucks and got a Xojo license ... now I am working in BASIC, for the first time since 1992 - but it has an interface designer. For a massive boost in usability, I have to get back into a language I wished to forget a long time ago.

And that does not spark joy.

Yes, bloat is bad. Yes, I too make fun of people who have to import some nom package to check whether a number is odd or even.

But sometimes, you are not Michelangelo, chiselling a new David. Sometimes, you just need a quick way to do something small. Actively preventing me from achieving that by refusing to go with the times is destructive.

50 IQ: haha software is complicated whatever

100 IQ: (this post)

150 IQ: software is complicated whatever

Until the incentives change, the outcome won't change.

Pointless meetings and bureaucracy also doesn't help. Instead of giving engineers time and breathing room to build well-defined systems, organisations treat them like fungible workhorses that must meet arbitrary deadlines.

Read responsively

"We are destroying software by no longer taking complexity into account when adding features or optimizing some dimension.

And we are destroying software with complex build systems.

We are destroying software with an absurd chain of dependencies, making everything bloated and fragile.

And we are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."

Yie-die-die-die-diiiiieee-dieeee,Yie die die die dieee dieeee

I think people vastly underestimate "the wheel". The wheel was something recreated independently over and over again for thousands of years across human history. Even your favorite programming language or web framework is not comparable to "the wheel".

When we build software, we answer three questions: "what?", "how?", and "why?". The answer to what becomes the data (and its structure). The answer to how is the functionality (and the UI/UX that exposes it). The answer to why is...more complicated.

The question why is answered in the process of design and implementation, by every decision in the development process. Each of these decisions becomes a wall of assumption: because it is the designer - not the end user - making that decision.

Very rarely can the end user move or replace walls of assumption. The only real alternative is for the user to alter the original source code such that it answers their why instead.

Collaboration is the ultimate goal. Not just collaboration between people: collaboration between answers. We often call this "compatibility" or "derivative work".

Copyright, at its very core, makes collaboration illegal by default. Want to make CUDA implementation for AMD cards? You must not collaborate with the existing NVIDIA implementation of CUDA, because NVIDIA has a copyright monopoly. You must start over instead. This is NVIDIA's moat.

Of course, even if copyright was not in the way, it would still be challenging to build compatibility without access to source code. It's important to note that NVIDIA's greatest incentive to keep their source code private is so they can leverage the incompatibility that fills their moat. Without the monopoly granted/demanded by copyright, NVIDIA would still have a moat of "proprietary trade secrets", including the source code of their CUDA implementation.

Free software answers this by keeping copyright and turning it the other direction. A copyleft license demands source code is shared so that collaboration is guaranteed to be available. This works exclusively for software that participates, and that is effectively its own wall.

I think we would be better off without copyright. The collaboration we can guarantee through copyleft is huge, but it is clearly outweighed by the oligopoly that rules our society: an oligopoly constructed of moats whose very foundations are the incompatibility that is legally preserved through copyright.

In a world of mass hallucination (psychosis), doom-scrolling and international capital, software decay is a logical process. Your Leaders have no incentive to think systemically when they have guaranteed immunity.

A good software is a result of meritocratic system with accountability and transparency.

Just take a statistical view on investment in education vs investment in AI infrastructure and the picture becomes clear.

The designer fallacy. Techno-optimism. Detachment from the real problems of humanity. Desensitized obedience for career growth or social benefits.

We build software on the shoulders of giants with a sense of reality and human connection. We lost this skill.

You cannot abstract to infinity. You cannot complicate things just because and expect quality and maintainability to emerge from the ether.

I just open sourced a CLI tool for income and expense tracking yesterday at https://github.com/nickjj/plutus and I'd like to think I avoided destruction for each of those bullets.

You have a choice on the code you write and who you're writing it for. If you believe these bullets, you can adhere to them and if you're pressured at work to not, there are other opportunities out there. Don't compromise on your core beliefs. Not all software is destroyed.