We spent a year optimising the wrong bottleneck.

The harness discourse has been relentless - blueprints, schematics, thought leadership. Impressive engineering, most of it. But read the designs closely and you notice what they're all quietly aiming at: getting the developer out of the pipeline.

The logic seemed sound. Building dropped from days to minutes, and the human became the slow part. The bottleneck. So we designed the human out.

Then the telemetry arrived.

Faros AI instrumented 22,000 developers across 4,000+ teams. Moving from low to high AI adoption: task completion per developer up 34%, epics up 66%. Real gains. Also: bugs per developer up 54%, incidents per pull request up 243%, median review time up 5x, and 31% more PRs merging with no review at all.

Nobody decided to stop reviewing. Reviewers simply couldn't keep pace, and unread merges became normal. We knew this failure before AI. The 2,000-line PR lands in your inbox, and what follows is frustration, cognitive overload, and a silent rubber stamp. The difference is that it used to be the exception. Now it's the throughput model.

The bottleneck didn't disappear. It moved to review and integration - and we'd already removed the person who was supposed to be standing there when it arrived.

Two things worth saying plainly.

First: the human was never the bottleneck. The human is the missing oracle.

We have fast, cheap oracles for correctness. Do the tests pass? Does it lint? Machine-verifiable in seconds. We have no oracle at all for maintainability, intent, or design - and no benchmark I'm aware of currently measures them. GitClear's analysis of 623 million code changes shows what fills that gap: duplication up 81%, refactoring down 70%, error-masking constructs up 47%. Code that looks right and is structurally wrong.

Designing the human out doesn't remove a cost. It removes the only sensor we have for the slowest and most expensive failure mode. "Humans first" isn't sentiment or ethics-washing. It's a claim about where verification capability actually resides right now.

Second: we're borrowing against comprehension and calling it velocity.

Anthropic ran a controlled trial in January. Two groups, same unfamiliar library. The AI-assisted group finished marginally faster and scored 50% on comprehension. The manual group scored 67%. Seventeen points, on code they had written minutes earlier (this is a vendor publishing a result against it's own commercial interest).

That debt doesn't show up in your DORA metrics. It shows up at 2am when nobody on the call can reason about the system they shipped.

The industry response is to build faster agents. So I built the opposite experiment. A harness that puts the human at the centre - not to slow things down, but to make judgment cheap, timely and measurable rather than optional. You can check out the harness here.

Plain bash. Deliberately crude. Built to learn, not to scale.

The rules:

1. Agents don't move artefacts through the SDLC. They hit mechanical gates.
2. Humans state intent, write the spec, define acceptance criteria, and read the diff.
3. Route every check to the cheapest reliable verifier - mechanical gates for what's machine-checkable, calibrated LLM judges only after validation against human labels with explicit thresholds, humans for intent and design.
4. Diff budget: 200 lines. (Which became 400, excluding tests). If it's more than 400 lines, the feature was scoped wrong. The gate fails and the work gets split.
5. Only iterate on the harness with confirmed evidence and root cause.

Thirty minutes on an approved spec and a design sketch turns a six-hour adversarial review into a twenty-minute confirmation. The human isn't reviewing more. They're reviewing earlier, where a one-line correction prevents two thousand lines of rework.

237 minutes. 12 features. One engineer, no control group - an experiment, not evidence. I'm publishing the method so it can be argued with.

DORA's finding is that AI is an amplifier: it magnifies whatever your organisation already is. If your answer to a 243% rise in incidents per PR is to remove the last human who might have caught them, the amplifier is working exactly as designed.

What are you actually measuring?

Harness Engineering

A harness is defined as a piece of equipment with straps and belts, used to control or hold in place a person, animal or object. Some examples are a safety harness if you are doing bungee. Or a baby's harness. Historically, a harness was very much associated with draft animals such as horses, oxen, mules and cattle. An ox pulling a plow is typically yoked with a harness. The intent was to harness something effectively. That is: to direct, control, and use its power effectively for a purpose.

A harness in AI, is everything you put around an AI agent to shape how it works and to check what it produces. The discipline is broken into 3 parts. Guides steer the work forward. These are (a) rules and context files, (b) specs and prompts (c) skills and examples and (d) tools the agent may leverage. The second part is Boundaries - constraints for effective execution. These include sandboxes for isolation, permissions and token budgets. This ensures that the agent is constrained to run safely, but also run in a loop within some predefined resource limitations. The final part is Sensors. These verify the result. This is done with compilers, linters, tests, security scans and increasingly AI reviewers.

Harness engineering is the craft of combining these deliberately. Early evidence suggests it reduces token consumption, makes output markedly more consistent, and that specific named instructions dramatically outperform general guidance. But there's a catch: the most effective harnesses appear to be those co-developed with their backing models. Harness and model trained and tested together. That's part of why Claude Code punches above its weight, and it raises an uncomfortable question for us around our own.

Software Factory

A factory is a set of buildings where large amounts of goods are made using machines. A software factory is the same idea, where a set of systems are integrated to build, verify and release software repeatedly and at scale, with AI agents as machinery.

The software factory is the harness taken to its logical extreme: remove the humans. A backlog of work items feeds an orchestrator. An orchestrator dispatches an agent swarm to do the various parts of the work. Automated checks gate the output - AI reviews the AI's work and merges it. Deployment is continuous. And telemetry or feedback generates the next tickets. The loop runs and closes without a person standing anywhere on the line of production. Its promise is throughput. Code generation around the clock at near-zero marginal human cost.

Harness engineering will mature into a discipline - from individual craft to team practice and then platform capability, with shared harness components governed centrally and judgement federated back to the teams on the ground. Two problems will define these steps forward, sensor integrity. That is, how accurate, useful and reliable are the sensors we build. The second is, calibration - AI judges are proliferating faster than anyone is measuring them, and the harnesses that endure will be the ones that score their automated reviewers (AI) against human decisions over time and improve through it.

Software factories will find their niche and their ceiling. Factories are genuinely viable when correctness is cheap to verify, and errors are cheap to reverse - transactional back-ends, legacy rewrites governed by strong conformance test suites and internal tooling. The ceiling is structural. Today's models are trained against fast signals - does it compile, do tests pass, and are lint checks clean. However, what they do not cater for is design, maintainability, fidelity to intent and these things will surface over the months for which no automation checks. A factory has no station for slow signals, so it doesn't fail loudly. It instead accrues debt silently behind green checkmarks.

Conclusion The two concepts are not rivals so much as two settings of one dial: how much do we let an agent decide, and how we stay confident in what it does? The answer depends on the situation. If you can check the result cheaply and trust the check, the agent can be given more freedom. If checking is hard or mistakes are expensive, keep the leash short. We need to place human judgement where it matters most - saying what correct means at the start, and making the final call at the end. But we must also regularly test whether the automated judges in between can still be trusted.

Through working extensively with AI, I've observed common patterns that hold developers back from realizing its full potential. By understanding these traps, we can better align our expectations and achieve more meaningful outcomes.

🎯 Pitfall #1: Poor problem framing.

Problem definition matters. Keywords play such a huge impact it can change the nature of the implementation with or without AI. For example, if I drew a circle, and I stated, what is this familiar object? You would immediately state it's a circle. But if I had instead asked, what is this object? Perhaps you would find it odd why I would be asking some a basic question, one I already know the answer to. Doubt would creep, perhaps some red flags, resulting in you perhaps asking more questions. Consider a third approach, what if I asked you instead, what is this unfamiliar object? This would certainly make you step back and think. How I framed the problem, impacted how you derived your outcome.

How to identify:

• Not thinking through what you are asking, but just asking
• Asking for complete solutions without breaking down complex problems
• Jumping straight to implementation without discussing architecture
• Being vague about edge cases

🏗️ Pitfall #2: Over-reliance on AI

Picture a chef asking a kitchen assistant to "just fix dinner service." Even with access to every ingredient and recipe, the assistant can't replace the chef's experience, judgment, and understanding of their kitchen's unique challenges. Similarly, feeding an AI your entire codebase won't magically solve architectural problems or replace developer intuition.

How to identify:

• Expecting AI to understand under-stated requirements
• Not reviewing generated code for best practices or logic flaws*
• Blindly implementing without understanding
• Using AI for critical security or data handling without review

🤖 Pitfall #3: Providing insufficient context

This is the equivalent of asking a construction company to quote you on building a 3 bedroom house, but forgetting to highlight that the location is on a hill, in a remote location with poor to little infrastructure. You just not going to get the right result.

How to identify:

• Not sharing relevant dependencies or environment details

• Omitting important business rules or constraints
• Not explaining how the code fits into the larger system
• Failing to specify performance requirements or scale

🔄 Pitfall #4: Ineffective iteration

Fred is building his dream bathroom with a view of the mountains. Initially, he tells the builder "Move the toilet to the left and bath to the right" to capture that perfect vista. The builder does exactly that, rearranging the plumbing at considerable effort. The next day, Fred has another thought: "Actually, what if we just kept everything where it was and moved the window instead?" The builder, trying to accommodate, moves the window. But Fred had forgotten a crucial detail from his first design - the original window position had needed special tinted glass to manage the intense morning sun. When Fred visits the site, he finds a beautiful mountain view...and a bathroom that turns into a greenhouse every sunrise.

How to identify:

• Not providing feedback on what worked/didn't work
• Starting over instead of building on previous responses
• Not clarifying misunderstandings in the AI's assumptions
• Failing to narrow down issues when debugging

Suggestions:

Improve your prompt engineering

One aspect of this is prompt engineering, and the second around structured communication. There is a plenitude of improvement and thinking around this on the internet, and a great resource in the Prompt Engineering Guide.

See AI as a collaborative junior developer

The real power comes from treating AI as a collaborative junior developer - one who can suggest approaches, spot patterns, and help with implementation details, but needs your guidance and domain expertise to create truly effective solutions. Like any good mentoring relationship, success comes from clear communication, thoughtful questions, and combining both parties' strengths.

Improve Problem Definition

Here's a simple template for an improved problem definition:

Here's what I'm trying to achieve: [clear goal]
Current environment: [versions, dependencies]
Constraints: [performance, security, etc.]
What I've tried: [previous attempts]
Specific questions: [what you need help with]

For more complex problems:

// Context
System: [architecture, tech stack, scale]
Dependencies: [versions, integrations]
Constraints: [performance, security, compliance]

// Current State
Existing code: [relevant snippets]
Current behavior: [what's happening]
Error messages: [if applicable]

// Desired Outcome
Expected behavior
Success criteria
Non-functional requirements

// Attempted Solutions
Approaches tried
Results observed
Specific blockers

// Specific Questions
Targeted questions about implementation
Areas needing clarification
Potential concerns

Include diagrams or flow-charts as well.

Improving Iterative Development

Initial code: [code snippet]
Issues found: [specific problems]
Required changes: [clear modifications needed]
New requirements: [additional features]

Improving development experience

Keep AI and context awareness separate from your IDE. While mastering these fundamentals, limit in-IDE AI to Copilot for routine code completion. Use standalone AI tools like Claude (Project Mode) or ChatGPT externally. This separation offers three key advantages:

1. Control over AI model quality
2. Better context management
3. Easier recovery from context-related mistakes

Up in the sky, the tempests rage,
as the heaven's proclaim the coming age,
where Jesus the Lamb, breaks vials of his own,
as he pours out their tears all over his throne.
His fury and wrath ascends to the highest,
and shall descend to the deepest, where the darkest liest.

Down on the earth, in the land of men,
The people dance and sing in their wicked den,
Praising self, rejecting Him, denouncing the Cross
Living their best life at great cost.
They live to enjoy each new day,
And steep themselves in comforts of rich array.

High up in heaven, the Lord mounts His horse,
and prepares to descend and evil divorce,
His Word like a sword proceeds from His mouth,
As He commands his armies to gather out.
Down to the earth they go,
The righteous will avail with mighty bow.

In Sodom and Gomorrah, they see the signs,
The earth is groaning but they remain benign.
Flashes scatter across they sky,
As the Lord breaks open every wretched lie.
The fire and fury of His descendance unknown,
As He comes to grant vengence to His very own.

Be-warned, be wary, murmur not and complain,
For Jesus is coming, coming again,
To rule and to reign,
To scatter the rain,
To dry up our tears,
And wrestle all fears,
Jesus, Jesus the King,
Is coming again.

Didn't complete

1. Never Split the Difference - Chris Voss
2. Refactoring - Martin Fowler
3. The No Asshole Rule - Robert Sutton
4. Cloud Strategy - Gregor Hohpe
5. AI Engineering - Chip Huyen

Read

1. The Philosopher's Stone - JK Rowling
2. The Sword in the Stone - T.H. White
3. Angular Design Patterns and Best Practices - Alvaro Camillo Neto
4. New Age Bible Version - Gail Riplinger
5. Faith: More than you think - Mike Pearl
6. Mistborn - Brandon Sanderson
7. The Well of Ascension - Brandon Sanderson
8. Exploring the Minor Prophets - John Phillips
9. The AI-Driven Leader - Geoff Wood
10. Elantris - Brandon Sanderson
11. New Age Bible Versions - Gail Riplinger

Planned

1. Robert Nystrom - Crafting Intepreters
2. Tom Stuart - Understanding Computation
3. Gerald Weinberg - Quality Software Management, Vol 1: Systems Thinking
4. Donella Meadows - Thinking in Systems
5. Brendan Burns - Designing Distributed Systems
6. Clarence Larking - Dispensational Truth
7. Betsy Beyer - Site Reliability Engineering
8. Steven Pinker - Rationality: What It Is, Why It Seems Scarce, Why It Matter
9. Lies My Gov't Told Me: And the Better Future Coming
10. Traced: Human DNA's Big Surprise
11. Jez-Humble, Gene Kim - Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
12. Brendan Gregg - Systems Performance
13. Site Reliability Engineering
14. Building secure & reliable systems
15. Neal Ford, Rebecca Parsons - Building Evolutionary Architectures
16. The Hard Thing About Hard Things - Ben Horowitz
17. Introduction to General Systems Thinking - Gerald Weinberg
18. Return of the God Hypothesis - Dr. Stephen Meyer
19. Building LLMS from scratch

Read

1. Never Split the Difference - Chris Voss
2. AI Engineering - Chip Huyen
3. Kettlebell: Simple and Sinister - Pavel Tsatsouline
4. The Hero of Ages = Brandon Sanderson
5. Endurance: SAS Soldier - Louis Rudd
6. Cloud Strategy - Gregor Hohpe
7. Bravo Two Zero - Andy McNab

Currently Reading

1. Refactoring - Martin Fowler
2. The No Asshole Rule - Robert Sutton
3. Platform Strategy - Gregor Hohpe
4. Fundamentals of Data Engineering - Joe Reis & Matt Housley
5. Designing Machine Learning Systems - Chip Huyen
6. Exploring Gospel of John - John Phillips
7. Building an LLM from Scratch - Sebastian Raschka
8. The Intentional Father - Jon Tyson
9. Dispensational Truth - Clarence Larkin
10. Why Machines Learn - Anil Anantaswamy

Planned

1. Robert Nystrom - Crafting Intepreters
2. Tom Stuart - Understanding Computation
3. Gerald Weinberg - Quality Software Management, Vol 1: Systems Thinking
4. Donella Meadows - Thinking in Systems
5. Brendan Burns - Designing Distributed Systems
6. Clarence Larking - Dispensational Truth
7. Betsy Beyer - Site Reliability Engineering
8. Steven Pinker - Rationality: What It Is, Why It Seems Scarce, Why It Matter
9. Lies My Gov't Told Me: And the Better Future Coming
10. Traced: Human DNA's Big Surprise
11. Jez-Humble, Gene Kim - Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
12. Brendan Gregg - Systems Performance
13. Site Reliability Engineering
14. Building secure & reliable systems
15. Neal Ford, Rebecca Parsons - Building Evolutionary Architectures
16. The Hard Thing About Hard Things - Ben Horowitz
17. Introduction to General Systems Thinking - Gerald Weinberg
18. Return of the God Hypothesis - Dr. Stephen Meyer
19. Building LLMS from scratch

Measuring developer productivity is a hot and controversial topic, and there have been many contributions from the likes of McKinsey, Kent Beck, Dan North, Gergely Orosz that deal with the subject matter from both sides (we can measure accurately vs. measuring is hard). My intent is to rather provide guideposts to the leader placed in a position to measure developer productivity. What should he or she do if the request is part of compliance with business executives? Or how can they get comfortable with the idea, and how can they take the next steps?

The Driving Forces

Now the need to measure can come from two forces: an external request from business or an internal demand to improve. In the former case, where an executive team or manager is requesting metrics, we will call this compliance. In the second case, where a leader and member of the delivery team want to improve, we will call this autonomy. Autonomy because there are fewer constraints and a greater ability to succeed in measuring relative to the context of the team and its practices.

Guidepost 1: Why?

But before we begin any journey, we must ask: Why? This seems like an obvious question, but in some organizations, it is a very difficult question to get the answer to. Some organizations may require it with the solid intent of improving continuous delivery. Or executives might pursue it to create some sense of tangible measure of performance (like that seen in sales/manufacturing). Another might be an engineering manager frustrated with an inability to generate impact from a highly skilled team of developers. Both require different strategies, but ultimately, it's important to understand why they're being done.

1. What is the perceived outcome of measuring developer productivity?
2. Why is this outcome necessary?
3. Could the outcome be a side-effect or is it a root-cause?

Compliance:

Guidepost 2: Behavioral Change

In terms of compliance, acceptance initially is key to granting you the room and space to be effective in communicating, inquiring, and sharing potential concerns. A fundamental question to ask is: if we did measure or leverage a set of measures and their results were negative; would they result in a change of behavior? More specifically, would business, management, or leadership invest to create the change they want. Is the lemon worth the squeeze?

Guidepost 3: Define

In compliance, it's very important to clarify terminology. One such word is productivity. We want more productive developers, sure, but what does that mean? Stable systems less features; unstable systems, rapid features. Iron out the terminology and be sure both parties are talking about the same thing.

Guidepost 4: Devise

In compliance, and if available, distill your concerns into well-articulated thoughts. When I was presented with the requirement to measure my teams, my first thought was DON'T. Inherently, all my years of experience as a developer and in leading teams had created a mental and abstract gate on my pre-frontal cortex that raised a red flag, but I was unable to articulate it effectively to others. Particularly business executives.

Recently, I sat down and did so, and these are my concerns/challenges to measuring developers:

1. Misuse: loss of understanding of individual teams and how they operate, thus enforcing behavior that does not align with or correlate to the team's practices.
2. Misinterpretation: Strategic decisions taken with generalized data across many teams that lead to large shifts in investments (time and money)
3. Misalignment: Metrics in isolation are not silver bullets. Meetings may be considered the No. 1 hindrance to deep work. But in viciously addressing it, we could see strong declines in company culture and collaboration.
4. Misplaced: A set of metrics is applied to achieve an outcome, but despite the positive nature of those metrics, it has little to no effect on that outcome.
5. Misdirection: The metrics give the business a false sense that all teams are delivering well and equally because of their numeric compliance (Goodhart's Law).

Guidepost 5: Derive

If you do have the ability to aid in the metrics that can be leveraged to measure developers' performance, don't depend on any single metric. There are no silver bullets. Secondly, try making it a three-tier set of measures.

1. With a people-based focus, this is about perceptions of how people feel or experience things.
2. With a system-based focus, this is about attaining more factual or hard truths about the performance of systems.3. With a user-centric focus, this is about deciphering and honing in on the right outcomes of the consumed output.

Guidepost 6: Partnership

This is a crucial part, don't become the enemy of business or management. Rather, partner and see the journey as an experiment. Partnerships are a great mechanism for achieving the right outcomes, as they enable you to communicate concerns with a-lot more ease.

Autonomy

With autonomy, the journey should be the same: why and to what outcome, and how will measuring productivity attain it. It could often be an experiment to understand different measures and assess their worth and impact. But the worst thing you could do is to have metrics or measures for the sake of having them.

Guidepost 7: Mental Frameworks

If you are clear on your outcome, there are three strongly supported mental frameworks for measuring developer productivity. I won't go into the details of each here, but they are worth reading up on. That is the problem each is trying to address and the value you could derive from leaning on them.

D.O.R.A

Use case

If you are interested in migrating teams towards small changes, frequently deployed. This is great for teams that are still largely waterfall. DORA is meant to track delivery practices and measure them, not the productivity of people.

S.P.A.C.E

Use case

The focus of SPACE is to clarify developer productivity, but to also focus on more than just systems, but how people consume those systems. It's more of a holistic view of the software development lifecycle by not only improving how software is produced, but also optimizing how it is consumed within the organization.

DEVEX

Use case

DevEx is concerned with the overall experience of developers. The problems it addresses are:

1. Tooling and infrastructure
2. Processes and Practices
3. Culture and feedback

DevEx focuses on making the development process more enjoyable and productive, which can lead to faster development cycles, higher quality software, and more innovation.

A helpful analogy for understanding the aims of these 3 studies is the following:

Hope that helps :)

Chaos surrounds us; it’s ubiquitous. Just consider the second law of thermodynamics, which asserts that everything tends toward disorder. Whether in our personal lives through imbalances, tragedies, or simply the daily pressures of work, chaos is a thread that connects us all. We may not experience chaos at the same time, in the same way, or in the same place, but inevitably, it will appear, as surely as sparks fly upward.

Reflecting on my own life and the challenges I’ve faced over a lengthy career in various roles—Linux Administrator, Development Manager, Developer, and now Team Lead—I sought to apply a new dimension of thought to these challenges. What am I not seeing? What can I learn better? So, I turned my gaze to outer space and the most powerful chaotic entity in our known universe: black holes. If this entity epitomizes all things disorganized, disruptive, and destructive, what can I learn from its design and nature? More importantly, how can I apply those lessons to the chaos that surrounds us? This introspection led me to black holes.

2. Terminology

Let's build up to what a blackhole is by going through some grounding in terms of terminology that we will use later.

Gravity: The force that attracts objects with mass towards one another. In black holes, gravity is incredibly strong, distorting space-time.

Space-time: Space-time is the four-dimensional fabric that combines space and time, shaping how objects move and interact under the influence of gravity. Or said differently, space-time is often referred to as the fabric of space because it combines the three dimensions of space and the one dimension of time into a single, interconnected framework that can be warped by mass and energy.

Blackhole: A region of space where the gravitational field is so strong that nothing, not even light, can escape from it.

Singularity: The singularity of a black hole is a point at its very center where gravity is so strong that it crushes all matter into an infinitely small space with infinite density.

Accretion Disk: is a swirling ring of gas, dust, and other material that forms around a black hole

Event Horizon: The boundary surrounding a black hole beyond which no light or other information can escape.

Tidal Forces: Tidal forces are the differences in gravitational pull on different parts of an object, stretching it when near a massive body like a black hole.

Spaghettification: The process by which an object would be stretched and elongated as it falls into a black hole due to extreme tidal forces. Your head and your feet would experience different forces as your feet would get pulled into long strands spaghetti-like that would stretch you towards the singularity.

Hawking Radiation: The theoretical radiation predicted by Stephen Hawking that black holes can emit due to quantum effects, potentially causing them to lose mass and evaporate over time.

1. Quantum Effects:

   • Near the event horizon of a black hole, quantum mechanics predicts that particle-antiparticle pairs can spontaneously form.

2. Particle Pairs:

   • Normally, these pairs annihilate each other quickly. However, at the event horizon, one particle can fall into the black hole while the other escapes.

3. Energy Loss:

   • The escaping particle takes energy away from the black hole. This energy loss appears as radiation emitted by the black hole.

4. Black Hole Evaporation:

   • Over a very long time, this process causes the black hole to lose mass and energy, potentially leading to its eventual evaporation.

Special relativity: (1905) Einstein’s theory dealing with the physics of objects moving at constant speeds, especially near the speed of light, and how time and space are relative.

General relativity: (1915) Einstein’s theory describing how gravity affects the fabric of space-time, predicting phenomena like black holes (mass and energy)

Minkowski diagram: is a space-time diagram used in special relativity to visualize events. It typically includes two axes: time (vertical) and space (horizontal).Light cones represent the paths light would take, forming a 45-degree angle with the axes.

Penrose diagram: also known as a conformal diagram. Is a way of representing spacetime that simplifies the structure of infinity to a finite distance, allowing the entire infinite spacetime to be depicted in a finite diagram. This very similar to a picture of the earth, Mercator diagram, where the sizes of the continents are obscured or compromised so the angles can be protected. The intent is to allow for navigation and moving around the earth as a ship for example. In the Penrose, it is the same concept but to the effect where infinity is compromised (reduced) so we can reason about infinite spacetime.

3. Quiz of Misconceptions?

3.1 What would happen if you fell into a blackhole?

• If you fell into a black hole, you’d experience extreme tidal forces stretching you out (spaghettification) as you approach the event horizon, the point of no return. Time would slow down for you compared to outside observers, making you appear to freeze at the horizon. Once inside, you’d continue falling towards the singularity, where gravity becomes infinitely strong, and space-time curvature is infinite, like an ultimate crash point where all known physics breaks down. This journey into the black hole would be a one-way trip with no escape.
• Another theory is that you would hit some kind of fire wall, and just explode.
• Either way, you die.

3.2 A blackhole is a vacuum

• A blackhole is not a vacuum. A vacuum by definition is empty space. A blackhole on the other hand as witnessed by accretion disk contains matter and gases, facing extreme pressure of gravity.

4. Chaos in Software Development

4.1 Lesson: Chaos has a Hidden Order

4.1.1 The Elegant Solution Gone Bad

If there is one clear guarantee, it is that in whatever role you are in, you will face a situation that presents a problem impacting someone, yet on the surface makes no sense or is complex and potentially challenges reason. Developers commonly encounter this when troubleshooting software defects. I faced one such situation with our high-throughput, highly multi-threaded monitoring architecture. We were polling over 12,000 devices and extracting about 60 billion data points a month, using nearly 40 MySQL servers to gather real-time metrics about machine health so we could notify customers when their machines were in jeopardy.

Unfortunately, we hit an issue where we were losing data for new devices with long names because we used the device name, customer name, and date as table names for storing data. MySQL has a table name limit of 64 characters. I implemented a fix, which was just three lines of code to generate a hash of the name. It felt like an ideal, simple, and highly effective solution. I was so proud. All testing indicated it worked and integrated beautifully across our systems. It went live, and the process was smooth. I had followed the system through two proven examples, and I now had confirmation it had worked. YAY!

A week later, the key nodes responsible for flushing data to the database from memory broke. They refused to flush any data to our databases, effectively breaking our data persistence layer. I spent hours trying to reproduce or understand the problem, reading and re-reading the code. Nothing made sense. The code was largely untouched. I sat down with the team and walked them through the problem. I spoke to our Director, a seasoned developer with over 20 years of experience, and he too was stumped. I re-read the code repeatedly, even reviewing my change. Three lines to generate a hash couldn't possibly be the problem. We were so confused. I started developing conspiracy theories about what was happening, delving into the internals of the GC, looking for bugs in the JVM, you name it. Reason didn't apply, so I was now delving into the land of the impossible.

Eventually, we made a judgment call to contact the author of the persistent layer who had immigrated. We granted him access to the systems, and in a few hours, he found the problem and gave me a call. The first thing he opened was my three lines of code. I hadn't put a lock around the three lines of code; simplistically, it wasn't thread-safe.

4.1.2 Black Holes Have a Hidden Order

When I think about black holes, I envision an unimaginable force of destruction—able to swallow planets and destroy galaxies. They are the epitome of chaos. But just like the chaos that resulted from my seemingly illogical code change, there is an actual hidden order. A system of dysfunction still based on the realities and physics of our world.

If we were physicists studying black holes, how would we even begin to understand them? How could we think about their nature and design, and more so, if their singularity collapses into infinity, how can we even think about its effects, draw theories, and conclusions? How do we reason about them? But even chaos has a hidden order. And we don't have to make up new rules to govern our understanding; special and general relativity are sufficient. In fact, this problem was solved earlier. Let's revisit our Penrose Diagram.

4.1.3 Penrose Diagrams

Penrose diagrams assist in understanding the causal structure of black holes and are a powerful tool in theoretical physics. They simplify the infinite regions, visualize the causal structure, analyze interior regions, study black hole dynamics, and help understand global properties.

What are Penrose diagrams? Well their like mercator projections. You know the picture of the continents. As you know, they have several incorrect distortions, one of which is large land masses stretched out at the poles. Why is this done? To preserve the angles for navigation. So to the Penrose diagrams are able to take the complexity of blackholes and provide insights around it's causal structure, it's infinite regions and much more. If you review the diagram, you will see, on a finite space, it collapses infinity. It creates an infinite future vertically, a infinite past at the bottom, infinite space that moves from right to left.

4.1.4 Even Blackholes have a hidden order

Referring back to my experience with those simple 3 lines of code that caused disaster. There was an order to the chaos that initially looked in-comprehensible. As we look at blackholes, despite physicists continual struggle to understand it's chaos, in roads have been made with leaps by Sir Roger Penrose to push the field forward with Penrose Diagrams. In all this, and even in our own lives, there is a pattern of taking the realities and constraints of what we know, and applying it to the unknown. We shouldn't start with chaos, with the unknowns, but start from the realities of what we do know slowly breaking down and navigating the chaos. To every chaos, there is an order. A system, and it's not beyond the realms of our reality.

"No problem can withstand the assault of sustained thinking"

5. Chaos with Soft Skills

5.1 Lesson: Don't be afraid of chaos

5.1.1 A Brief History of Time

This is not so much about black holes but a lesson in one of the most intriguing theories surrounding them, proposed by Stephen Hawking in 1974. Hawking Radiation predicts that black holes decay, combining two previously separate realms of physics: Quantum Mechanics and General Relativity.

However, not long ago, there was an article on Forbes where another PhD physicist completely dismantled the theory. Since then, there has been much debate about its correctness and legitimacy. Some even say that Hawking Radiation is nothing more than a theory or narrative Hawking put together as a way to help readers of his book "A Brief History of Time" understand black holes better, suggesting that real physicists know the truth.

5.1.2 Lesson

Regardless of the debate, Stephen Hawking took a bold step in putting forward this theory. Remember, he released this along with his book "A Brief History of Time" in 1974, when there was no internet or large language models, and black hole theory was significantly less advanced. He knew it was controversial because it challenged established views around general relativity and quantum mechanics. Whether to be hailed as an Einstein or much later an idiot, he put forth his theory.

Often, as technical people, ideas, potential solutions, and designs may be lost because of what is established and a lack of belief or confidence. Solutions should be judged on their merit and put forth with conviction. They should not be lost because we fear what is, or are enveloped by a lack of confidence in our own insights.

“True innovation often requires the courage to challenge the impossible. Embrace your ideas and let them shine, for they may shape the future.”

6. Chaos in Life

6.1 Life through the lens of your chaos

6.1.1 Hosting Company Experience

I joined a hosting company with great expectations. In fact, the architect took a liking to me and believed I could help him transform the business to a service-oriented architecture or TOGAF. Unfortunately, instead of collaborating with others and him, I tried to solve difficult problems alone, thinking I alone was sufficient for success. My efforts soon led him to incorrectly micro-manage me, and our relationship started to deteriorate. He had his own personal demons, and I wasn't helping, and soon he tried to force me out of the company. I feared him. Thankfully, I was offered a rotation to another team. Eventually, despite his best efforts to transform the organization, he ended up leaving. But that's not where the story ends. It ends with me struggling to escape the darkness of that experience. I was so hurt, I felt so incompetent, and in every interaction in that organization, I applied that lens. I felt everyone around me thought I was a fraud, useless and ill-equipped. Reaching this epiphany took a bit of work, but the place I was in was dark like a black hole; that one event caused an infinite collapse, further and further into darkness.

6.1.2 Lesson

A black hole is a dark unknown. Its event horizon is the first contact with its power and destruction. As mentioned when we covered spaghettification, on entry, there is no escape. No information escapes, not even light itself. Its darkness is all-encompassing. Today, you may be faced with a similar challenge or have been through one. The darkness can be overwhelming. Some event or situation has marred your ability to function optimally. Some set of circumstances has damaged your brand, reputation, or confidence in yourself.

My advice to you is, don't be scared of the dark. Sometimes you may try your best to push against the inevitability of the event horizon. It's an impossible task. Light and information never escape. All that's left is to push through the darkness, accept what is, learn from it what you can, and follow the infinite. Don't allow the lens of past experiences, pain, or darkness to destroy today.

Embrace the dark, and rise up. Deshi Basara, Deshi Basara!

I was recently putting together C4 Model diagrams and when I got to the last-level, I needed code level-views. This is where I stumbled onto the following automation to assist with TypeScript to UML. Automatic generation of UML from typrscript.

TsUML2

There is also a good option for C# users:

Generate OMD

Git, EditorConfig and Darn Windows Users

If you in a team and the only Linux/Mac user and using Git. This is the setting you need for you git config.

core.autocrlf=false

Git access multiple accounts

Adapt this and add to your ~/.ssh/config

# Enterprise account
Host github.com-enterprise
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_github_enterprise
  IdentitiesOnly yes

# Personal account
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_github_personal
  IdentitiesOnly yes

Make sure for each repo you set the following to match:

git config user.name "Your Enterprise Username"
git config user.email "your_enterprise_email@example.com"

Then define your remote origin:

git remote set-url origin git@github.com-enterprise:Organization/repo.git

High Fidelity Tests

This is an absolutely well articulated blog post on Testing. It emphasizes to pursue high fidelity tests. That is tests, that are closest to reality. It suggested a three-fold approach, of starting with (1) use the real thing (2) use a fake, and worst-case (3) use a mock.

I find this salient advice, tying directly to my experience.

Read it here

This is a great aid if you looking to get insight into debug information via console, while not using a debugger. DAP sucks.

Dumpify

Retrieving dependadot alerts from Github API

import csv
import requests

OWNER = 'your_owner_name'  # GitHub Owner name
REPOSITORIES = ['repo1', 'repo2']  # List of repositories
PAT = 'your_personal_access_token'  # GitHub Personal Access Token
CSV_FILE = 'dependabot_alerts.csv'  # Output CSV file name

session = requests.Session()
session.headers.update({
    "Accept": "application/vnd.github+json",
    "Authorization": f"Bearer {PAT}",
    "X-GitHub-Api-Version": "2022-11-28"
})

def fetch_dependabot_alerts(owner, repo):
    """Fetch Dependabot alerts for a specific repository using the session."""
    url = f"https://api.github.com/repos/{owner}/{repo}/dependabot/alerts?state=open&severity=critical&per_page=100"
    response = session.get(url)
    if response.status_code == 200:
        return response.json()
    else:
        print(f"Failed to fetch alerts for {repo}: {response.status_code}")
        return []

def process_alerts(alerts, repo):
    """Process each alert to extract relevant fields, including the repository name."""
    processed_alerts = []
    for alert in alerts:
        processed_alert = {
            "repository": repo,
            "number": alert.get("number"),
            "state": alert.get("state"),
            "dependency_ecosystem": alert.get("dependency", {}).get("package", {}).get("ecosystem", ""),
            "dependency_name": alert.get("dependency", {}).get("package", {}).get("name", ""),
            "security_advisory_description": alert.get("security_advisory", {}).get("description", "")
        }
        processed_alerts.append(processed_alert)
    return processed_alerts

def write_to_csv(data):
    """Write the processed alert data to a CSV file."""
    with open(CSV_FILE, mode='w', newline='') as file:
        writer = csv.DictWriter(file, fieldnames=data[0].keys())
        writer.writeheader()
        for row in data:
            writer.writerow(row)

def main():
    """Main function to orchestrate the fetching, processing, and writing of Dependabot alert data."""
    all_alerts = []
    for repo in REPOSITORIES:
        alerts = fetch_dependabot_alerts(OWNER, repo)
        if alerts:
            processed_alerts = process_alerts(alerts, repo)
            all_alerts.extend(processed_alerts)
    if all_alerts:
        write_to_csv(all_alerts)
        print(f"Data written to {CSV_FILE}")
    else:
        print("No data to write.")

if __name__ == "__main__":
    main()

Query the data

 kubectl --kubeconfig ~/.kube/my-config get ingress --all-namespaces -o json > ingresses.json

Pretty Print

cat ingresses.json | jq -r '
.items[] |
{
  namespace: .metadata.namespace,
  name: .metadata.name,
  rules: .spec.rules[]
} |
"Ingress Name: \(.name),Host: \(.rules.host),Paths: \(.rules.http.paths[] | "Path: \(.path), Service Name: \(.backend.service.name), Service Port: \(.backend.service.port.number)")"'

InnerSource

What is InnerSource? Simplistically it's nothing more then when a company tries to do open-source but in a closed space.

3 minute video I found helpful

InnerSource is enabled by tools and processes, but it is also a change to the culture. The biggest change is allowing mistakes, talking about them, and learning from them.

DORA vs SPACE vs DEVEX

I found this really great analogy:

RACI Matrix

A RACI chart, also called a RACI matrix, is a type of responsibility assignment matrix (RAM) in project management. In practice, it’s a simple spreadsheet or table that lists all stakeholders on a project and their level involvement in each task, denoted with the letters R, A, C or I. Once these roles are defined, assignments can be attributed to the roles and work can begin.

R, A, C, I stands for:

Responsible Accountable Consulted Informed

Forbes Link

Team Topologies

1. Team Topologies Overview

Team Topologies, as described by Matthew Skelton and Manuel Pais in their book “Team Topologies,” focuses on optimizing team interactions and alignments with business goals. The core team types and interaction modes are key concepts in this framework.

2. Core Team Types

a. Stream-Aligned Teams

• Definition: Teams aligned to a flow of work from a segment of the business domain. • Purpose: Delivering valuable increments of work to end-users continuously. • Example: A team dedicated to a specific product feature, such as the user onboarding process or payment gateway.

b. Enabling Teams

• Definition: Teams that assist other teams to overcome obstacles and adopt new technologies or practices. • Purpose: Providing specialized knowledge and facilitating the adoption of best practices. • Example: A team focused on helping other teams implement CI/CD pipelines or adopt cloud technologies.

c. Complicated-Subsystem Teams

• Definition: Teams responsible for building and maintaining complex subsystems that require specialized knowledge. • Purpose: Handling parts of the system that require deep expertise and cannot be easily managed by stream-aligned teams. • Example: A team dedicated to developing a high-performance database engine or a sophisticated machine learning model.

d. Platform Teams

• Definition: Teams that build and maintain platforms used by other teams to deliver work. • Purpose: Providing self-service APIs, tools, and services to enable other teams to deliver software efficiently. • Example: A team managing the internal cloud infrastructure, CI/CD tools, or authentication services.

3. Interaction Modes

a. Collaboration

• Description: Teams work together for a defined period to achieve a specific outcome. • Use Case: When multiple teams need to work together to deliver a complex feature that spans different domains.

b. X-as-a-Service

• Description: One team provides a service that other teams can consume independently. • Use Case: Platform teams offering CI/CD pipelines as a service to stream-aligned teams.

c. Facilitating

• Description: Enabling teams facilitate and assist other teams to overcome specific challenges. • Use Case: An enabling team helping a stream-aligned team adopt a new testing framework.

4. Common Practices for Organizing Delivery Teams

a. Define Clear Team Boundaries and Responsibilities

• Clarity: Ensure each team has a clear mission and well-defined responsibilities to avoid overlaps and confusion. • Autonomy: Empower teams to make decisions within their domain to increase accountability and efficiency.

b. Optimize for Flow

• Stream Alignment: Align teams to the flow of work that delivers value to customers. Avoid organizing teams around rigid component boundaries. • Value Streams: Identify and organize around value streams to ensure teams can deliver end-to-end features.

c. Promote Cross-Functional Collaboration

• Skills Diversity: Ensure teams have the necessary skills to deliver complete solutions, including development, QA, UX, and operations. • Collaboration Tools: Use tools and practices that facilitate seamless communication and collaboration, such as agile boards, chat platforms, and video conferencing.

d. Facilitate Continuous Improvement

• Feedback Loops: Establish regular feedback loops through retrospectives, reviews, and one-on-one meetings to identify areas for improvement. • Learning Culture: Encourage continuous learning and improvement by providing access to training, conferences, and knowledge-sharing sessions.

e. Balance Stability and Innovation

• Stable Base: Maintain a stable platform and set of practices for the majority of the work while allowing for innovation and experimentation in a controlled manner. • Innovation Time: Allocate time for teams to explore new ideas and technologies that can drive future improvements.

5. Practical Implementation Tips

a. Start Small and Scale Gradually

• Pilot new team structures with a small group before scaling across the organization. • Gather feedback and adjust based on what works and what doesn’t.

b. Use Metrics to Guide Decisions

• Measure team performance using relevant metrics such as lead time, deployment frequency, and defect rates. • Use these metrics to identify bottlenecks and areas for improvement.

c. Encourage Ownership and Accountability

• Foster a sense of ownership by allowing teams to take full responsibility for their services or components. • Implement practices like DevOps where teams are responsible for both development and operations.

Conclusion Organizing delivery teams effectively requires a thoughtful approach that aligns with business goals and fosters collaboration, autonomy, and continuous improvement. By leveraging the principles of Team Topologies, organizations can create an environment where teams are empowered to deliver high-quality software efficiently and adapt to changing needs.

What to do if you blank in an interview?

It’s natural to occasionally lose your train of thought or feel flustered during an interview. Here’s a structured approach to handle such situations gracefully:

1. Pause and Take a Breath

• Stay Calm: Take a deep breath to calm your nerves. It’s okay to take a moment to collect your thoughts. • Pause: Use a brief pause to compose yourself. This can also give the impression that you are considering your answer carefully.

2. Ask for Clarification

• Clarify the Question: If you’re uncertain about the question, politely ask the interviewer to repeat or clarify it. This can give you additional time to think and ensure you’re addressing the right topic. • Example: “Could you please repeat the question? I want to make sure I address it correctly.”

3. Acknowledge and Redirect

• Acknowledge the Pause: If you’ve forgotten your point mid-answer, acknowledge it briefly and redirect the conversation. • Example: “I apologize, I seem to have lost my train of thought. Let me start again.” • Restart or Pivot: Either restart your answer or pivot to a related point that you can speak about confidently.

4. Use Filler Phrases

• Filler Phrases: Use phrases like “That’s a great question” or “Let me think about that for a moment” to buy yourself a few seconds to regain your composure. • Example: “That’s a great question. I think the key point here is…”

5. Summarize and Simplify

• Summarize Your Key Points: If you’re struggling with a detailed response, summarize your key points and then expand on them. • Example: “In summary, my approach would focus on collaboration, continuous improvement, and leveraging best practices. To elaborate…”

6. Be Honest

• Admit if You Don’t Know: If you genuinely don’t know the answer, it’s better to admit it than to fumble through an uncertain response. • Example: “I’m not sure about the exact details, but I would approach it by doing XYZ…”

7. Offer to Follow Up

• Follow-Up: If applicable, offer to follow up with a more detailed answer after the interview. • Example: “I don’t have the exact information on hand, but I’d be happy to follow up with a detailed response after the interview.”

It allows an organization to remember. It is easier to remember that which is tied to emotion then that which is pure fact. Speak in stories.

Speak In Stories

The Power of Behaviour Driven Development

Testing meets story-telling in BDD.

1. TDD vs BDD

2. BDD is about Communication

3. BDD is about shared understanding

4. BDD is another shift left

Build Your Own AI Code-Reviewer

In this journey, I embarked on creating a plugin for my IDE, designed to highlight code snippets and provide insights on their function, quality improvement, and refactoring potential.

Why Build Your Own?

Here are compelling reasons to consider:

1. A local LLM (Large Language Model) guarantees your privacy.
2. The absence of a suitable plugin for your specific IDE.
3. Desire to customize the LLM's role and focus.
4. Interest in leveraging open-source LLMs for experimentation.
5. Curiosity to explore various LLMs.

If these resonate with you, prepare for a rewarding endeavor!

The Steps Involved

1. Choosing the Right LLM
2. Setting Up the LLM
3. Mastering LLM Interactions
4. Crafting Your IDE Plugin
5. Refining the Outcome

Choosing the Right LLM

Limited by my hardware, I sought LLMs that were compact, efficient, and specialized in coding. I discovered a helpful list by continuedev and chose Deepseek Coder.

Setting Up the LLM

My go-to was LM Studio. Keep these points in mind:

• LLMs come in Base and Instruct types: Base excels in completing code, while Instruct is adept at writing from scratch.
• Quantization affects the LLM's performance, balancing inference quality, speed, and resource usage.

Tip: For a 7B model, a q4_K_S quantization is recommended.

Interacting with the LLM

LM Studio facilitates interactions similarly to the OpenAI API. Here's a sample interaction using curl or Httpie:

{ 
  "messages": [ 
    { "role": "system", "content": "Review my code as an expert senior developer. Be critical. Focus on readability and maintainability. Refactor if needed." },
    { "role": "user", "content": <code snippet> }
  ], 
  "temperature": 0.7, 
  "max_tokens": -1,
  "stream": false
}

Define the LLM's behavior as 'system' and input your code snippets as 'user'.

Note: Code must be properly escaped for POST HTTP requests.

Building Your IDE Plugin

I developed a plugin for LazyVim using neovim. Here's the process:

• Initialize your plugin on GitHub.
• Start with a simple echo function.
• Install the plugin in LazyVim (~/.config/nvim/lua/plugins/).

# reviewer.lua
return {
  {
    "daneb/reviewer.nvim",
  },
}

• Enhance the plugin functionality (see Reviewer.nvim).
• Use LazyVim to sync plugin updates.
• Implement keymapping (located in ~/.config/nvim/lua/config/keymaps.lua).

vim.api.nvim_set_keymap(
  "v",
  "<leader>lm",
  ':lua require("reviewer").main_function()<CR>',
  { noremap = true, silent = true, desc = "AI Reviewer" }
)

Tweaking the Result

Your plugin, now functional in your IDE, can be aesthetically enhanced with features like window sizing, colors, and borders.

Challenges remain, such as ensuring proper code snippet escape, particularly with regex. Initially, I used a curl call instead of the built-in neovim HTTP API.

It's a work in progress, but it's an accessible, enjoyable, and fulfilling project!

Currently Reading

2. Refactoring - Martin Fowler

Read

1. Atlas of Management Thinking - Edward De Bono
2. Radical Candour - Kim Scott
3. The Lion, The Witch, and The Wardrobe - C.S. Lewis
4. Think Again - Adam Grant
5. The Fellowship of the Rings - JRR Tolkien
6. Black Holes - The key to understanding the Universe
7. Think Like an Engineering Manager
8. Are your lights on? - Gerald Weinberg
9. Elevate Your Productivity: Automate Everyday Work Tasks with ChatGPT
10. Tidy First - Kent Beck
11. Fundamentals of Software Architecture: An Engineering Approach
12. The Book of Daniel - Dr. Ruckman
13. The Secrets of Consulting Vol 1
14. The Book of Three - Lloyd Alexandar
15. 37 Things one architect knows about IT Transformation - Gregor Hohpe
16. The Worst Class Trip ever - Dave Barry

Planned

1. Robert Nystrom - Crafting Intepreters
2. Tom Stuart - Understanding Computation
3. Gerald Weinberg - Quality Software Management, Vol 1: Systems Thinking
4. Donella Meadows - Thinking in Systems
5. Brendan Burns - Designing Distributed Systems
6. Clarence Larking - Dispensational Truth
7. Betsy Beyer - Site Reliability Engineering
8. Steven Pinker - Rationality: What It Is, Why It Seems Scarce, Why It Matter
9. Lies My Gov't Told Me: And the Better Future Coming
10. Traced: Human DNA's Big Surprise
11. Jez-Humble, Gene Kim - Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
12. Brendan Gregg - Systems Performance
13. Site Reliability Engineering
14. Building secure & reliable systems
15. Neal Ford, Rebecca Parsons - Building Evolutionary Architectures
16. The Hard Thing About Hard Things - Ben Horowitz
17. Introduction to General Systems Thinking - Gerald Weinberg
18. Return of the God Hypothesis - Dr. Stephen Meyer

How I Built My Own Static Site Generator for a Personal Blog

In the ever-evolving landscape of web development, the allure of simplicity often leads to innovative solutions. This was precisely my experience as I ventured into creating my own static site generator for my personal blog. It definitely doesn't have everything, but it's enough, done across 2 days and is only 132 lines of C#. Here’s a glimpse into my journey, offering insights and practical steps that might inspire your own custom project.

Step 1: Embracing Markdown and C# for Content and Processing

The cornerstone of my project was the utilization of Markdown for content creation, chosen for its simplicity and flexibility. Coupled with C#, a language I was already comfortable with, I used the Markdig library to process Markdown files into HTML. This setup provided a straightforward way to write and transform blog content.

Step 2: Implementing Templating with Razor

Consistency in appearance is key to any blog's identity. Leveraging the power of the Razor templating engine, commonly used in ASP.NET, I could craft dynamic templates. These templates ensured a uniform layout and style across various blog posts, embedding the essence of the blog’s personality into every page.

Step 3: Styling with Tailwind CSS

Aesthetic appeal and responsive design are non-negotiable in today’s web. Tailwind CSS was my choice for its utility-first approach, enabling me to elegantly style the blog. The integration of Tailwind CSS guaranteed not only functionality but also visual appeal, ensuring the blog's seamless presentation on diverse devices.

Step 4: Front Matter Parsing with YamlDotNet

A crucial feature for any blog is the ability to categorize and manage metadata for each post. YamlDotNet came to the rescue, allowing me to parse Front Matter in Markdown files. This addition enabled me to define properties like title, date, and categories directly within the Markdown, greatly enhancing content manageability and organization.

Step 5: Embedding GitHub Gists

To enrich the technical aspect of the blog, embedding code snippets was essential. GitHub Gists provided a simple yet effective way to incorporate these snippets. By placing placeholders in the Markdown content, which were later replaced with Gist embed codes during HTML generation, I could seamlessly integrate dynamic code examples into the posts.

Step 6: Deployment on GitHub Pages

The final piece of the puzzle was deploying the blog. GitHub Pages offered an efficient and straightforward hosting solution. After setting up a repository and configuring the GitHub Pages settings, I pushed the static HTML files, bringing the blog to life on the web.

Overcoming Challenges

The journey wasn’t without its challenges. Ensuring that Tailwind CSS properly styled the dynamically generated HTML content required some tweaking, solved by configuring the JIT Compiler and the correct loading sequence. Deploying the site with a custom domain on GitHub Pages needed careful DNS configuration and repository setup, including a .nojekyll file to bypass Jekyll processing.

Conclusion

Crafting a static site generator from scratch was not only immensely satisfying but also provided a tailor-made solution for my blogging needs. It allowed complete control over the design, functionality, and content, resulting in a unique and personal blogging platform. For those inspired to embark on a similar endeavor, remember to keep things simple, leverage familiar tools, and enjoy the creative process. Your perfect blogging platform might just be a few code lines away.

Happy coding and blogging!

Introduction

Good morning brothers and sisters. If we reflect on the period or time of Covid, we consider it was a scary and dark time for us all. A time when people where in search of answers. For some this was science, but sadly science became the control of governments to dictate their narratives and propagate their outcomes. Studies once reliable were shown to be easily polluted, easily accepted and the community that were supposed to gate was thin.

An example was 3 people who wrote 20 hoax papers about gender-identity, group-identity and sexuality etc. 6 of their papers were rejected. 7 were under serious peer reviews and the rest were progressing to approval. Another random sample of 5000 papers in one field alone, Neuroscience, revealed 34% of papers were plagiarized or just made up in 2020.

During Covid we also saw a divisions in society, as there were those against vaccines and those for. People were ostracized. Society and people turned on each other. The media took sides and pushed agendas from governments right or wrong. What was clear, was that truth was relative. It was cheap. Easy to deny, easy to twist. Information was censored. People were scared. People were confused. They were looking for truth, but deceived or unable to discern truth. It was a dark time.

Not only where we fighting a diseases, government intervention, but there was a mindset being proliferated and that of gender-politics (still making it's rounds today). Men could call themselves women, trans individuals wanted to be called by specific pronouns, people could be whoever they wanted to be. A women could label themselves man, and a man label themselves a woman despite their clear physical design. This thinking continues today in America and now in Europe. Again, truth is not based on reality but is not defined from the figments of peoples imaginations.

But amidst these dark times, where truth is relative and controlled, there are some truths no man can alter.

1. Our God is true. Basic human reasoning could tell you that.
2. And the second, the focus for the message today, The Gospel is true and is the worlds only hope.

READ 2 Corinthians 4:1-6

May blindness be removed

This morning, that light has shone out of darkness, for today there be some seated here whose blindness has been removed. But there are also others who remind blind. Darkness is upon you, but you believe you are in the light. Be warned friend, it is easy for darkness to appear as light, when darkness is all you know. May the Lord awaken you this morning, may your eyes open, may the glorious light of the gospel shine and may it give you the light of the knowledge of the glory of God.

Let's turn to the Lord in prayer.

Pray for someone to get saved. For the darkness to be removed

Body

1. Hell matters, are you going there?

1.1 Hell is real

i. The logical argument

• I just want to say this morning, if it's not immediately clear, hell is real.
• Look out at the very basics mechanics and patterns of the our world.
• There is a very definitive law embedded in all things. You reap what you sow. You sit around and do nothing and well you will be without a job. You don't study for exams and you will fail. You break the law, you are punished. Why should the fundamental mechanic be any different when it comes to eternity when this is our reality?

ii. The biblical evidence

• But perhaps if the logical argument doesn't suffice how about the truth, accuracy and reliability of scripture. There are 54 verses in scripture that tell us of hell (Deut 32:22, Isa 5:14, Luke 12:5, 2 Peter 2:4).

Deu 32:22 For a fire is kindled in mine anger, and shall burn unto the lowest hell, and shall consume the earth with her increase, and set on fire the foundations of the mountains.

Isa 5:14 Therefore hell hath enlarged herself, and opened her mouth without measure: and their glory, and their multitude, and their pomp, and he that rejoiceth, shall descend into it.

Luk 12:5 But I will forewarn you whom ye shall fear: Fear him, which after he hath killed hath power to cast into hell; yea, I say unto you, Fear him.

2Pe 2:4 For if God spared not the angels that sinned, but cast them down to hell, and delivered them into chains of darkness, to be reserved unto judgment;

iii. Call out the guilty

• Hell is a place of eternal torment. A place of darkness. A place suitable enough for the bounds of evil. A place filled with those who have murdered, killed, raped, stolen, cheated, lied and had evil thoughts. Jesus says in the book of Mark,

And he said, That which cometh out of the man, that defileth the man. For from within, out of the heart of men, proceed evil thoughts, adulteries, fornications, murders, Thefts, covetousness, wickedness, deceit, lasciviousness, an evil eye, blasphemy, pride, foolishness: All these evil things come from within, and defile the man.

Rev 21:8 But the fearful, and unbelieving, and the abominable, and murderers, and whoremongers, and sorcerers, and idolaters, and all liars, shall have their part in the lake which burneth with fire and brimstone: which is the second death.

• Note scripture says, "all liars", not some. All liars shall have their part in the lake of fire. If you have lied before, you stand condemned before a Holy God!
• How clean are your thoughts?
• As sure as the Sun will rise tomorrow, we have all fallen short of God's glory. Do you see it brother, do you see it sister?

iv. Hell is scary

• You think the challenges in this life are hard, there are nothing in comparison to come for the torment, pain, affliction and burning that awaits you in hell. In fact, hell will be cast into the lake of fire. There will be no respite. There will be no momentary relief. There will be no joy, there will be no laughter, only pain, only death, only destruction and continual evil.
• Not for one lifetime, not for two, but for all eternity. All you will know is PAIN. All you will know is suffering. You have broken God's law and God in His Holiness has defined the judgement. If God was so creative to create a world as beautiful as this earth, imagine when He applies His mind to creating an eternal prison for those who have murdered, raped, blasphemed, lied and rejected Him.

1.2 Death and Hell ride together

i. What hell is?

Rev 6:8 And I looked, and behold a pale horse: and his name that sat on him was Death, and Hell followed with him.

• Hell accompanies Death. They ride together.
• If you have to die today, if you had to step out of this church and meet you death, where would you go?

ii. Have you broken the law?

• If you have broken but just one of God's laws, you have failed to meet God's requirement for heaven.
• Being in church, attending church does not redeem a sin committed.
• Popes, men, money, good deeds cannot undo breaking God's law.
• Your father, your mother, your family cannot redeem you from the judgement to come.
• No ordinary man, no woman can stand as substitute.
• Where are you going when you die? Have you met God's standard?

2. Jesus matters, do you believe in the right Jesus?

2.1 Jesus is God (John 1:29)

i. The many Jesus

• Turn your Bibles to John, and read verse 29.
• We see John gaze out and say a most prophetic thing.

ii. Exposit verse

1. Behold, gaze with intent, pay attention
2. Jesus "taketh away the sin of the world" (how amazing, the disciples and those closest to Him could have learnt much from these simple words of John). Yet for them they were awaiting the literal kingdom, and missed God's plan. Jesus was going to take away sin.
3. But John the Baptist, is not called the greatest prophet without reason by Jesus (Matthew 11:11). Not only is it revealed what God would do with sin, but also "how" He would do it.

iii. Jesus the Sacrifice

• "Lamb of God" - Jesus would be that way, He would be the means by which sin would be atoned. He was pointing to the cross. He was talking to Jesus being God's son. The creator dying for His creation. The son dying for the atonement of sin.
• Does this not reflect the Holiness of God, by the payment required.
• Does this not reflect the extreme cost for sin, God needed a payment for your sin and mine, and He His son, to be beaten, to be pierced, to walk this earth and be mocked, and to be crucified, so you and I can have freedom from sin, atonement from sin, and life eternal.

2.2 The real Jesus (John 1:1-3, 14; 1 John 5:7)

i. The Jehovah Witness

• I've run into the JW's many times, had some great conversations through the years.
• And while I was growing up, being in an Indian school, had many muslims try to convert me.
• But what was interesting and common hooks both used in their conversion process as a form of gateway to their religions was Jesus. Both see Jesus as a great prophet and that's it.

Mar 13:22 For false Christs and false prophets shall rise, and shall shew signs and wonders, to seduce, if it were possible, even the elect.

ii. Not the same Jesus

• Their Jesus is not our Jesus. Their Christ is not our Christ of the Bible. Their Jesus is a prophet, our's is God

iii. Why does this matter?

• How can sins of the world be atoned for by the death of a man, even if he were perfect. Perhaps he would pay for 1 or 2. But to be the atonement for all sin, for all men and women since the dawn of time. This is significant. The payment has to be great, and the only thing that makes sense is that Christ himself, God himself becomes that payment, that atonement. Jesus MUST BE GOD FOR THE PAYMENT TO BE SUFFICIENT.
• Only an ETERNAL PAYMENT, can stand for an ETERNAL JUDGEMENT.
• Only an ETERNAL PAYMENT, can stand for ETERNAL SECURITY.
• Only an ETERNAL PAYMENT, can redeem you from HELL.
• That PAYMENT has to be Jesus Christ as GOD.

iv. The supporting verses

• The verses that are irrefutable to the fact that Jesus is God is in John 1:1-3, 14-15, 1 John 5:7.

• Please turn to John 1:1

  1. So we see there is the Word. This word was in the beginning with God (the Word is eternal)
  2. The Word was also creator.
  3. In v14, 15 we learn His identity.
  4. Another irrefutable verse is 1 John 5:6-7 as it affirms Jesus is a part of the Trinity.

• Jesus part of the Trinity, and He is God, and He is your Savior, and He is the ONLY atonement for sin.

• This is the TRUE JESUS. There is NONE OTHER.

3. The Romans Road

3.1 Romans 3:23

i We are all guilty

• The Bible says that all have sinned. That mean's you and I. We are sinners.

• And have fallen short of God's glory.

  Romans 3:10, As it is written, there is none righteous, no not one.

• Do you see it friend? Your good works can't help. You could save 50 million lives but it would be insufficient to atone for the sin you have already committed in your thoughts, with your body or in your actions.

3.2 Romans 6:23 (a)

i. Our sin brings death

• What does sin bring?
• Well two things,
  1. it destroys your life. Sin separates from you God, but it also pushes you further into darkness. But it can also accelerate God's judgement. If you reject His word, the Gospel and continue to pursue your own, the Lord may choose to end it.
  2. secondly, sin brings the second death.

Rev 20:14 And death and hell were cast into the lake of fire. This is the second death. And whosoever was not found written in the book of life was cast into the lake of fire.

This morning, do you see your destination?

3.3 Romans 5:8

i. God made a way

• Death hangs of you sinner, death hangs over you. Eternal torment and condemnation.
• But friend, but for Jesus.
• Read Romans 5:8.
• How amazing is our Lord, while we were yet sinners, while we were still sinful.
• It's not about being clean and then coming, but about being contrite, being convicted of your sin, and seeing the need for you Saviour.
• Jesus has made a way.

3.4 Romans 10:9

i. You can be saved

• But how can I be saved you ask? How can I be rescued from the fire?
• Read Romans 10:9.
• But it is not enough to confess, to speak or to think in one's mind.
• The devil understands the scriptures. We see how he referenced it when He tried to tempt Jesus. He believes in a God, He knows God exists.
• But that is insufficient. You have to confess and believe in thine heart. It has to be down to your core, to your innermost parts.
• And when you have thou shalt be saved.

3.5 Romans 8:10

i. Free from condemnation

• The Bible says in Roman 8:1, there is no condemnation to those who are in Christ Jesus.
• When you are saved, you are free from God's wrath, you are free from His eternal judgement.
• Oh praise the Lord, for His work, for His redemption for you and I.

Conclusion

READ Spurgeons PLEA

Take a moment now, and you speak to the Lord. If your heart has been convicted by the light of the gospel, call upon the Lord. After a short moment, I will pray.

One of the lesser-discussed facets of a successful career is the health and joy of one's marriage. Though it is undeniably a personal and private matter, can we not consider it as a fundamental ingredient, or at the very least a significant factor, in cultivating an effective mindset to deliver our best work?

Assuming you have a special someone in your life, turmoil at home doesn't lend itself to efficiency at work. Struggles at home, at work, or within your socio-economic context can amalgamate into a high-stress cocktail. Consider, for instance, the impact buying a house can have on an employee's productivity during the process. I've witnessed this in myself and in team members I've guided. It often results in mental distractions, slower delivery, and interruptions. The impact is even more profound when you and your closest companion are embroiled in heated conflict.

While I'm no expert, I believe we should at least initiate the conversation and grow together. I've been in the industry for over 20 years, and for most of that time, I've been married. Ever since tying the knot, I've been intentional about ensuring the success of my home and marriage. We're joyously celebrating 13 years of matrimony this year, and it's been the best journey of my life.

When chaos descends on the world, it's comforting to find solace in the warm, loving embrace of your partner at night. This is someone who loves you unconditionally. Moreover, in your spouse, you often discover your most effective critic for self-improvement. They possess deep insights into your behavior and are able to communicate them effectively.

To stimulate this conversation, I'd like to share some high-level strategies that have been instrumental for us:

1. Your spouse must be your best friend. Friends and family are essential, but they take second place to my wife. She is always a top priority.

2. Your spouse must come before your kids. The unique love of a child is a given, but it doesn't supersede the bond and priority of a husband and wife. This bond forms the foundation of our family structure.

3. Cleave to your spouse. I don't require breaks from my wife. Instead, I seek her out, inviting her closer to me. We are partners, finding courage, strength, and love in each other.

4. Align on your mission. Our life goals, including those for our kids, family, and careers, are in harmony. Much of this was defined and articulated before we got married, during our courtship. It's crucial to address the difficult topics first.

5. Don't use work as an excuse. It's all too easy to let work become a priority at the expense of being present in your relationship. Stay mindful of this.

6. Make the time. Be present when your spouse speaks. Engage them not only on your concerns and frustrations, but ask about theirs. Show curiosity about their evolving interests.

These are some of the guiding principles we adhere to, although individual experiences will naturally vary.

Even if you forget everything else from this article by tomorrow, I urge you to remember this: Be intentional in nurturing your relationship with the person with whom you've chosen to walk life's path.

Marriage is a beautiful journey, and its beauty is largely a function of what you invest into it.

For about 3 years I've been running a D-Link DIR-825, a fibre and wireless router provided by my ISP. And here to begins my woe. I've been struggling with it's maintenance and software patching, it's long aged and become a dinosaur with no more firmware upgrades. With the increasing attacks worldwide on networks, I wanted deeper insight to the hardware and software used to defend and connect my home network.

So I decided to poke around my router, and discovered that publicly visible to the world, and not by my configuration, was an SSH service. It was running with admin privilege and with the default password set by D-Link themselves (which I guessed by the way).

Correlation is not necessarily causation of course, but the abstraction has paid a price.

But first, interesting hack

If you want your router to shutdown daily at a set time. Instead of using cron, you can use the scheduler built into the shutdown command.

# This will shutdown daily at 22:00
echo "shutdown -h 22:00" >> /etc/sysconfig/rc.local

The beauty of this is that you can interrupt the shutdown with:

shutdown -c

And to confirm if the command has fired on startup

ps -ef | grep shutdown

Back to the Home Firewall setup

My first step to correcting the problem was to try identify a physical firewall that I could purchase. I live in South Africa so choice is limited, but I wanted something entirely cost effective, ability to deep dive into network traffic and something not made in China. That was the D-Link and it's support was horrible. Sadly, the closest thing was R5000 (Ubiquity) and it didn't seem practical with the current economic climate.

That sparked an old idea, why not try a Raspberry PI 4. I attempted this before using Ubuntu server but ran into challenges with the wifi speed when it was used a Wireless hotspot. But I was on holiday now and well, why not. I had a incremental 2 phase plan.

What where some alternatives to IpFire?

1. I could have stuck with the DLink and overwritten it with OpenWrt. But sadly it wasn't supported.
2. As mentioned the Unify was R4800.
3. Just use vanilla Linux (Ubuntu etc). This is covered below in the Q&A.

Why this may be valuable to do?

1. Fine grained control of your network
2. More transparency around what is coming in and out
3. Increase learning in network design and security
4. You don't trust your existing device (it's out of firmware upgrades or really old)

Phase 1 - Proof of Concept

• Retain the D-Link for speedy wifi access, but sufficiently limit it's capability.
• Use the Pi4 as the gateway and firewall with Raspbian 64
• Get basic masquerading working for everything on the D-Link - basically all wifi connected devices routing through the firewall to the internet.

Phase 2 - Implement with IpFire

• Once that proved itself, I would replace Raspbian with something more enterprise - IpFire.
• Ensure the networking between the two devices and my home computers internet access functions correctly
• Try get rid of the D-Link and use the Pi4 as a Wireless Hotspot as well and gauge its performance

My Current Configuration

1. Fibre CPE that provides access through Ethernet cable
2. Fibre Service Provider: Coolideas
3. D-Link DIR 825 with the WAN port connected to the CPE and Wifi Hotspot
4. Raspberry Pi4

• 8GB Internal memory
• 32 GB SSD
• USB Broadcom NIC
• Internal WLAN NIC
• Internal Ethernet NIC

My Target Configuration

1. No more D-Link router (unless providing access to guests)
2. Raspberry Pi4 running IpFire
3. Fibre CPE direct into Pi4 for Internet Access (RED)
4. Second USB NIC connected to D-Link router for guest access (GREEN)
5. Pi4 as a wireless hotspot (BLUE)

The Result

Well success of course. But perhaps let me talk through some of the challenges.

Challenges in Phase 1

Should I use the WAN port to connect the Pi4 and D-Link?

• This is firstly not supported as the expectation that both the WAN IP is not the same as the WLAN.
• I used a standard port.

Do I have to do any port forwarding or masquerading on the D-Link and should the two devices share a subnet?

• No, there was no configuration needed on the D-Link.
• Yes, I used the USB NIC of the Pi4 (GREEN Zone) I used to link up to the D-Link

How should I configure the Pi4 Raspbian OS?

• I plugged the Cat 6 from the Fibre CPE into it the internal Pi4 Nic allowing DHCP to configure the internet IP address through the provider.

Did you masquerade?

• Yes, I added a simple rule to masquerade the GREEN zone (link between two devices)

# sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Why did I not stop here?

• It was insecure. I would need to spend a significant amount of time setting the firewall rules and debugging.
• Not to mention, installation a ton of software to calibrate network statistics.

Challenges in Phase 2

Now that we have a proof of concept, let's move onto IpFire.

Any tips for initial setup of Image onto SD-Card?

• In writing the IpFire image to your SD-card ensure to disable the serial cable requirement so you can set it up easily with HDMI and USB keyboard - you need to edit the uENV.txt file on the flashed SD Card:

# From
SERIAL-CONSOLE=ON 
# To
SERIAL-CONSOLE=OFF

How did you define the zones?

• I used RED for the Internet access (internal nic of Pi4)
• GREEN for all traffic from the D-Link router (USB nic to D-Link)
• BLUE for wireless traffic using the Pi4 itself
• Be advised for access from GREEN to RED I used the transparent proxy included with IpFire

It works

It's been an amazing experience thus far, by no means an enterprise grade user interface or corporate backing for sexy bells and whistles. But it's a Toyota Corolla that does the job and well.

Supported features I am getting a ton of value around is:

1. Hardware graphing performance (memory, cpu, load)
2. Firewall logs by country, port and IP
3. Tcpdump on console for troubleshooting and viewing low-level packets
4. Built-in proxy
5. Easy support for multiple networks
6. Wireless Hotspot easy configuration
7. Proxy reports and logs
8. Intrusion detection (multi-provider support)
9. IP Address black lists
10. Pakfire enables safe package installation and in-built plugin support
11. DNS resolution and configuration

Tip

It may be worthwhile when you are done to review this helpful guide around best practices from IpFire Blog A helpful tutorial that may guide your journey.

Tiny Thought

If you wait until you're motivated, you’ve already lost. Surgeons don’t always feel like doing surgery. Teachers don’t always feel like teaching. Parents don’t always feel like cooking. Firemen don’t always feel like rushing into a burning building. If you let motivation dictate your actions, inertia conspires to keep you in place.

Action creates progress. Progress creates momentum. Momentum creates motivation.

CAP Theorem

Your two choices: you have to choose between consistency or availability. You cannot have both. This assumes 100% availability but you could have degrees of consistency along with availability (or vice versa).

List.ForEach is not foreach (C#)

List.foreach will create isolated clojures that run Actions independently without side-affects. foreach is synchronous and mutates. Eric Lippert

Redis Use Cases (blog.bytebytego.com)

Playwright

• For Playwright tests in .NET, there is no need to use Playwright directly. But you can use Playwright.NUnit to implement and use Page.

Adding a User to SQL Server (some crucial steps) to connect from Docker with

1. Ensure you checkout SQL Configuration Manager - Is it running via TCP as a protocol?
2. Don't forget to enable TCP listening on the IP you require
3. User gets added to Sql Server
4. User then get's given permission in database with Securables (schemas)

Team Lead Tid-bit:

Never forget to keep your eye on the big picture when leading a team. It's easy when fighting fires and trust is low to get stuck in the trenches. In the trenches, strategy is missed and often times that leads to a disconnect in what business needs and what is visible to business.

Measuring team performance:

• When it comes to measuring a teams performance and reporting back to business, don't build your own metrics.
• Often times the metrics that drives a team internally are not the same metrics that provide business the value they need.
• How to start measuring a team for yourself? Start by figuring out how you would measure yourself.

Read:

1. Relentless - Tim Grover
2. Thinking Fast and Slow - Daniel Kahneman
3. Blink - Malcolm Gladwell
4. Peace Child - Don Richardson
5. The Magician's Nephew - C.S.Lewis
6. Mobile Solar Power Made Easy - William Prowse
7. Elon Musk - Ashlee Vance
8. Calling Bullshit
9. Surrounded by Idiots: The Four Types of Human Behaviour - Thomas Erikson
10. Atomic Habits - James Clear
11. Surrounded By PsychoPaths - Thomas Erikson
12. An Elegant Puzzle: Systems of Engineering Management
13. Hidden Treasures - Chuck Missler
14. The Mystery of Godliness - W. Ian Thomas
15. The Hobbit - JRR Tolkien
16. The Psychology of Money
17. Thinking like an Engineering Manager
18. How to make the best coffee at home - James Hoffman

Planned:

1. Robert Nystrom - Crafting Intepreters
2. Tom Stuart - Understanding Computation
3. Gerald Weinberg - Quality Software Management, Vol 1: Systems Thinking
4. Donella Meadows - Thinking in Systems
5. Brendan Burns - Designing Distributed Systems
6. Clarence Larking - Dispensational Truth
7. Betsy Beyer - Site Reliability Engineering
8. Adam Grant - Think Again
9. Steven Pinker - Rationality: What It Is, Why It Seems Scarce, Why It Matter
10. Lies My Gov't Told Me: And the Better Future Coming
11. Traced: Human DNA's Big Surprise
12. Jez-Humble, Gene Kim - Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
13. Brendan Gregg - Systems Performance
14. Site Reliability Engineering
15. Building secure & reliable systems
16. Neil Ford - Fundamentals of Software Architecture: An Engineering Approach
17. Neal Ford, Rebecca Parsons - Building Evolutionary Architectures
18. The Hard Thing About Hard Things - Ben Horowitz
19. Are your lights on - Gerald Weinberg
20. Introduction to General Systems Thinking - Gerald Weinberg
21. Refactoring - Martin Fowler