







It's really easy to tend towards complexity as engineers. I think on some level, we love complexity. There are obviously bad types of complexity, but I think there are other types of it that we seek out, because there's something satisfying about wrapping your head around it; and I think a lot of that kind of complexity ends up in our programming languages.
Why embracing complexity is the real challenge in software today
In the midst of industry discussions about productivity and automation, it’s all too easy to overlook the importance of properly reckoning with complexity.

Complexity and Strategy | HackerNoon
I struggled with how to think about complexity through much of my career, especially during the ten years I spent leading Office development. Modeling complexity impacted how we planned major releases, our technical strategy as we moved to new platforms, how we thought about the impact of new technologies, how we competed with Google Apps, how we thought about open source and throughout “frank and open” discussions with Bill Gates on our long term technical strategy for building the Office applications.


Routledge International Handbook of Complexity Economics | Ping Chen,
The Routledge International Handbook of Complexity Economics covers the historical developments and early concerns of complexity theorists and brings them into

Complexity Explorables
A collection of interactive explorable explanations of complex systems in biology, physics, mathematics, social sciences, epidemiology, ecology and other fields....

Small Programming Tricks
A lot of effective engineering comes from the accumulation of small nuggets of knowledge.
</> htmx ~ Working With AI: A Concrete Example
In this essay, Carson Gross walks through a concrete bug fix in hyperscript to show where AI helped, where it fell short, and why keeping a knowledgeable human in the loop is what kept complexity in check.
The Compendium
A compendium of insights about complexity structured as inter-linked cards by Alex Komoroske
The Facebook Method of Dealing With Complexity
Computers used to be weak, so we had to make their world simple. Now they can handle endless complexity, but we need to learn how to make the world simple

Complexity is a source of income in open source ecosystems | R-bloggers
I am someone who regularly uses R, and my interest in programming languages means that on a semi-regular basis spend time reading blog posts about the language. Over the last year, or so, I had noticed several patterns of behavior, and after reading a recent blog post things started to make sense (the blog post […]

The Bulk of Software Engineering is Just Plumbing
I read a post online recently about how some software engineer was asked to complete a technically complex, jargon-filled coding challenge over the...

X : Do you think AI / vibe coding is not worthwhile? Me : Are you kidding? I was talking about conversational programming (what you call vibe coding) back in 2018. Of course, I think it's important.… | Simon Wardley | 44 comments
X : Do you think AI / vibe coding is not worthwhile? Me : Are you kidding? I was talking about conversational programming (what you call vibe coding) back in 2018. Of course, I think it's important. I think the approach we're using currently is flawed. X : Why? Me : Well, I could go on about the basics such as the medium is wrong (needs to be more image / whiteboard based rather than text) or how we're getting wrapped up in deterministic outputs (text based code) rather than realising the end outputs will eventually be non-deterministic models or we're still learning practices in this space especially with agents and how we rushing ahead into failure creating trust issues. There's a lot of messy stuff happening. But my real interest is with turning software engineering into an engineering discipline. X : Isn't it? Me : If I look at a map of decision making then testing (specifically TDD) is an engineering topic (see figure 1) but the development part is firmly a craft (see figure 2). If we want to make development an engineering subject then we need to learn from testing i.e. we should be building context specific tools (think a test suite) from lots of micro tools (think tests). See figure 3. X : And AI can help? Me : Oh, yes. In two parts - the construction of micro tools which helps us improve our ttA (time to answer) and in the construction of new hypothesis which helps us improve our ttQ (time to question). See figure 4. X : And is that happening? Me : Very slowly. Remember you have a multi billion dollar tool industry that doesn't want you creating tools and hence they're trying to flog you old tools with a skim of AI. X : But we need people selling pickaxes. Me : Sure. But they've been telling us that their pickaxes work everywhere ... making soup, you need a pickaxe with added AI. X : But coding is coding. Me : An electronic healthcare system is not the same as an online gambling site. The contexts are completely different. It's why the test suites are different and a test is nothing more than a micro tool. Why don't we compose our tool for that context out of micro tools ... just like testing? X : Because it's hard? Me: Pickaxe salespeople must love you. That's their marketing literature. Reminds me of the early days of Test Driven Development (TDD) where most people thought it was mad to build a test suite out of thousands of small tests. | 44 comments on LinkedIn
Growing Graphs
Experimental simulation of emergent complexity through graph-rewriting automata.

Teach Yourself Programming in Ten Years
The conclusion is that either people are in a big rush to learn about programming, or that programming is somehow fabulously easier to learn than anything else. Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies." The Abtruse Goose comic also had their take.
Understanding is the new bottleneck
Agents can write code faster than we can absorb it. Here's why it still matters for humans to understand what they build — and some techniques for doing that efficiently: explainer docs, quizzes, micro-worlds, and shared spaces.
