2 ms·

This is horrifying, and needs a trigger warning lol. It gave me a sense of panic to read it. It’s always bad when you get so lost in the codebase that it’s just

by K0balt 2y ago

This is horrifying, and needs a trigger warning lol. It gave me a sense of panic to read it. It’s always bad when you get so lost in the codebase that it’s just a dark forest of hidden horrors. When this kind of thing tries to surface, it’s a warning that you need to 10x your understanding of the problem space you are adjacent to.

JohnMakin 2y ago
I guess I’ve worked in a lot of ancient legacy systems that develop over multiple decades - there’s always haunted forests and swaths of arcane or forgotten knowledge. One time I inherited a kubernetes cluster in an account no one knew how to access and when finally hacking into it discovered troves of crypto mining malware shit. It had been serving prod traffic quietly untouched for years. This kind of thing is crazy common, I find disentangling these types of projects to be fun, personally, depending on how much agency I have. But I’m not really a software developer.
namuol 2y ago
The surest way to get yourself into a mess like this is to assume that a sufficiently complex codebase can be deeply understood in the first place. By all means you can gain a lot by making things easier to understand, but only in service of shortcuts while developing or debugging. But this kind of understanding is not the foundation your application can safely stand on. You need detailed visibility into what the system is genuinely doing, and our mushy brains do a poor job of emulating any codebase, no matter how elegant.
- K0balt 2y ago
  Yeah, if you get over a thousand lines of code you need to be building and documenting it in a way that makes it intelligible in a modular way. FP can be good for that but I often find that people get so carried away with the pure notion of functional code that they forget to make it obvious in its design. Way, way too much “clever” functional code out there. The data structures are the key for many things, but a lot of software is all about handling side effects, where basically everything you touch is an input or an output with real world, interrelated global state. That’s where correctly compartmentalising those state relationships and ample asserts or fail-soft/safe code practices become key. And properly descriptive variable names and naming conventions, with sparse but deep comments where it wasn’t possible to write the code to be self documented by its obvious nature.

by K0balt 2y ago

JohnMakin 2y ago

I guess I’ve worked in a lot of ancient legacy systems that develop over multiple decades - there’s always haunted forests and swaths of arcane or forgotten knowledge. One time I inherited a kubernetes cluster in an account no one knew how to access and when finally hacking into it discovered troves of crypto mining malware shit. It had been serving prod traffic quietly untouched for years. This kind of thing is crazy common, I find disentangling these types of projects to be fun, personally, depending on how much agency I have. But I’m not really a software developer.

namuol 2y ago

The surest way to get yourself into a mess like this is to assume that a sufficiently complex codebase can be deeply understood in the first place. By all means you can gain a lot by making things easier to understand, but only in service of shortcuts while developing or debugging. But this kind of understanding is not the foundation your application can safely stand on. You need detailed visibility into what the system is genuinely doing, and our mushy brains do a poor job of emulating any codebase, no matter how elegant.

K0balt 2y ago
Yeah, if you get over a thousand lines of code you need to be building and documenting it in a way that makes it intelligible in a modular way. FP can be good for that but I often find that people get so carried away with the pure notion of functional code that they forget to make it obvious in its design. Way, way too much “clever” functional code out there. The data structures are the key for many things, but a lot of software is all about handling side effects, where basically everything you touch is an input or an output with real world, interrelated global state. That’s where correctly compartmentalising those state relationships and ample asserts or fail-soft/safe code practices become key. And properly descriptive variable names and naming conventions, with sparse but deep comments where it wasn’t possible to write the code to be self documented by its obvious nature.