Finally in Amsterdam after an extended stay in Belgrade, Serbia!! I’ve accepted a Cloud Engineer role at Sensys Gatso Group and I’m building a new normal around it.

Moving through life with more intention. At the moment that means focusing on Health (sleep hygiene and training), learning fast in the new role, and reading well: the Jane Austen classics and the Bible.

Routine

There is freedom in having a thought out structure to life.

A routine is something I’ve been iterating on for years. This latest iteration is the culmination of all my efforts and I’m really happy with it.

Up with the sun, creatine and amino water, no phone for the first hour. Journal and walk before the office 2-3 days a week with consistent hours, gym on the days I’m home. Game dev after work, no screens from 9pm, then reading before bed. Fasting until lunch, eating only between 12pm and 6pm.

I use pomodoro timers to gamify focus time across my days.

Building

I’m making a 2D exploration golf game in the Godot engine!! It’s built around a swing mechanic I haven’t seen anywhere else in my research. Watch this space.

See the tech I’m using here: Tech Stack.

I’ve read this book twice now, once early on in my career and again now whilst having a breadth of more DevOps experience at companies with different levels of DevOps maturity. I found myself skimming sections that weren’t as useful to me now, but re-reading in detail sections I found new insights from. You’ll be able to tell which based on my most recent quote pulls at the end. The whole book hangs off the Three Ways, which is kind of funny because Taoism talks about “The Way”, so this recent reading reminded me of Taoism and the book I recently read there.

• The First Way is flow: get work moving left to right, from the business to the customer, as fast as possible.
• The Second Way is feedback: get signal moving right to left, fast and constantly, so problems get fixed near where they were made.
• The Third Way is a culture of experimentation and learning, where you deliberately take risks and treat failure as information rather than something to hide.

The best companies I’ve worked at give a culture safety to experimentation, AND provide tooling to support safe experiments. Which in essence gives cultural safety again! If deploys are scary, that’s a signal about your architecture and your test coverage, not about the inherent difficulty of shipping.

Continuous integration, trunk-based development, telemetry everywhere(!!!), feature flags, and labelling low-risk releases.

Small batches of changes are important to make failures small, cheap, easy to attribute, and easy to rollback. Big batches make failures ambiguous and tough to revert.

The importance of blameless postmortem was rehighlighted here, Atlassian has a great doc on it. The argument is that blame drives information under the rug, if naming a cause means naming a person who gets punished, you stop learning what actually happened, remove cultural safety of experimentation, and reduce the effectiveness of the whole investigation.

Workshops and their importance to get everyone involved so we can discover the quick wins; this is workshops including both tech experts, decision makers, and domain experts.

Value Stream mapping is next exercise, showing how new features (or new value) is added to the app. Probably customer request or business hypothesis, flowing through planning, dev, and deploy. There is skill involved in identifying the teams involved with a given Value stream. I think that a value stream is a domain within a company and the value that a given team (or cluster of teams) offers the customer.

One key thing that tends to happen is surfacing of the many heroics across the business. Normally we think of heroics as great, but in DevOps of someone has to be a hero than the process has failed us and we should fix that process. Minimising heroics from the team, like late nights or weekend works, is important for the longevity of the dev team overall.

Deployment methodologies for safe deployments, one method is blue/green databases with a switch the flicks over post-successful deployment. The better solution is to actually decouple the database changes from the application, this is what I’ve seen done more often than not. No deletion of columns, and make sure the changes are additive only. Complex db changes require different approaches.

Use the strangler patter to safely evolve the architecture of a system over time. The strangler pattern is worth knowing about, I experienced this during my time at Xero.

Quotes

Introductions

High performers deployed code thirty times more frequently, and the time required to go from “code committed” to “successfully running in production” was two hundred times faster—high performers had lead times measured in minutes or hours, while low performers had lead times measured in weeks, months, or even quarters.

Another more extreme example is Amazon. In 2011, Amazon was performing approximately seven thousand deploys per day. By 2015, they were performing 130,000 deploys per day.

We describe value streams, how DevOps is the result of applying Lean principles to the technology value stream, and the Three Ways: Flow, Feedback, and Continual Learning and Experimentation.

Part I — The Three Ways

Improving daily work is even more important than doing daily work.

In addition to lead times and process times, the third key metric in the technology value stream is percent complete and accurate (%C/A). This metric reflects the quality of the output of each step in our value stream. Karen Martin and Mike Osterling state that “the %C/A can be obtained by asking downstream customers what percentage of the time they receive work that is ‘usable as is,’ meaning that they can do their work without having to correct the information that was provided, add missing information that should have been supplied, or clarify information that should have and could have been clearer.”

By seeing problems as they occur and swarming them until effective countermeasures are in place, we continually shorten and amplify our feedback loops, a core tenet of virtually all modern process improvement methodologies. This maximizes the opportunities for our organization to learn and improve.

The First Way: The Principles of Flow

Work is not done when Development completes the implementation of a feature—rather, it is only done when our application is running successfully in production, delivering value to the customer.

REDUCE THE NUMBER OF HANDOFFS

High performers, regardless of whether an engineer is in Development, QA, Ops, or Infosec, state that their goal is to help maximize developer productivity.

The Second Way: The Principles of Feedback

Dr. Sidney Dekker, who also codified some of the key elements of safety culture, observed another characteristic of complex systems: doing the same thing twice will not predictably or necessarily lead to the same result. It is this characteristic that makes static checklists and best practices, while valuable, insufficient to prevent catastrophes from occurring.

We use peer reviews of our proposed changes to gain whatever assurance is needed that our changes will operate as designed. We automate as much of the quality checking typically performed by a QA or Information Security department as possible. Instead of developers needing to request or schedule a test to be run, these tests can be performed on demand, enabling developers to quickly test their own code and even deploy those changes into production themselves. By doing this, we truly make quality everyone’s responsibility as opposed to it being the sole responsibility of a separate department.

The Third Way: The Principles of Continuous Learning and Experimentation

The leader helps coach the person conducting the experiment with questions that may include:

• What was your last step and what happened?
• What did you learn?
• What is your condition now?
• What is your next target condition?
• What obstacle are you working on now?
• What is your next step?
• What is your expected outcome?
• When can we check?

Part II — Where to Start

Instead of the top-down, command-and-control approach, we need broad support from throughout the organization, especially from those doing the daily work.

Find Innovators and Early Adopters: In the beginning, we focus our efforts on teams who actually want to help—these are our kindred spirits and fellow travelers who are the first to volunteer to start the DevOps journey.

Based on their research, Dr. Govindarajan and Dr. Trimble assert that organizations need to create a dedicated transformation team that is able to operate outside of the rest of the organization that is responsible for daily operations (which they call the “dedicated team” and “performance engine” respectively).

By dedicating 20% of our cycles so that Dev and Ops can create lasting countermeasures to the problems we encounter in our daily work, we ensure that technical debt doesn’t impede our ability to quickly and safely develop and operate our services in production.

These observations led to what is now known as Conway’s Law, which states that “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations…. The larger an organization is, the less flexibility it has and the more pronounced the phenomenon.”

In high-performing organizations, everyone within the team shares a common goal—quality, availability, and security aren’t the responsibility of individual departments, but are a part of everyone’s job, every day.

As Jason Cox, Director of Systems Engineering at Disney, described, “Inside of Operations, we had to change our hiring practices. We looked for people who had ‘curiosity, courage, and candor,’ who were not only capable of being generalists but also renegades… We want to promote positive disruption so our business doesn’t get stuck and can move into the future.”

Another way to enable high-performing outcomes is to create stable service teams with ongoing funding to execute their own strategy and road map of initiatives. These teams have the dedicated engineers needed to deliver on concrete commitments made to internal and external customers, such as features, stories, and tasks.

Another way we can enable more market-oriented outcomes is by enabling product teams to become more self-sufficient by embedding Operations engineers within them, thus reducing their reliance on centralized Operations.

Part III — The First Way: Flow

Deploying the same way to every environment

But why does using version control for our environments predict IT and organizational performance better than using version control for our code? Because in almost all cases, there are orders of magnitude more configurable settings in our environment than in our code. Consequently, it is the environment that needs to be in version control the most.

In other words, we will only accept development work as done when it can be successfully built, deployed, and confirmed that it runs as expected in a production-like environment, instead of merely when a developer believes it to be done—ideally, it runs under a production-like load with a production-like dataset, long before the end of a sprint.

ADOPT TRUNK-BASED DEVELOPMENT PRACTICES

Frequent code commits to trunk means we can run all automated tests on our software system as a whole and receive alerts when a change breaks some other part of the application or interferes with the work of another developer. And because we can detect merge problems when they are small, we can correct them faster.

Of course, we know that we need to be deploying more frequently to achieve our desired outcome of smooth and fast flow, not less frequently. To enable this, we need to decouple our production deployments from our feature releases. In practice, the terms deployment and release are often used interchangeably.

Gracefully degrade performance: When our service experiences extremely high loads that would normally require us to increase capacity or, worse, risk having our service fail in production, we can use feature toggles to reduce the quality of service. In other words, we can increase the number of users we serve by reducing the level of functionality delivered (e.g., reduce the number of customers who can access a certain feature, disable CPU-intensive features such as recommendations, etc.).

Part IV — The Second Way: Feedback

As Adrian Cockcroft pointed out, “Monitoring is so important that our monitoring systems need to be more available and scalable than the systems being monitored.”

To enable everyone to be able to find and fix problems in their daily work, we need to enable everyone to create metrics in their daily work that can be easily created, displayed, and analyzed.

When critical production services have problems, waking people at 2 a.m. may be the right thing to do. However, when we create alerts that are not actionable or are false-positives, we’ve unnecessarily woken up people in the middle of the night.

Tom Limoncelli, co-author of The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems and a former Site Reliability Engineer at Google, relates the following story on monitoring: “When people ask me for recommendations on what to monitor, I joke that in an ideal world, we would delete all the alerts we currently have in our monitoring system. Then, after each user-visible outage, we’d ask what indicators would have predicted that outage and then add those to our monitoring system, alerting as needed. Repeat. Now we only have alerts that prevent outages, as opposed to being bombarded by alerts after an outage already occurred.”

Before we build a feature, we should rigorously ask ourselves, “Should we build it, and why?” We should then perform the cheapest and fastest experiments possible to validate through user research whether the intended feature will actually achieve the desired outcomes. We can use techniques such as hypothesis-driven development, customer acquisition funnels, and A/ B testing, concepts we explore throughout this chapter.

The surprising reality is that in environments with low-trust, command-and-control cultures, the outcomes of these types of change control and testing countermeasures often result in an increased likelihood that problems will occur again, potentially with even worse outcomes.

One of the core beliefs in the Toyota Production System is that “people closest to a problem typically know the most about it.”

Pair programming has the additional benefit of spreading knowledge throughout the organization and increasing information flow within the team. Having more experienced engineers review while the less experienced engineer codes is also an effective way to teach and be taught.

Part V — The Third Way: Continual Learning and Experimentation

Blameless post-mortems are about accurately learning what happened, not about assigning blame.

During the meeting and the subsequent resolution, we should explicitly disallow the phrases “would have” or “could have,” as they are counterfactual statements that result from our human tendency to create possible alternatives to events that have already occurred. Counterfactual statements, such as “I could have…” or “If I had known about that, I should have…,” frame the problem in terms of the system as imagined instead of in terms of the system that actually exists, which is the context we need to restrict ourselves to.

In addition to the Lean-oriented terms kaizen blitz and improvement blitz, the technique of dedicated rituals for improvement work has also been called spring or fall cleanings and ticket queue inversion weeks. Other terms have also been used, such as hack days, hackathons, and 20% innovation time.

A dynamic culture of learning creates conditions so that everyone can not only learn, but also teach, whether through traditional didactic methods (e.g., people taking classes, attending training) or more experiential or open methods (e.g., conferences, workshops, mentoring). One way that we can foster this teaching and learning is to dedicate organizational time to it.

Bland said, at that time, there was a 20% innovation time policy at Google, enabling developers to spend roughly one day per week on a Google-related project outside of their primary area of responsibility. Some engineers chose to form grouplets, ad hoc teams of like-minded engineers who wanted to pool their 20% time, allowing them to do focused improvement blitzes.

Part VI: Integrating Security, Change Management and Compliance

Instead of inspecting security into our product at the end of the process, we will create and integrate security controls into the daily work of Development and Operations, so that security is part of everyone’s job, every day. Ideally, this work will be automated and put into our deployment pipeline. Furthermore, we will augment our manual practices, acceptances, and approval processes with automated controls, relying less on controls such as separation of duties and change approval processes.

Source code integrity and code signing: All developers should have their own PGP key, perhaps created and managed in a system such as keybase.io.

OWASP publishes a great deal of useful guidance such as the Cheat Sheet series, which includes: How to store passwords How to handle forgotten passwords How to handle logging How to prevent cross-site scripting (XSS) vulnerabilities

No one actually looks at the unit tests, and they’re run every time someone commits code to the repo.” This demonstrates that in order to adequately protect the integrity of our applications and environments, we must also mitigate the attack vectors on our deployment pipeline.

In this case, we must ensure that any submitted change requests are as complete and accurate as possible, giving the CAB everything they need to properly evaluate our change—after all, if our change request is malformed or incomplete, it will be bounced back to us, increasing the time required for us to get into production and casting doubt on whether we actually understand the goals of the change management process.

For Mangot and Mathew, one of the key successes from all the repeatability and rigor they designed into the process was being told by their change management group that “infrastructure changes made through Puppet would now be treated as ‘standard changes,’ requiring far less or even no further approvals from the CAB.” Furthermore, they noted that “manual changes to infrastructure would still require approvals.”

Appendices

APPENDIX 9 THE SIMIAN ARMY After the 2011 AWS EAST Outage, Netflix had numerous discussions about engineering their systems to automatically deal with failure. These discussions have evolved into a service called “Chaos Monkey.”

Thankfully, I found Dev Containers, which turned into its own rabbit hole but lets us lock down Claude without having to maintain our own docker image.

This reflection post talks through the containerised setup and some issues I faced while setting it up. If you just want the solution, then the implementation is in the .devcontainer/ directory of this website’s source code.

Feature or docker image?

I assumed that Anthropic would ship an official Claude base image you build on top of. They don’t, they only post a recommended starting point. Claude Code installs into any Dev Container through the ghcr.io/anthropics/devcontainer-features/claude-code:1.0 feature, which you reference in devcontainer.json like any other devcontainers feature. It works wherever the Dev Containers spec is supported e.g. VS Code, Codespaces, JetBrains, and (with some rough edges) Cursor. In VS Code it can be configured to pull in the Claude Code extension, keeping Claude decoupled from the base image entirely.

That leaves three layers to assemble: a base image, the tooling you use, and Claude Code on top. The real decision is whether you bake those middle two layers into a custom docker image you push to a registry, or assemble them per-repo through devcontainer.json features. A custom image is the better call for a team, where you want a validated, secure, and reusable environment everyone builds on. For a solo setup spun up per-repo, features are easier. The cost is a slow first build and less control over exactly what lands in the image, which is what post-create.sh helps automate somewhat.

My devcontainer.json ended up looking like this, trimmed to the main parts:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  },
  "remoteUser": "vscode",
  "mounts": [
    "source=claude-code-config-${devcontainerId},target=/home/vscode/.claude,type=volume"
  ],
  "runArgs": ["--cap-add=NET_ADMIN", "--cap-add=NET_RAW"],
  "postCreateCommand": "sudo zsh .devcontainer/post-create.sh",
  "postStartCommand": "sudo /usr/local/sbin/init-firewall.sh",
  "waitFor": "postStartCommand"
}

The non-root vscode user is important if you ever run with --dangerously-skip-permissions, Claude Code requires it. The named volume on ~/.claude means login persists across rebuilds instead of re-authenticating every time. The NET_ADMIN/NET_RAW capabilities exist so that we can create the containerised firewall. waitFor: postStartCommand blocks the terminal until that firewall script finishes, so there’s no window where Claude is already running before egress is locked down.

post-create.sh is the everyday stuff a feature-based setup doesn’t hand you for free: setting git aliases, adding a couple of zsh aliases for kubectl and terraform, locking down sudo/su.

init-firewall.sh sets default-DROP policies on iptables, then builds an ipset allowlist of everything the container is allowed to reach outbound. Part of that allowlist is GitHub’s own published IP ranges, fetched live at container start:

gh_ranges=$(curl -s https://api.github.com/meta)
while read -r cidr; do
    ipset add allowed-domains "$cidr"
done < <(echo "$gh_ranges" | jq -r '(.web + .api + .git)[]' | aggregate -q)

Everything else —npm, api.anthropic.com, the VS Code marketplace— gets resolved and added individually. The firewall script finishes by checking its own work: it tries curl https://example.com and expects that to fail, then tries curl https://api.github.com/zen and expects that to succeed.

Firewall and sudo

I spent a decent chunk of time configuring who’s allowed to touch iptables. The common-utils feature grants the vscode user blanket passwordless sudo by default, and my first cut of post-create.sh narrowed that down to the iptables/iptables-save/ipset binaries themselves, with no argument restriction. Which meant Claude or anything else running as vscode, including under --dangerously-skip-permissions, could just run sudo iptables -F && sudo iptables -P OUTPUT ACCEPT and the firewall would be gone! Anthropic’s own reference devcontainer avoids this by granting sudo on one fixed script path instead of the raw binaries, baked into their image at build time so the script itself can’t be edited either. I didn’t want a custom Dockerfile yet, but dev containers can do the same thing with just postCreateCommand: copy init-firewall.sh to a root-owned /usr/local/sbin/init-firewall.sh outside the bind-mounted workspace while the feature’s broad sudo grant is still active, then narrow sudo down to NOPASSWD on that one frozen executable file only. The tradeoff is that editing the live init-firewall.sh to allow a new domain now needs a full Rebuild Container, not just a restart, since the frozen copy is what actually runs.

Claude has it’s own way to limit it’s own execution too using .claude/settings.json. We’ve configured this on top to deny any Bash(sudo *) and Bash(su *) commands, so in normal mode Claude won’t even attempt the command. But --dangerously-skip-permissions does exactly what its name says: it bypasses every permission rule, deny rules included. So that file is a speed bump for the default mode, not something to lean on once the safety’s off. The frozen-script sudoers restriction is the one that locks it down regardless, because it’s enforced by the OS, not by Claude Code.

Gap in the firewall

One thing I noticed was that api.github.com/meta’s ip ranges aren’t scoped to the API. They cover GitHub’s whole edge network, which includes GitHub Pages in some cases. For example, this website, westernwilson.com, runs on GitHub Pages. So with the firewall up and supposedly restricting the agent to an approved set of domains, I could still reach my own site. And by the same logic, any other *.github.io page, or anything hosted there by someone with worse intentions. A page on *.github.io could potentially hold a payload hosted somewhere else entirely, and the firewall would wave it through without ever knowing the difference.

I see three ways to close that off:

• Proxy the traffic and filter on hostname instead of IP. Cleanest in theory, but Encrypted Client Hello can still hide the hostname from anything sitting.
• Drop *.github.io from the allowlist entirely. Unfortunately this also takes raw.githubusercontent.com out too since they share the same ip ranges, but if that’s not something the container needs, it’s a fine trade.
• Accept the risk and move on.

I haven’t picked one yet, for now I’m sitting with the risk while I think about which tradeoff is actually worth it.

Logging in to Claude

Logging in had its own gotcha. In VS Code there is a big orange “use your subscription” button that opens a browser and waits for a callback to localhost, which never makes it back into the container and just hangs. The fix is to skip the button, open a terminal inside the container and run claude, which kicks off the same browser flow but resolves the callback correctly.

We then use ~/.claude, which is now owned by the vscode thanks to the chown at the top of post-create.sh, so once logged in, we gain stickier login sessions.

In doing the whole login dance from a bare terminal meant that my first real session with Claude Code inside the dev container was just text based interaction with no IDE extension wrapper around it at all. It’s an interesting way to work and removes a lot of the UI distraction, but not something I’ll rely on fulltime.

Port forwarding

The other thing that briefly worried me is VS Code forwarded around thirty-two ports the moment the container came up. My first thought was that something in the container was reaching out on its own. It’s not, after some searching I found that it’s VS Code’s automatic port-forwarding scanning the container for anything listening on a port, for example a dev server that you’ll want to open in a browser. It’s a separate, fairly trigger-happy feature, and apparently a known source of noise; This GitHub issue describes the exact same “over 20 ports auto-forwarded” behaviour after a setting silently flips from process to hybrid detection mode.

If you want to see the actual config rather than the excerpts above, it’s all in this repo under .devcontainer/. Treat it as a personal setup to extend, not a hardened image to copy verbatim.

Further reading: Anthropic’s Dev Containers docs and the VS Code Dev Containers tutorial.

This book is packed with examples and opinions by people with decades of experience. Martin has clearly written a lot of code and seen a lot of projects go sideways, then picked up the pieces and improved them.

My main takeaway is that the cost of bad code is huge, and it compounds over time. A team that moves fast with messy code will eventually stall. Anyone who has picked up someone else’s code and spent an hour just trying to figure out what it does will know exactly what he means.

Somewhere in the first chapter he makes a link between the abstraction away from byte code to assembly to object oriented languages, then expands further to consider a new AI system that will do our jobs for us (similar to what we are living through). It gave me a strong sense that no matter what level of abstraction we rise to (AI non-deterministic prompting being the latest), we still need strong, clear communication of our ideas.

There was a comment about Coders being essentially Authors, I don’t know why, but was a paradigm shift in my brain. We are writers using language syntax that tells machines what to do, but also has to show other Authors/engineers what it does. So be professional and communicate clearly. You’ve read bad articles or books, and you’ve read good ones, make sure your code aligns closely with the good ones.

He put a lot of emphasis on the effort you should spend on good names. But not letting that effort slow you down because it is refactorable. Both of these change how I think about naming things.

A clever shorthand variable name might save you ten seconds when you write it, but it’ll cost the next person ten minutes when they read it.

A good variable or function name is a small piece of documentation that you never have to keep in sync with the code, because it is the code. The time you spend thinking of a better name is almost always worth it.

Functions should do one thing. That principle sounds obvious until you realise how hard it actually is to follow. While reading this chapter I remembered functions I’d written that did a few things, and cringed. Ideally, the function should do one thing well, and be named in line with exactly what it does.

I’d heard these comment vs code arguments from an old colleague, this book reemphasised what he was saying. Comments are a failure; they’re a sign that the code isn’t clear enough to speak for itself. Every comment you write is maintenance debt. Code changes; comments drift. There’s nothing worse than a comment that confidently describes something the code no longer does. I agreed with this chapter wholeheartedly.

The boy scout rule is great too: leave the campground cleaner than you found it. Don’t just fix the bug and ship it. Rename the thing that confused you, or extract the chunk that didn’t belong. Don’t rewriting everything, but small incremental improvements accumulating over time into a codebase makes it actually pleasant to work in.

One key idea to me was the purpose of writing OOP; from what I gather, it’s to make the code easily changeable and extensible in such a way that future features are easier to add. This tends to look like standardised patterns so you know exactly how to make changes to extend the code without stepping on each others toes. By following uncle Bob’s rules in this book, you can both make code easy to understand, but also easy to change.

The final chapters taught me that writing clean code is not something you get right the first time. It’s like writing an article or blog post, you have multiple stages of drafts, and over time the output condenses into something legible.

The book shows a systematic way go from idea to messy code, then from messy code to refactored clean code (iteratively). To do this, automated unit tests are a requirement. OOP helps make testing easier by abstracting away key components of the system.

Quotes

Foreword

Clean code honors the deep roots of wisdom beneath our broader culture, or our culture as it once was, or should be, and can be with attentiveness to detail.

It is a recommended practice in Scrum that re-factoring be part of the concept of “Done.” Neither architecture nor clean code insist on perfection, only on honesty and doing the best we can. To err is human; to forgive, divine. In Scrum, we make everything visible. We air our dirty laundry. We are honest about the state of our code because code is never perfect.

Chapter 1 Clean Code

Yo… AI? It’s not there yet, not sure if it will ever be.

They are hoping that one day we will discover a way to create machines that can do what we want rather than what we say. These machines will have to be able to understand us so well that they can translate vaguely specified needs into perfectly executing programs that precisely meet those needs.

Truth. Though I strive to not allow it to be my truth.

We’ve all said we’d go back and clean it up later. Of course, in those days we didn’t know LeBlanc’s law: Later equals never .

I worked somewhere stuck in this same situation, it’s so refreshing to know that 1) it wasn’t a unique experience to me, and 2) that there are ways around it.

Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does. This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.

You will not make the deadline by making the mess. Indeed, the mess will slow you down instantly, and will force you to miss the deadline. The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

Bjarne Stroustrup, inventor of C + + and author of The C + + Programming Language

But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.

We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

It’s not enough to write the code well. The code has to be kept clean over time. We’ve all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.

Chapter 2 Meningful Names

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

Classes and objects should have noun or noun phrase names like Customer , WikiPage , Account , and AddressParser . Avoid words like Manager , Processor , Data , or Info in the name of a class. A class name should not be a verb.

Single-letter variable names are only acceptable as loop counters. Everything else deserves better.

The name AccountVisitor means a great deal to a programmer who is familiar with the VISITOR pattern. What programmer would not know what a JobQueue was? There are lots of very technical things that programmers have to do. Choosing technical names for those things is usually the most appropriate course.

Chapter 3 Functions

Functions that do one thing cannot be reasonably divided into sections. … To say this differently, we want to be able to read the program as though it were a set of TO paragraphs, each of which is describing the current level of abstraction and referencing subsequent TO paragraphs at the next level down. To include the setups and teardowns, we include setups, then we include the test page content, and then we include the teardowns.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Functions should do one thing. They should do it well. They should do it only. This feels achievable until you’re actually in the middle of writing something and you just want to add one more thing because it’s almost related.

A function with two arguments is harder to understand than a monadic function. For example, writeField( name) is easier to understand than writeField( output-Stream, name). Though the meaning of both is clear, the first glides past the eye, easily depositing its meaning. The second requires a short pause until we learn to ignore the first parameter. And that, of course, eventually results in problems because we should never ignore any part of code. The parts we ignore are where the bugs will hide.

Have No Side Effects Side effects are lies. Your function promises to do one thing, but it also does other hidden things. Sometimes it will make unexpected changes to the variables of its own class.

In general output arguments should be avoided. If your function must change the state of something, have it change the state of its owning object.

On the other hand, if you use exceptions instead of returned error codes, then the error processing code can be separated from the happy path code and can be simplified:

Chapter 4 Comments

So when you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code.

Others who see that commented-out code won’t have the courage to delete it. They’ll think it is there for a reason and is too important to delete.

Every time you write a comment, you should grimace and feel the failure of your ability of expression.

Chapter 5 Formatting

We use horizontal white space to associate things that are strongly related and disassociate things that are more weakly related.

Chapter 6 Objects and Data Structures

In any complex system there are going to be times when we want to add new data types rather than new functions. For these cases objects and OO are most appropriate. On the other hand, there will also be times when we’ll want to add new functions as opposed to data types. In that case procedural code and data structures will be more appropriate.

More precisely, the Law of Demeter says that a method f of a class C should only call the methods of these: • C • An object created by f • An object passed as an argument to f • An object held in an instance variable of C The method should not invoke methods on objects that are returned by any of the allowed functions.

I wrote a note here to look more into procedural vs oop methodoloies and programming.

They have functions that do significant things, and they also have either public variables or public accessors and mutators that, for all intents and purposes, make the private variables public, tempting other external functions to use those variables the way a procedural program would use a data structure.

The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit.

Chapter 7 Use Exceptions Rather Than Return Codes

Use Exceptions Rather Than Return Codes

Create informative error messages and pass them along with your exceptions. Mention the operation that failed and the type of failure. If you are logging in your application, pass along enough information to be able to log the error in your catch.

It’s easy to say that the problem with the code above is that it is missing a null check, but in actuality, the problem is that it has too many. If you are tempted to return null from a method, consider throwing an exception or returning a SPECIAL CASE object instead.

Chapter 8 Boundaries

If you use a boundary interface like Map, keep it inside the class, or close family of classes, where it is used. Avoid returning it from, or accepting it as an argument to, public APIs.

In learning tests we call the third-party API, as we expect to use it in our application. We’re essentially doing controlled experiments that check our understanding of that API. The tests focus on what we want out of the API.

We manage third-party boundaries by having very few places in the code that refer to them. We may wrap them as we did with Map , or we may use an ADAPTER to convert from our perfect interface to the provided interface. Either way our code speaks to us better, promotes internally consistent usage across the boundary, and has fewer maintenance points when the third-party code changes.

Chapter 9 Unit Tests

in the mad rush to add testing to our discipline, many programmers have missed some of the more subtle, and important, points of writing good tests.

First Law You may not write production code until you have written a failing unit test. Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing. Third Law You may not write more production code than is sufficient to pass the currently failing test.

The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

That is the nature of the dual standard. There are things that you might never do in a production environment that are perfectly fine in a test environment. Usually they involve issues of memory or CPU efficiency. But they never involve issues of cleanliness.

Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.

Clean boundaries. Code at the boundaries needs clear separation and tests that define expectations. There’s a whole class of bugs that only exist because the assumptions on one side of an API boundary were never written down anywhere. Tests are the written-down version.

Chapter 10 Classes

There is seldom a good reason to have a public variable. Public functions should follow the list of variables. We like to put the private utilities called by a public function right after the public function itself. This follows the stepdown rule and helps the program read like a newspaper article.

With functions we measured size by counting physical lines. With classes we use a different measure. We count responsibilities

The problem is that too many of us think that we are done once the program works. We fail to switch to the other concern of organization and cleanliness. We move on to the next problem rather than going back and breaking the overstuffed classes into decoupled units with single responsibilities.

many developers fear that a large number of small, single-purpose classes makes it more difficult to understand the bigger picture. They are concerned that they must navigate from class to class in order to figure out how a larger piece of work gets accomplished. However, a system with many small classes has no more moving parts than a system with a few large classes. There is just as much to learn in the system with a few large classes. So the question is: Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?

To restate the former points for emphasis: We want our systems to be composed of many small classes, not a few large ones.

We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which represent concepts only.

Chapter 11 Systems

Domain-Specific Languages allow all levels of abstraction and all domains in the application to be expressed as POJOs, from high-level policy to low-level details.

Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work .

Chapter 12 Emergence

As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance. You can express yourself by choosing good names. We want to be able to hear a class or function name and not be surprised when we discover its responsibilities. You can also express yourself by keeping your functions and classes small. Small classes and functions are usually easy to name, easy to write, and easy to understand.

Chapter 13 Concurrency

Recommendation : Write tests that have the potential to expose problems and then run them frequently, with different programatic configurations and system configurations and load. If tests ever fail, track down the failure. Don’t ignore a failure just because the tests pass on a subsequent run.

Recommendation : Run your threaded code on all target platforms early and often.

The point is to jiggle the code so that threads run in different orderings at different times. The combination of well-written tests and jiggling can dramatically increase the chance finding errors.

Chapter 14 JUnit Internals

I don’t like the way that the last two lines of the new function return variables, but the first two don’t. They aren’t using consistent conventions [G11]. So we should change findCommonPrefix and findCommonSuffix to return the prefix and suffix values.

Chapter 16 Refactoring SerialDate

This chapter was hard to read on my ereader, like it took a bit of time to disect what was happening. But the explanations that walked you through his thinking when refactoring was SO GOOD. There are probably Youtubers who walk through code like this too, giving me a new angle and new lease on thinking about writing good code.

It’s generally a bad idea for base classes to know about their derivatives. To fix this, we should use the ABSTRACT FACTORY 3 pattern and create a DayDateFactory . This factory will create the instances of DayDate that we need and can also answer questions about the implementation, such as the maximum and minimum dates.

The next abstract method is toDate (lines 838–844). It converts a DayDate to a java.util.Date . Why is this method abstract? If we look at its implementation in SpreadsheetDate (lines 198–207, Listing B-5 , page 382 ), we see that it doesn’t depend on anything in the implementation of that class [G6]. So I pushed it up.

Chapter 17 Smells and Heuristics

All else being equal, we want to eliminate Feature Envy because it exposes the internals of one class to another. Sometimes, however, Feature Envy is a necessary evil.

This is a great example of how to make code more readable by avoiding selector arguments. With selector arguments we break the single responsibility principle, which is bad because it makes the code harder to understand.

There is hardly anything more abominable than a dangling false argument at the end of a function call. What does it mean? What would it change if it were true ? Not only is the purpose of a selector argument difficult to remember, each selector argument combines many functions into one.

I like this, I often get troubled with reading boundaries for ++ or -=1 and sometimes result to trial and error.

Notice that level + 1 appears twice. This is a boundary condition that should be encapsulated within a variable named something like nextLevel . int nextLevel = level + 1; if( nextLevel < tags.length) { parts = new Parse( body, tags, nextLevel, offset + endTag); body = null; }

More specifically, if A collaborates with B , and B collaborates with C , we don’t want modules that use A to know about C . (For example, we don’t want a.getB(). getC(). doSomething() ;.) This is sometimes called the Law of Demeter. The Pragmatic Programmers call it “Writing Shy Code.” 12 In

Rather we want our immediate collaborators to offer all the services we need. We should not have to roam through the object graph of the system, hunting for the method we want to call. Rather we should simply be able to say: myCollaborator.doSomething().

J2: Don’t Inherit Constants I have seen this several times and it always makes me grimace. A programmer puts some constants in an interface and then gains access to those constants by inheriting that interface.

T6: Exhaustively Test Near Bugs Bugs tend to congregate. When you find a bug in a function, it is wise to do an exhaustive test of that function. You’ll probably find that the bug was not alone.

Appendix A Concurrency II

On evaluating and understanding how complex async programming becomes.

If the code is processor bound, more processing hardware can improve throughput, making our test pass. But there are only so many CPU cycles available, so adding threads to a processor-bound problem will not make it go faster. On the other hand, if the process is I/ O bound, then concurrency can increase efficiency. When one part of the system is waiting for I/ O, another part can use that wait time to process something else,

And this is a simple problem. If we cannot demonstrate broken code easily with this problem, how will we ever detect truly complex problems? So what approaches can we take to demonstrate this simple failure? And, more importantly, how can we write tests that will demonstrate failures in more complex code? How will we be able to discover if our code has failures when we do not know where to look?

Hardware & software of choice

• Macbook Pro 16
• AnyType for personal notes
• Claude
• Flow for pomodoro timing
• Arc browser
• Kindle ereader (11th Gen Paperwhite)

Technical Stack

• Cloud & Infrastructure: AWS (EKS, IAM, RDS), Terraform, Docker, Kubernetes, Helm, PostgreSQL, OpenStack, GCP (wanting to learn)
• CI/CD: GitHub Actions, TeamCity, Octopus Deploy
• Languages: Python (FastAPI, Flask), Bash, Go (learning), some C# & Java
• Observability: New Relic, Sumo Logic, Prometheus, Grafana, Kibana / ELK
• Practices: REST API Design • Infrastructure as Code • Observability • Security Controls • Agile/Scrum

Also worked with:

• Frontend: Vue.js (Nuxt), React (Next.js), Tailwind CSS, Hugo
• ML basics: Google’s MLCC with hands-on experience using Pandas, NumPy, TensorFlow

A highlight has been hearing the difference between Germanic, Slavic, and Romance languages up close. Back home in NZ I mostly heard English, some Cantonese, and a little Māori, so all these new sounds have been a great for my brain.

The food everywhere has been amazing too, nothing crazy adventurous, but plenty to satisfy the palate.

• Greece: Island hopping was fantastic, friendly people, and such a rich history. We toured the major islands and timed Mykonos perfectly, just before party season kicked off. We had room to walk and explore without the crowds. Saw a lot of churches and heard about the various empires that occupied these parts.
• Denmark: Beautiful but expensive. Everyone wears gorgeous, sustainable, layered clothing. This makes sense given how much colder it is than NZ. Metro made it so easy to get around. Bikes everywhere.
• Amsterdam: Visited to explore Amsterdam and also for a bunq hackathon (reflection here). I loved the vibe, though getting around without a bike was slow. So a bike is the first thing I’m getting once I live there. Free ferries were fantastic!
• Italy: Five days in Rome. It felt like you could walk in any direction and stumble onto a grand church or building. The food here was the best I’ve had anywhere, once we found one particular shop’s tiramisu we ate three in a single day. Also saw Michelangelo’s Creation of Adam on the Sistine Chapel ceiling, the scale of it is hard to describe. I guess it was well over 4 years of his life!
• Croatia: Some of the best scenery I’ve seen outside of New Zealand. We hired a car and drove from Zagreb to Split, stopping at the Plitvice Lakes National Park in between for some incredible waterfalls. Driving on the opposite side of the road took adjusting (NZ left-side and Croatia right-side), but having a car unlocked so many random stops for our journey.
• Serbia: A taxi driver suggest Burek to me and I ate it most days. I learnt about Belgrade’s hectic history, even up until recently. I’m in awe of what people there have survived, over four passport changes in the last 25 years and across many different occupations. We were told it’s because of Belgrade is positioned on the Danube and Sava rivers, prime real estate with a fortress that holds the high ground.

Scrolling through job listings this past month, I noticed roles titled DevOps Engineer or Platform Engineer or Infrastructure Engineer that were listed with almost identical responsibilities.

I know innately that these roles have some differences, but the titles are often used interchangeably by hiring teams.

Where DevOps came from

DevOps is a word created from the combination of the words Developer and Operations. To understand why that portmanteau word became a job title, you need to understand the problem it was trying to solve.

Traditionally, software teams were split in two. Developers wrote code in one room, and an Operations team —sometimes called Ops— deployed and ran that code in production. Each group had different incentives e.g. devs wanted to ship fast whilst ops wanted stability. That tension caused friction, slow releases, and potentially a blame culture when things broke.

The DevOps movement, popularised in part by The Phoenix Project (Kim, Behr, Spafford, 2013) and The DevOps Handbook, proposed a cultural fix to tear down that wall. If developers owned their code all the way to production, they’d build with operability in mind. They’d care about deployment pipelines, alerting, and recovery because those things would become their problem too.

DevOps is meant to be a shared practice of principles across teams, and not a single person’s role. But organisations found it easier to spin up a DevOps teams or hire someone with the DevOps title who embodied that DevOps mindset to show some adoption of “DevOps” when it was first cool.

What a DevOps Engineer actually does

In practice, the DevOps Engineer tends to be embedded within a product team, sometimes as the only person with that focus. Their job is improving the speed and safety of getting code from a developer’s machine into production.

That means CI/CD pipelines (think GitHub Actions, TeamCity, CircleCI, or similar), automated testing, deployment automation, monitoring and alerting, and security gates. If a developer is waiting too long for a build, or a deployment is a manual, error-prone process, the DevOps Engineer is the one called on.

My own experience working in this role felt exactly like that: a solo DevOps expert embedded in a development team, focused on making the production path faster and more reliable. In smaller companies you will probably get the opportunity to pick up other development tasks outside of the usual job description. This helps you experience the pain that engineers go through to build better solutions.

Platform Engineering

Platform Engineering has similar tools and similar outcomes, but from what I’ve seen, the scope and audience are different.

Where a DevOps Engineer typically serves one team, a Platform Engineer serves many. This role, I think, is oriented around building an Internal Developer Platform (IDP). An IDP is a curated set of tools, templates, and standards that every engineering team in an organisation can use. The CNCF communities often describe this as building golden paths: opinionated, well-maintained routes that make the right thing the easy thing for developers to do.

Think of it as the difference between solving a problem for your team versus building the infrastructure so any team can solve that problem themselves. Platform teams treat internal developers as their customers. They build self-service tooling —things like standardised deployment workflows, observability stacks, or secrets management patterns— so that product teams don’t have to reinvent those wheels independently.

This tends to appear at larger organisations, where inconsistency across teams becomes a bigger cost. At a company with ten engineers, one strong DevOps person can handle everything informally. At a company with five hundred, the absence of shared standards can create chaos.

The tradeoff here is somehow creating efficient standards to keep things stable, but also giving optionality to engineers so they have autonomy over the tooling they choose.

A good tool to know about is Spotify’s open source Backstage tool: https://backstage.io/

Infrastructure Engineering

Infrastructure Engineering overlaps with both DevOps and Platform, but sits slightly further from application code in my experience.

An Infrastructure Engineer is typically focused on the foundations: cloud architecture, networking, access management, and the security controls that sit beneath the application layer. They’re thinking about VPCs, subnets, firewall rules, load balancers, DNS, and how services communicate across boundaries. Often this involves deep expertise with IaC tools like Terraform and close familiarity with the cloud provider’s lower-level primitives.

A DevOps Engineer might spend their day modifying a GitHub Actions workflow or adjusting a Dockerfile. An Infrastructure Engineer might spend theirs designing the network topology that those pipelines eventually deploy into.

That said, in my experience, in any organisation you have problems to solve and there is never a clean separation. So you’re owning all of it, and carrying all three titles simultaneously whenever something is required.

Why the roles overlap

There are more than the three role titles I’ve talked about too, e.g. Systems Engineer, Site Reliability Engineer, Integration Engineer, and many others that cover similar responsibilities with decent overlap.

Part of it is because fashionable titles shift over time; DevOps was the go-to term but now it feels like Platform Engineering is. This is probably because it better captures the product-focused, team-of-teams thinking that scales for devops/platform teams.

Each organisation decides on responsibilities differently depending on team size, product maturity, culture in the industry, and even the background of whoever’s hiring. So the title they’re given is essentially a best guess based on responsibilities required at the start of the role, which often morphs into different roles as projects progress.

A startup with five engineers often doesn’t have the headcount for specialisation. The person managing Terraform, building the deployment pipeline, and configuring the VPC is doing DevOps, platform, and infrastructure work all at once.

At larger companies, the separation becomes more meaningful. A Platform team with a product mindset and a roadmap looks very different from a DevOps Engineer embedded in a squad, even if both are deep into Kubernetes on any given Tuesday.

Read the job description

After reading many applications, the practical lesson is to read past the title and into the responsibilities. A “Platform Engineer” role at a thirty-person startup will look nothing like the same title at an enterprise company. A “DevOps Engineer” role at a bank might be closer to what a Platform team does at a tech company.

The questions worth asking in an interview: Are you embedded in a product team or sitting in a centralised infrastructure group? Are you building tooling for developers, or helping productionise a single product app? What does ownership look like when something breaks at 3am?

I like that DevOps Engineering is broad; I like having the option to do whatever is required to get the job done.

So, I’m refreshing my understanding and reflecting on it here.

Important terminology and tools

An important distiction is the difference between Authentication and Authorisation. Authentication asks “are you who you say you are”, while Authorisation says “I know you, but are you allowed to do what you’re trying to do”.

Infrastructure-as-code (IaC) is self-explanatory, it allows you to codify your infrastructure changes. Letting you track infra changes over time, and efficiently keep the infra actually deployed in line with your intentions. When there is drift between intentions and actual, IaC helps it realign.

Terraform is a great tool for IAC, and is the focus for this reflection.

There are many other tools that help with IaC including CloudFormation and Ansible. CloudFormation is AWS’s solution for the IaC giving declarative provisioning, but its locked to AWS. Ansible is more focused on configuration management and orchestration once infrastructure exists, though there is some overlap with IaC.

CI/CD is Continuous Integration / Continuous Delivery. It is a mindset with many tools that helps our code build, test, and deploy safely for our users. GitHub Actions our CI/CD tool of choice. There are others like TeamCity, Circle CI, Jenkins, Octopus Deploy, GitLab CI etc.

When mentioning MacBook it could be any developer machine enabling you to make infra changes by running Terraform.

Given all of this, there are two main use cases:

• Human to machine - Connecting MacBook to AWS
• Machine to machine - Connecting GitHub Actions to AWS

Both use cases need to authenticate and authorise, but they do it using different methods. We’ll explore that difference in the upcoming sections.

Human to machine

When running Terraform from your laptop, the industry standard is to authenticate with AWS SSO (rebranded as AWS IAM Identity Center in 2022, though the CLI commands remain the same).

From the terminal you run an aws cli command that opens your browser, asks you to log in using your identity provider (or aws creds), and grabs a short-lived credential for use during your AWS terminal session. It normally expires after 8 hours, but this is configurable. Terraform picks up that short-lived credential and uses it to configure the infrastructure however you’ve defined.

# day to day example (assumes sso roles are setup)
aws sso login --profile terraform
export AWS_PROFILE=terraform

terraform apply

These commands work because there’s a human in the loop. Developers can login to AWS, click a button, and complete an MFA prompt. It’s verifiable that you are the person at the keyboard.

This is not possible the moment you’re out of the loop.

Machine to machine

A GitHub Actions CI/CD pipeline can’t easily open a browser or tap an allow button on your phone. It needs to authenticate to AWS without a person in the loop, securely, and without any of the interactive trust mechanisms that make SSO work locally.

The old answer was to generate an AWS access key pair, paste it into GitHub as a secret, and let the pipeline use that to authenticate with AWS. This still works, but it’s a liability and no longer recommended. Long-lived access keys, if leaked, can grant authentication to whoever gets them. Unfortunately, because infra work requires a broader set of permissions, losing these keys is a bigger security risk.

Long-lived keys should also be rotated frequently (i.e. rotating means to update the keys). That requires additional reminder scheduling, and if the key is used in many places, the work to update might require a bit more effort.

The better answer is Open ID Connect (OIDC). To understand OIDC, you have to understand JWTs first.

JWTs

JWT stands for JSON Web Token. It’s a compact, self-contained token for passing claims between parties.

A claim is a key-value assertion about a subject, e.g. "sub": "user_123" or "email": "john@example.com". The issuer party (AWS or GitHub) is saying: I assert these properties are true about the subject of this token (and that it is valid for the stated audience and time window)

What might be at first surprising, is that a signed JWT isn’t encrypted and anyone can read it. Paste a JWT string into jwt.io and you’ll see everything inside (with real tokens, keep them out of public tools!).

The point of JWT tokens isn’t secrecy, it’s integrity. If you trust the issuer’s public key, and the signature checks out, then you can trust the claims.

Think of it like a driver’s licence, it’s contents are not a secret (anyone who physically holds it has the info), but it’s validity is trusted because it was created by a trusted authority. Other parties (police, security, the supermarket cashier) recognise it and trust what it claims.

A JWT is a string with three parts separated by dots. Header, payload, and signature.

<header>.<payload>.<signature>

The header says how it was signed. The payload is a set of claims or facts about whoever the token is describing. The signature is the issuer’s cryptographic stamp.

E.g.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjdXJpb3VzX3JlYWRlciIsIm5hbWUiOiJZb3UsIHRoZSBjdXJpb3VzIG9uZSIsIm1lc3NhZ2UiOiJUaGV5IHNheSBjdXJpb3NpdHkga2lsbGVkIHRoZSBjYXQsIGJ1dCBpdCB3b24ndCBraWxsIHlvdS4gU3RheSBjdXJpb3VzLiIsImlhdCI6MTc0NjY2MjQwMCwiZXhwIjo5OTk5OTk5OTk5fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

You can read more detail here: https://www.jwt.io/introduction#what-is-json-web-token

OIDC

OIDC (OpenID Connect) is how JWTs get used for authentication. An identity provider mints a signed JWT about who someone is or what it’s doing, and a relying party verifies the token and decides what to do.

Back to the analogy of a JWT and a drivers license. The issuing authority is whoever grants drivers licenses, in New Zealand this would be NZ Transport Agency (NZTA or Waka Kotahi). The relying party, again, could be police, security, or the supermarket cashier.

For your CI/CD, GitHub is the identity provider and AWS is the relying party. GitHub publishes its public keys at a well-known URL. AWS knows where to find them and when the workflow pipeline runs, GitHub mints a JWT describing that specific job (the repo, git branch, the workflow file) and signs it. The pipeline hands the token to AWS, AWS verifies the signature, reads the claims, and decides whether to issue short-lived credentials.

There’s no shared secret and no pre-arranged handshake. You declare in your AWS account that you trust GitHub’s issuer URL and from that moment, AWS knows how to verify any token GitHub signs.

This grants you authentication, and next it’s important to look at the policies that grant authorisation to make changes.

The trust policy

With the authentication and JWT verification mostly handled by AWS & GitHub, you can focus more on deciding which GitHub claims you’ll accept.

For example, every JWT GitHub mints contains a sub claim, i.e. the subject

repo:my-org/my-repo:ref:refs/heads/main

That string identifies exactly which repo, branch, or trigger produced the token. Your trust policy in AWS is a set of conditions on those claims. So if you pin the sub claim to a specific repo and your main branch (like the above example), then only that combination can assume the role.

Set up the AWS trust policy too loosely and you replace one risk with another. The biggest mistake is wildcarding the subject repo:*, which means that any repository on GitHub could potentially assume your role. The fix is to only give access to specific repositories that need it, following least privilege access. Most tutorials highlight this point too.

Using GitHub environments

Many tutorials suggest the use of GitHub Environments for production deploys. So you can pin the trust policy to repo:my-org/my-repo:environment:production. You then set up your repo to require manual approval on production deployments, thus adding another layer of protection. Now even a workflow on main can’t deploy until a human clicks a button.

For an enterprise team, this makes sense. Multiple people merging code, the reviewer and the deployer might not be the same person. So the approval gate gives you a real second pair of eyes.

For a solo project without actual customers it’s optional, but worth knowing the pattern exists for when the team grows.

Relearning

Coming back to OIDC after a year of travel, I noticed new details since the first time round. Especially in terms of trust policies, and why the sub claim specificity matters. Going back to first principles about JWTs and OIDC before touching any config gave that stronger mental model.

If you want to see how someone might configure all of this, check out my repositories here:

• AWS Foundation SSO & OIDC setup: https://github.com/wjkw1/aws-foundations
• Demo Application: https://github.com/wjkw1/devops-profile-coffee-card-app-demo

This book begins and ends with sadness. It has many ups and downs which helped me feel really invested in the students journey.

The author moves through the story really quick. It’s great to read because it feels like there is no dawdling on useless parts of text or superflous detail. It all moves the plot or develops a character. Such a good author.

It reminds me of Derek Sivers and his ethos about reducing and refining the texts he writes into their most condensed form. It makes his writing great to read too, because it shifts quickly and captures big ideas in a small amount of text.

I drew parallels with the plot of this book and the age of AI we are currently living through. Yes it’s written in a time near the industrial revolution but the silverworking automations are more like magic (which in some ways is what AI can feel like).

The book explores privileged/secret knowledge learnt by a select few scholars (in real life, this would be tech workers), and the benefits of these outputs given to that small class. With the age of AI, we are being sold a pipe dream where complex technical knowledge is no longer limited to a select few who studied it, and now anyone can pull up a chatbot to create something.

There are substantial job losses as a result of silver working by the scholars and researchers at Oxford. Loads of people losing work because of the efficiency gains that silver gives machines. It sounds similar to what’s happening now in the AI revolution.

The book forces us to acknowledge how our optimisations affect people without that knowledge, it’s something that the scholars (or tech workers) tend to ignore. Confronting the loss of jobs and sometimes even loss of lives due to new technology (self driving cars, unsafe automated machinery, and working conditions or environmental impact). It’s a bleak look at a different era where some of these same problems seem to be reoccurring.

There are huge colonialist undertones throughout the book and in the secret (or perhaps no longer secret) inner workings of the translation society in bringing the world under their leadership. They achieve this not through war, but through knowledge and intentional mistranslation of treaties. Tbh they might have been unintentional mistranslations, but at the time it was the best translation they could give with their scoped in points of view.

This idea is relevant to the Treaty of Waitangi and central to some of the arguments presented in NZ politics. They argue that Māori understood and signed the Māori document, assuming that same intent was on the English version. There are arguments that this was intentional mistranslation in favor of the crown.

Many characters in the story come from broken homes, grew up as slaves, or lost their families to sickness. The kids that showed intelligence were plucked by the translation society, and indoctrinated into an English upbringing to take advantage of their natural language heritage. We know how much our environment can shape our opinions. Imagine growing up as a child taken from your homeland and raised inside the empire of the English? Imagine how much that upbringing might shape your perspective of the world. Western ideas and Western thoughts.

On that, AI as built today, thinks in this same Western thought. The data is more heavily weighted towards what is on the internet, and so minority languages that arent as common in the public domain are weighted out. Not an easy problem to solve, and probably not one many people will want to solve because of the percieved “pay off”. It’ll take a strong and well-driven community to drive it, or a banding together of indigenous folks in similar predicaments. The latter is more realistic imo.

At the end of this book, I can’t help but feel sad. Their dependence on silver working was the downfall of the empire. There are lessons here warning us about over-dependence on AI.

Professor Lovell in the book uses the argument that the scholars’ hard work is justification enough for them to profit from it. He believes this information is out there for anyone to learn, they could’ve taken advantage of the system and learnt and succeeded like him. But what that argument misses is that the environment in which the professor grew up in is vastly different. The tutors, the private lessons, access to resources. Even something as simple as time to study.

It’s sad we don’t hear about whether the empire recovered from the tragedy of the tower collapse. But I assume this is intentional as it allows us the freedom to think about what might have happened.

Quotes

Chapter 2

‘But in latin, malum means “bad” and mālum,’ he wrote the words out for Robin, emphasizing the macron with force, ‘means “apple”’. Interesting comparison to the macron in Maori. The main example I remember has to do with shit I think.

Learnt about the word “erudite”, which means to have or show great knowledge.

He learned what the Corns Laws we’re and what they had to do with a Frenchman named Napoleon. He learned who the Catholics and Protestants were, and how the (he thought at least) small doctrinal differences between the two were apparently a matter of great and bloody importance.

New words in English were a game to him, for in understanding the word he always came to understand something about English history or culture itself. He delighted when common words were, unexpectedly, formed from other words he knew. Hussy was a compound word of house and wife. Holiday was a compound of holy and day. Bedlam came, implausibly, from Bethlehem. Goodbye was, incredibly, a shortened version of God be with you.

Chapter 3

So what does that tell you Birdie? If they’re going to tell stories about you, use it to your advantage. The English are never going to think I’m posh, but if I fit into their fantasy, then they’ll at least think I’m royalty.’ This was Remy assuming the identity of a royal and behaving in a way that took control of the narrative of how he was perceived. Within the realms of what the English though practicable.

Chapter 6

He felt loose, vulnerable. Too passionate for what should have been and intellectual discussion. ‘We take their languages, their ways of seeing and describing the world. We ought to give them something in return.’ ‘But language,’ said Professor Lovell, ‘is not like a commercial good, like tea or silks, to be bought and paid for. Language is an infinite resource. And if we learn it, if we use it - who are we stealing from?’

Chapter 9

‘Then the expense is entirely invented?’ Robin asked. This came about more sharply than he’d intended. But her was thinking, then, of the choleric plague that had swept through London; of how Mrs Piper explained the poor simply could not be helped, for silver-work was so terribly costly. ‘Oh, yes.’ Professor Playfair seemed to find this all very funny. ‘We hold the secrets, and we can set whatever terms we like. That’s the beauty of being cleverer than everyone else…’ This makes me think about IT or any other skill based or learned field. We charge a premium not for the difficulty of the task at hand. But for the years of experience spent learning to make the task fast. Some element of time efficiency and not having to burden ourselves with that knowledge too. Even if it might be easy to learn, shrouding it in difficulty makes paying for it easier. I want to try my best to learn throughout my whole life. Always tinker and try things out myself. We have the internet in our pockets.

Chapter 10

‘But China has no reciprocal appetite for British goods. When the Qianglong Emperor received a display of British manufactured items from Lord Macartney, do you know what his response was? Strange and costly objects do not interest me. The Chinese don’t need anything we’re selling; they can produce everything they want on their own. So silver keeps flowing to China, and there’s nothing the British can do about it because they can’t alter supply and demand. One day it won’t matter how much translation talent we have, because silver reserves will simply not exist to put it to use. The British Empire will crumble as a consequence of its own greed. Meanwhile, silver will accrue in new centres of power - places that have heretofore had their resources stolen and exploited…’ This conversation was between Robin and his older brother.

Chapter 12

The full impact of so-called silver industrial revolution, a term coined by Peter Gaskell just six years before, was just beginning to be felt across the country. Silver-powered machines of the kind William Blake dubbed ‘dark Satanic Mills’ were rapidly replacing artisinal labour, but rather than bringing prosperity to all, they had instead created an economic recession, had caused a widening gap between rich and poor that would soon become the stuff of novels by Disraeli and Dickens. Rural agriculture was in decline; men, woman, and children moved en masse to urban centres to work in factories, where they laboured unimaginably long hours and lost limbs and lives in frightful accidents. Our civilization has gone through this industrial revolution already. But it begs the question, what would happen if the knowledge work was replaced by agentic systems. Would people in the know have working knowledge to profit from it? Will people retreat from urban centres into the country sides, in an effort to claim back that which makes us human?

Chapter 32 Todo: add characters.

Insane was not enough to cover it, Robin thought. English was insufficient to describe all this. His mind wandered to old Chinese texts, the idioms they employed about dynastic collapse and change. (Add chars here); tiānfalāndìfù. The heavens fell, and the earth collapsed in on itself.

Chapter 33

How did one make peace with one’s own death? According to the accounts of Crito, the Phaedo, and the Apology, Socrates went to his death without distress, with such preternatural calm that he refused multiple entreaties to escape.

I copied this quote while on a plane leaving Athens. This was after walking past the prison of Socrates and the university building where he taught.

This moment has been circling in my mind across this last week.

How I got there

I went to Amsterdam for three nights to see the city and to take part in Bunq’s 24-hour hackathon. I arrived alone and Bunq connected me with a team. On the day two people didn’t show so we ended up finding two others in similar situations and formed a new team.

The hackathon brief was to build something that solved a problem, used the Bunq API, and had some kind of multi-modal AI. I didn’t know what we’d build, and honestly that was exciting to me!

Who I worked with

Our team was called “4 corners” with people from four countries. We had a DevOps Engineer, Business Analyst, Product Owner, and even a CFO. Honestly, it was a privilege to be around such accomplished people whose lives had taken different trajectories leading them to this moment.

The build

On the day we had a brilliant talk by someone from AWS about spec driven development. I took that talk to heart and tried building our app using that same ethos. This led me to a vibe-coded backend app in Python, the language I knew, but attempting to use production-grade infrastructure. For a 24-hour prototype, this was overkill. The AI, eager to please, happily built me something far beyond what the hackathon called for.

It reminds me of something an old colleague once told me:

building something is easy, productionising it is the hard bit

In this hackathon, unfortunately, I started off by inverting their advice. I was productionising something before I’d built anything.

The pivot

You can wrangle an app together in 24 hours. What matters more is whether you’ve thought clearly about the problem, can articulate the pain point, and can demonstrate something useful with honest tradeoffs.

• Mock APIs not crucial to the core solution instead of integrating with them.
• Stub the database or run one locally to show the core idea working.
• Later, if there’s time then connect the real infra.

The lesson for me was closing the gap between ambition and execution. A gentle reminder to focus more on the problem being solved, and on building an MVP that demonstrates a useful solution.

That’s what scrapping the bloated AI app got me back to. Something small, something easily understood, something we could actually show someone.

The winning teams that night? Mostly localhost applications.

Amsterdam

After the Hackathon winners were announced, I left Bunq HQ into a city I’d been told was lovely. My cousin recommended Amsterdam as the place to be, and I could see why. Flat landscape, bike-friendly, sunny skies that week (rare, apparently), with free ferries criss-crossing the harbour, and people moving through it all with quiet competence. It felt like a larger Wellington with better trains.

I came partly to see whether I could live in Amsterdam. I left knowing I could.

Naming convention decision

Final name: tfstate-{AccountId}-{GitHubRepo}

Example: tfstate-123456789012-aws-foundations

Why this name

The convention earns its structure because I’m committing to one terraform state bucket per project.

So, the three pieces of information communicated in the bucket name:

The convention scales cleanly: every future infrastructure repository gets tfstate-{AccountId}-{GitHubRepo}, with no naming decisions to revisit.

Options considered and why they were rejected

tfstate-aws-foundations

Not globally unique, and almost certainly already taken thanks to the known limitation of S3. It also encodes the github project name in a bucket originally conceived as potentially holding all account state. Once my intent changed, the name became misleading.

tfstate-{AccountId} (original)

Unique and future-proof, but loses the repo link. Fine if one bucket holds state for many projects; less good when the bucket is scoped 1:1 to a single repo, where the link has real navigational value.

{AccountId}-aws-foundations

Globally unique, still links to the repo. But without a tfstate indicator, anyone browsing S3 has no immediate signal about what the bucket is for. The AccountId prefix also groups infrastructure buckets together when sorted, at the cost of reading unnaturally left-to-right.

aws-foundations-{AccountId}

More readable than the account-first example, same repo link. Still missing the tfstate indicator.

tfstate-{AccountId}-aws-foundations (chosen)

Purpose is obvious. Guaranteed to be unique. The 1:1 GitHub mapping is perfect. The tradeoff: twelve digits in the middle makes the name long and not great to say out loud. That cost is low because this string gets typed approximately twice in the bucket’s lifetime – at creation and in versions.tf – so conversational readability is not important.

Convention going forward

tfstate-{AccountId}-{GitHubRepo}

Other projects I create that require aws infra will each get their own S3 state bucket following this pattern.

This gives me state isolation between projects; a terraform mistake in one project cannot affect another, and state files stay small and fast.

I think that’s only half the story.

Chasing threads is about following inspiration when it strikes.

During my induction week as a graduate engineer, over seven years ago, I was told a story about our CEO. It’s where I first felt encouraged to be curious at work.

The CEO had a planned visit to one of our front-line Telco stores. All staff were prepped with questions and had a stacked agenda for photos and content capture. When the boss arrived, he spotted a staff member off to the side, absorbed in something (repairing a device, restocking a shelf) I can’t quite remember.

He walked over and simply asked: “Hey what are you doing?”

Whoever this person was, they spoke about what they were doing with such genuine passion and joy that the CEO scrapped the rest of the agenda entirely. He spent the whole visit just talking with this one person about technology, about their goals, about what they loved about the job.

That conversation turned into a friendship. They kept in touch across the year. And eventually, that staff member grew into a role back at headquarters. All because the boss saw someone doing something that looked interesting, and went and spoke to them.

Do you know the feeling? You’re reading something and a word catches you, you look it up, and suddenly you’re twenty minutes deep into the history of something you never knew you cared about.

The conventional wisdom says to ignore that. To get back on task and stay on track.

But what if the thread is the track?

Here’s the reframe I often come back to: life is distractions. It’s the distractions the give life meaning. Not in the doom-scrolling-at-2am sense. In the sense that the interesting stuff, the stuff that actually shapes who you are, rarely arrives through the front door. It sneaks up on you. It’s the thing you weren’t supposed to be doing that ends up mattering most.

Steve Jobs is probably the most famous example of this. In his 2005 Stanford commencement speech, he talked about dropping in on a calligraphy class at Reed College out of pure curioisty, with no practical application in mind. A decade later, that class became the foundation for the beautiful typography of the first Macintosh.

He didn’t chase calligraphy because it was strategic. He chased it because it pulled at him. Same instinct as a CEO who walks past a stacked agenda to talk to someone doing something interesting. Same instinct as anyone who follows a word into a twenty-minute rabbit hole and comes out knowing something they didn’t expect to care about.

But I have to be honest with myself, because this idea has a dark twin. Something a colleague of mine introduced me to because I was chasing the latest technologies all the time.

There’s a concept called Shiny Object Syndrome. The idea that some people —especially curious, creative, entrepreneurial types— get so drawn to the next interesting thing that they never actually go deep on anything. They bounce from project to project, tool to tool, always chasing novelty, never building something real.

I’ve been there. Most curious people have. You pick up a thread and it leads you to another thread, and another, and before you know it you’ve spent a whole day falling down rabbit holes and nothing is finished.

The shiny ball of yarn is real. And if you’re not careful, chasing threads becomes a sophisticated-sounding excuse for avoiding the hard, slow, unglamorous work of actually finishing things.

The difference between a thread worth chasing and a shiny object isn’t obvious in the moment; but it becomes clear with a bit of distance. If you park an idea for a few days and it’s still pulling at you, it’s probably a thread worth chasing. If you forget about it, then it probably wasn’t worth following anyway.

So go chase your own threads. Not all of them and not recklessly. But when something tugs at you, don’t immediately dismiss it as a distraction.

Linting and formatting code

Recently, while working on a personal DevOps project, I spent some time looking into linting tools. They amazingly save your brainpower for the actual problem, instead of code styling. Whether it’s two spaces or four per indent, single quotes or double, I don’t mind. Other people have thought deeply about these trade-offs, landed on reasonable answers, and codified them. I’m happy to piggyback on that.

I aim to write code that works, and let the styling happen automatically.

There’s a side benefit too: when a codebase consistently uses a popular linting tool, anyone familiar with it can scan the code and immediately know where to look. It’s like how headings in a research paper let you scan before you commit to reading.

Three touchpoints that matter

Good linting hygiene should show up at meaningful points in your development lifecycle:

1. In your IDE (or text editor), as you write
2. Locally, before you commit
3. In CI/CD, before code merges

Each layer serves a different purpose. Together, they make code quality essentially automatic. (Tools like SonarQube go deeper —security, coverage, and code smells at a project level— but that’s a reflection for another time.)

In the IDE (or text editor), I use VS Code with the relevant extensions installed and Format on Save enabled. It does what it sounds like: when the file saves, the formatter runs. Sometimes this needs dev dependencies installed to work properly; check the official docs and you’ll figure it out quickly, I’ll go into Ruff for Python specifically later in this post.

Locally, before committing, is where things get interesting. At various companies I’ve seen the same pattern repeat: developer forgets to format, pushes code, CI fails, they fix locally, force-push, CI reruns. This adds ten minutes to the dev cycle, minimum. Multiply that across a team and it adds up quickly.

Git’s pre-commit hooks solve this cleanly. When you attempt a commit, a hook runs your formatting and linting checks first. If they fail, the commit doesn’t go through. This means no broken CI and no annoying formatting fix commits. This enables the code to validate itself before it ever leaves your machine.

The one catch: developers can skip the setup step entirely, which is exactly why the third layer exists.

In CI/CD, the pipeline enforces what the pre-commit hook encourages. Even if someone bypasses local hooks, nothing merges unless the linting passes. This is your actual quality gate and is what you rely on.

Why Ruff instead of Black and Flake8

Three or more years ago, I used Black for formatting and Flake8 for static analysis. Two tools, two configs, two things to install and maintain. It was a minor friction, but that friction compounded and was a little naff.

Ruff replaces both with a single tool. It’s faster, simpler, and opinionated enough that you don’t have to make many decisions. For a project where the point is less thinking about styling and formatting, that’s exactly what I wanted.

The Setup (Python / FastAPI)

Three things to configure, in roughly this order:

Step 1: VS Code + Ruff extension

Install the Ruff extension from the VS Code marketplace — the official one is published by Astral (charliermarsh.ruff). Once installed, add this to your .vscode/settings.json:

{
  "[python]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  }
}

Committing .vscode/settings.json to the repo is intentional. Anyone who clones the project and opens it in VS Code gets the same formatting behaviour automatically. No extra knowledge required.

No separate Ruff installation is needed as the VS Code extension ships its own binary, and the pre-commit hook (added in Step 2) bundles its own too. You just need to add your Ruff config to ruff.toml:

[tool.ruff]
line-length = 88
target-version = "py312"

[tool.ruff.lint]
select = ["E", "F", "I"]

The select block opts into pycodestyle errors (E), Pyflakes (F), and isort import sorting (I). This covers what you’d previously have needed Black, Flake8, and isort to do separately.

Step 2: Pre-commit hooks

First, install the pre-commit package:

pip install pre-commit

Then create a .pre-commit-config.yaml in the root of your repo. Here’s exactly what’s in the project:

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.11.4
    hooks:
      - id: ruff
        args: [--fix]
        files: ^api/
      - id: ruff-format
        files: ^api/

A few things worth noting here. The files: ^api/ pattern scopes the hooks to the API directory only — the frontend has its own linting story (ESLint + Prettier), so there’s no point running Ruff across the whole repo. The ruff hook handles lint checks and the --fix flag means it’ll auto-fix what it can rather than just reporting issues. The ruff-format hook handles formatting, equivalent to what Black would have done. Once the file is in place, install the hooks:

pre-commit install

This wires the hooks into your local .git/hooks/pre-commit. From this point, every time you run git commit, Ruff runs first. If it finds issues it can’t auto-fix, the commit is blocked and the problems are printed to the terminal. Fix them, stage the changes, and commit again. You can also run it manually across all files at any point:

pre-commit run --all-files

Useful for a first run after setting up, or after pulling in changes from someone else who hasn’t had the hooks installed.

That’s it. Once it’s done, your automatic project linting works in the background. Which is perfect.

We respect these boundaries through how we care for others and by letting them have their own emotional experiences

Too often we feel the emotional burden, or perceived microexpression that means a person is angry or sad. Then you immediate feel an urge to rush in and fix it.

That isn’t respect. They didnt ask for help. They’re processing something you can’t see. You must let them have that experience and not feel guilty about not forcing your hand to help.

This book comes with a lot of hard-hitting boundary related questions that are worth diving into. Some are pretty confronting tbh. Firstly it’s important to understand the categories, even at a surface level.

The categories Fath G. Harper uses for the various boundaries we have:

• Time boundaries - limits around how you spend your time, who has access to it, and protecting it from overcommitment or others’ demands
• Spiritual boundaries (belief system) - the right to hold your own beliefs, values, and practices without pressure to adopt or justify them to others
• Intellectual boundaries - protecting your thoughts, opinions, and ideas from ridicule, dismissal, or coercion to think differently
• Emotional/relational boundaries - defining what emotional labor you will and won’t take on, and how others are allowed to treat you in relationships
• Sexual boundaries - determining what sexual contact, conversation, or attention you consent to, with whom, and under what circumstances
• Property boundaries - your right to control who uses your belongings, space, and possessions
• Physical boundaries - limits around your body, personal space, and physical touch

Questions for consideration:

1. what are some of the boundaries you have for each of these categories?
2. which kinds of boundary violations do you experience the most? Which categories do those violation s belong to?
3. which kinds of boundaries do you have the most difficulty respecting for others? Which categories do those violations belong to?

Four main biggest reasons boundaries get walked over:

1. Overall social hierarchy problems
2. Screwed up attachment styles
3. High conflict personality
4. Perpetuation of coercive control

Originally it was difficult to understand what the words in this sentence meant: “perpetuation of coercive control”. Breaking down what each part of the sentence means makes more sense. It feels like a persistent, slow burn where a person is using force to control someone. Hectic.

The book explains an ideal cultural norm where “yes means yes” and not having the opposite where we are forced to look “no means no”. She describes the the flip of what we currently have. This is good.

The books says tha all large political movements started with a boundary being crossed and someone standing up for their right to protect said boundary. So, in essence, boundaries are eventually political by nature. They’re definitely shaped by politics and what is acceptable by both our culture and our laws.

Schools aren’t always equipped to set kids up for healthy communication and boundaries, though they try. Sometimes it feels like they’re set up for compliance and adhering to the status quo. I remember a time as a young kid where answering questions was fun, and more people put up their hands. Eventually less and less hands were keen to go up. It felt like you were shamed for answering questions wrong, and so the social rejection / embarrassment trained you to ask less questions. Since then, I consistently try to ask one useful question in meetings/events that I’m a part of. Something that’s taken time to unlearn. Heck, I still get nervous at the thought of putting my hand up to ask a question.

Three attachment styles in a nutshell:

• Secure attachment - general comfortability with others. 60% of people in the US.
• Avoidance attachment - hard time trusting or depending on others, uncomfortable with the level of closeness people expect of them
• Anxious attachment - hard time with worry, fear of abandonment

It feels like that depending on the context of whatever situation you’re in, and people you’re with, you slide in and out of each attachment style. Say for example, with your best friend you feel secure around. But a mean teacher you feel avoidance toward.

The book reinforces the impact childhood has on attachment styles in adulthood. And until we learn skills to react differently to the world around us, we won’t really be able to move past our attachment styles.

I knew these words, but I didn’t realise the succinct meaning behind them:

1. Narcissistic - excessive self-interest in self and appearance
2. Histrionic - excessively theatrical or dramatic in character or style

The minute we start paying attention to our own bullshit is the minute it starts to change. On noticing your own state and not externalising your problems on the world.

Best way to respond to High Confilct Individuals, is to first ask if you even need to respond? What are the consequences of not responding, what about if you respond?

The final bits of the book for me remind me that effective communication is possible. It shows a fair few examples and says everyone has a responsibility to help make the world a better place. Decent read. I think if I was more strict on the questions and spending time on them I might have got more out of this book. The questions are worth picking up and going through at various stages of your life.

This book leans on Charlie Munger’s philosophy. Early on he shares a Munger quote:

I believe in the discipline of mastering the best of what other people have figured out When mental models are not applied then you probably have failed understanding of a given situation.

One example is the context of an elephant and a blind person who has never experienced an elephant. They might mistake an elephant ear to be a fan, the trunk tusks might be mistaken as a spear, or the trunk as a snake.

The main chunk of the book explains general thinking concepts that are akin to common sense. For example:

1. Map is not the territory
2. First order principles (using 5 whys or scratch method)
3. Thought experiments
4. Circle of competence
5. Inversion - begin with the end in mind. Work both ways.
6. Falsifiability
7. Second order thinking. Literally just thinking about the consequences of consequence. Reminded me of playing chess or even 8-ball pool.

Probabilistic thinking is a mental model I naturally lean towards. I avoid thinking in black & white or definite yes/no thinking. Instead, things tend to be more of a grey area, belonging to a spectrum of possibilities. In reality, probabilities should update based the most up to date information too.

I enjoyed learning about Occams razor; the simplest explanation, if most probable, is the most likely. Hanlons razor was equally facinating; it’s not malice, it’s probably stupidity or ignorance.

There are a few supporting ideas, one that stuck out is necessity and sufficiency. Where sometimes something might be necessary, or sufficient, and any combination of either or.

I learnt about blood-letting in this book, and how it was the suggested medical practice for over 2000 years. The idea that if you get sick you can bleed it out of you. But losing blood actually makes you weaker and might end up making your more sick.

I was reminded of Causation vs. Correlation in this book. The classic example of shark attacks increasing in correlation with ice cream sales. Though buying an ice cream doesn’t cause a shark attack. I think it was more likely summer time, which means it’s both hot enough for ice cream but also means more people are swimming.

Think through whether an idea is required or not before jumping to conclusions. Sometimes we have a bias toward ideas that support the conclusion we want, over the conclusion that actually is.

Quotes

The skill for finding the right solutions for the right problems is one form of wisdom

Our failures to update from interacting with reality spring primarily from three things: not having the right perspective or vantage point, ego-induced denial, and distance from the consequences of our decisions.

Admitting that we’re wrong is tough. It’s easier to fool ourselves that we’re right at a high level than at the micro level, because at the micro level we see and feel the immediate consequences.

There is an old adage that encapsulates this: “To the man with only a hammer, everything starts looking like a nail.”

In order to use a map or model as accurately as possible, we should take three important considerations into account: Reality is the ultimate update. Consider the cartographer. Maps can influence territories.

What is the C4 Model?

The C4 Model is a structured, uniform approach to describe the architecture of a software system at different level of detail. Instead of throwing everything onto a single diagram and hoping people get it, it organises abstractions in a way that mirrors how developers or software architects tend to think about systems.

The 4 levels are:

1. System Context - the big picture: your system and how it interacts with users and other systems.
2. Containers - the applications and data stores that make up your system.
3. Components - the building blocks of each of our containers.
4. Code - the classes, interfaces, and functions that implement each component. The official definition explains it best:

   A software system is made up of one or more containers (applications and data stores), each of which contains one or more components, which in turn are implemented by one or more code elements (classes, interfaces, objects, functions, etc). And people (actors, roles, personas, named individuals, etc) use the software systems that we build. Source: https://arc.net/l/quote/kvovhsbn Visit the official website to read more detail about this framework.

The map is not the territory

A book called The Great Mental Models: General Thinking Concepts has a chapter called “the map is not the territory”. The idea being that the granularity of Google Maps, does not show the same level of detail as someone walking around on the ground. This is a similar line of reasoning useful when thinking about the C4 diagram. For most intents and purposes, the maps context is enough to be useful at a high-level. But sometimes, we need more detail to understand what is going on under the hood. That’s why we have these layers of abstraction, and at each abstraction we are targeting a different audience.

The caveat at the code level

The creator of this framework, Simon Brown, recommends never manually building the lowest level C4 class diagram. It’s not worth the effort of building, and definitely not worth keeping updated; especially with the pace at which software changes nowadays. The level of detail is normally so closely related to code that it can (and should) be generated automatically. This is a pragmatic acknowledgement that diagrams are tools, not artefacts to be maintained for their own sake. If a diagram can’t keep pace with reality, it quickly becomes a source of confusion rather than clarity.

Examples from a personal project

I’ve been applying this framework in a recent pet project. If you’d like to see the diagrams in action, head over to the demo project here: devops-profile-coffee-card-app-demo.

Context

Containers

Components TBD

Coming soon…

“a website containing a writer’s or group of writers’ own experiences, observations, opinions, etc., and often having images and links to other websites.”

A reflection has many meanings, but the two I latch onto are:

• a fixing of the thoughts on something; careful consideration.
• a thought occurring in consideration or meditation.

The word reflections carries a quieter, more inward energy for me. It implies that you’re writing for the process of thinking, not for an audience or an outcome. I love that there is no implicit pressure to grow a following, monetise, or be consistent on a schedule.

My perception of blogs is that they come loaded with baggage nowadays. It asks for SEO optimisation, calls to action, newsletter signups, and the hustle of content creation. That’s a very different thing from sitting down and genuinely processing your thoughts on paper.

This is why I choose to use reflections, to give me freedom of thought while writing thoughts on a page.

This book was amazing read for me. I barely read anything fictional thats not got some element of fantasy or super powers. But I couldn’t stop myself from turning pages. Thoroughly enjoyed it and I’ll be reading her other works.

This book was gripping, the pacing of each sentence was masterful. It feels like it was written in its most condensed form without losing any meaning from the text. It jumped from plot to plot, and I like that it didn’t waffle on about unessesary bits.

The book was broken into many main themes as the story progressed. Basically, it shows a lonely character Juniper Song (Hayward) go through the envy, then stardom, then the fall because of her silly decisions.

She wants to be a great writer, but isn’t ever that good at creating her own ideas. She keeps trying to draw parallels between her own messed up situations and what Athena, the successful author of the book (in the novel), and herself. I wonder if she might have done better as an editor of other peoples works (though envy and her mean inner voice probably wouldn’t have helped her case).

There are significant moments in the book that make your insides curl. Basically, June was racist and couldn’t understand why. We see her struggling to understand what its like to be a person of colour, and how she continues to miss the mark, and unfortunately believes in her mind that she’s in the right. There is one scene where she chats to her mentee, a young aspiring Asian author and says something along the lines of: “don’t worry, you’ll be fine. You could write anything, you’re diverse and publishers eat that up!”.

R.F.Kuang showed June as a bad writer by showing us the bad decisions she made while writing, especially the parts June decided to cut out.

I enjoyed seeing the difference between having a star publishing team vs an independant agent who doesn’t have the resources to support a writer. I wonder how much of this is true in the real world? Marketing is such a skill, and if you aren’t able to get your book, product, or tech in front of people then I doubt they’ll use it.

June’s whole life changed when she got a great publishing team. They were able to publicise her book and get out to the best sellers list. They had connections, and methods, and a team of publicists to help her. Though June’s success is probably due to the foundations of the story she stole.

Juniper struggles with her social media addiction, and her incessant need to be popular, also maybe her ego. These all warp any effective decision making she would ever be able to make, she fixes the momentary problems as they come up but doesn’t think about long-term consequences.

By the end of the book she is caught out on her lies, and even at the end, it finishes by June coming up with a delusional plan to flip the narrative on its head and go against the person who has video taped proof of her admitting her guilt.

meta – Posts about this site itself – announcements, changes, meta type entries. Use when: the post is about the website or process specifically, not a topic within it.

ai – Artificial intelligence, large language models, and how I’m using them in work or writing. Use when: the post is primarily about AI tools, AI tech, or AI behaviour

career – Work, professional growth, team dynamics, and lessons from the industry. Use when: the post reflects on the people side of software – roles, culture, collaboration.

communication – Explaining ideas about communicating, for example to non-technical audiences, across teams, or in documentation. Use when: the post is about how we convey information to other people.

definitions – Posts that define how I use a specific term, phrase, or concept – personal vocab entries. Use when: the post is structured around explaining what something means to me.

devops – Platform engineering, infrastructure, CI/CD, and the operational side of software. Use when: the post is about systems, pipelines, or keeping things running.

devtools – Tools that shape how I work - editors, CLIs, SSH, local setup. Use when: the post is hands-on with a specific tool or workflow.

writing – Reflections on the writing process, publishing, and finding my voice. Use when: the post is about writing itself, not just a post that happens to be well-written.

1. Start that “thing” today—not tomorrow, and not next week.
2. Getting started doesn’t require structure, an official tutorial, or any special gear.

‍Setting the scene

I’ve got no idea what I’m doing. I don’t know what software to use, but I do know that I don’t want to pay for anything—at least not until I’m sure making music is something I actually want to pursue.

First things first, I set out to find the “best” software to experiment with, without breaking the bank. For me, “best” meant: no cost, offline mode, a UI that isn’t ugly or archaic, easy-ish to experiment with, and something with learnings that transfer to a more advanced product later on.

In the past I tried Spotify’s web UI music creation tool, but it was only online so could only be used while I had internet, the lag wasn’t fun and it cost money quite quickly after the trial.

I like Fred again’s music, so I wondered what software he uses - apparently he’s a Logic Pro pro. Perplexity reckons Logic Pro is basically an overpowered and extended version of GarageBand. GarageBand comes for free with Macbook’s OS…so I went with GarageBand.

‍Getting started

At this point, I would normally pause there and think “job done”, lets continue tomorrow. I have two reasons why I didn’t want to pause:

1. Recent content I’ve been consuming has encouraged more personal agency. Books like 4-hour workweek or Modern Wisdom’s podcast interview with Naval Ravikant.
2. I read numerous articles of people starting with the only the simplest tools, making music only off their phone

So, using Atomic Habits tricks, I told myself to make music for 5 minutes. Without needing to even downloaded the software, I spend over an hour, hopping around the interface, trying to make a simple beat with the software MIDI controller.

No theory, no structured learning, no tutorials, just dive in and try it out. This worked well for me, and here is the first beat I made:

https://soundcloud.com/westernwilson/music-day-1

Before this, I didn’t know what a MIDI controller was or what a DAW was. (MIDI stands for Musical Instrument Digital Interface and DAW is what GarageBand is, and it stands for Digital Audio Workstation). Now I kinda do???

Honestly, taking a course or chatting with someone more experienced might be a good idea soon. I’ve thought about reaching out to Dera Meelan—someone I’ve enjoyed since hearing his track “Fire Sale” with Church & AP.

A few days past and here was my second beat:

https://soundcloud.com/westernwilson/music-day-2 ‍ If you have any pointers, reach out on any socials or at kiaora@westernwilson.com 🙏

‍Final note

There are many successful podcasters whose early podcasts sounded like they were recorded in a bedroom closet, sounding unpolished with bad scripts/questions. But no shade, I think that’s how it should be, that’s how you should start.

Point is, you can start today, and you can bootstrap it with minimal investment. Don’t spend on the best equipment if you’re not even remotely sure you’ll want to stick with it in a year; heck, you might quit after a couple of weeks.

Persevere with whatever you’ve got going on. Good luck, and stay curious!