n² likes = n maxims/rules of thumb I try to consistently apply to understand why software engineering is so complex, interesting, infuriating, and wonderful

1. "Computers are bad." A huge source of bugs and strange behaviors are due to the incredibly idiosyncratic nature of software. It's more likely your bug is coming from an undocumented config setting in some other program than from some fundamental technical flaw.

2. "Context matters." Understanding how things got to be this way is essential to understanding why they *are* this way... and what we can change for the better. The history of software shapes the present, and so shapes the future.

(For example: https://www.deconstructconf.com/2019/hillel-wayne-what-we-can-learn-from-software-history)

3. "Python is the fourth-best language for everything." Often there are tools perfectly suited to a given task, but if the choice is discovering and learning that tool and using something that kinda-sorta is okay, people will do the latter. And usually, that's the right choice.

4. "Hate your tools." I struggle most to explain this one. If you want to master something, you need to understand it inside-and-out, and see it perfectly objectively. That means not just being aware of its objective flaws, but accepting of them.

5. "Communities are judged by their worst members." It doesn't matter if 99% are great, outsiders will remember the 1% that are assholes. I am unlikely to ever learn Clojure, purely because one Clojurist keeps harassing me. He unfairly tainted the rest by association.

6. "Everything is part of a system." People make decisions in a broader system, code works in one. When investigating something that seems wrong or silly, strive to see if it's poor or actually a local optimum in the broader system.

(Similar to 2, but still distinct.)

A corollary of this is that problems never have a single root cause, because that oversimplifies the vastly complicated system.

7. "The pendulum swings eternal." Each generation rejects the flaws in the previous generation... which itself rejected the flaws in the generation before. People complain third-party libraries lead to bad software. 30 years ago, it was the lack of libraries that was the problem.

(7.5: Over time, movements become the satires of themselves, as the founders who lived in both worlds fade out and people who only knew that movement become more influential. They don't remember the origins, the *why*.)

8. "We are not special." Virtually none of our challenges are unique to software engineering. Heck, they're not even unique to general engineering: there's a lot we can learn from event planning, hospital management, library science, social work, even sex work.

(Because someone will inevitably challenge me: I'd bet the average online sex worker knows way more about privacy, security, and digital footprints than the average software developer does.)

9. "Charisma matters." Software trends driven as much by good speakers and writers as they are by technical merits, perhaps even moreso. As a person who wants to influence software engineering, this is important for me to keep in mind, important skills to continually improve.

10. "Memory is currency." New features, higher abstractions, developer affordances, everything costs RAM and CPU cycles. Our budgets may be loose but they're still present, and we should always be cognizant of what performance cost we're paying for whatever code change we make

(I was debated for *way* too long about that vs "simplicity is currency", which sounds a bit nicer but is less intuitive for most people, and "performance is currency", which is a bit more accurate but sounds terrible. They're all currencies. Often ones in direct conflict.)

Going offline a bit, have a few more maxims ready for when I get back

11. "Time is evil." The relentless march of time shapes everything we do in software. It's why purity is impossible, why performance is a necessary evil, why concurrency is so dangerous. Time is what drags our theories into the real world.

(I'm catastrophizing it, but only a bit. Adding time to any model of reality, mathematical or otherwise, makes everything much harder. And much buggier.)

12. "There's a lot we don't know." Related to 6, 8, and 9, we have very little empirical evidence for all the software claims we make. We argue from personal experience and intuition, not rigorous data. This is fine, but we should accept that and be humble about our limitations.

13. "Expertise comes from the little details." There's a huge number of critical skills we need that aren't, on the face of it, related to what we do. You need to know how to use a search engine, which means figuring out the right terms to search. That's not just common sense.

Every trick, every gotcha, every footgun adds up. Experts have a bewildering away of recognized special cases and snippets and heuristics they use, often all lumped under their implicit knowledge. This matters much more than we pretend.

14. "Nobody reads the primary source." If people are citing or quoting a work, the work will almost inevitably be arguing something *very* different from what the citers think it does. Ideas get corrupted, exaggerated, even inverted. Always read the primary source.

15. "Technical problems are social problems." Ultimately, we're writing code to solve some problem we can't solve with just people, whether that's a good idea or not. Understanding the connection between the software and why people need it in the first place is crucial.

(Yes, I know we're up to 17 now, but I only had 15 I had written down in advance. Want to review some of my writing and notes and make sure the next ones are actual maxims I believe in, not just silly quotes or repeats of older ones)