In engineering, there is a familiar idea: good enough.

For most use cases, an average value or a standard library will get you across the finish line. In many contexts, that is entirely acceptable, sometimes even preferred. Once cost is introduced, there is often a clear point of diminishing returns where pushing beyond “good enough” is not justified.

Still, systems are rarely defined by the average case. It is the edge conditions, the remaining 20 percent, that determine performance, efficiency, and margin. That is where details stop being academic and start defining real capability, and where small oversights can compound into meaningful risk.

This blog is a space for exploring that gap between “good enough” and “robust enough”.

It is a place to write about engineering problems, programming work, and the process of building tools that try to reduce uncertainty rather than accept it. Some of this comes directly from professional experience in chemical engineering. Some of it comes from curiosity and personal projects that grew out of the same habits.

Early in my chemical engineering work, I repeatedly ran into the limits of standard simulation tools and spreadsheet-based approaches. Much of the work relied on built-in libraries in Aspen HYSYS and Aspen Plus, or on simplified assumptions in Excel models that were “good enough” for most cases. When they were not, the usual approach was to rely on supplier inputs or smooth over the gaps using averages.

It worked, mostly.

But “mostly” becomes a difficult place to stay when the results are tied to capital decisions and physical design choices. Over time, I started building internal tools to address those gaps more directly. This included extending property data across operating conditions, integrating values over reaction ranges instead of relying on single-point estimates, and replacing ad hoc approximations with more explicit models.

In many cases the difference was small. In some cases it was not. Hydrogen is a good example. Its thermodynamic behavior, especially its heat capacity, can make averaged assumptions noticeably misleading in certain regimes. What looks like a harmless simplification can shift design outcomes in ways that only become visible later.

The goal was never precision for its own sake. It was reducing uncertainty where it mattered.

Working through those cases changed how I approach problems more broadly. It changed how assumptions are treated, how uncertainty is communicated, and how confidence in a result is actually justified.

It also reinforced something important. Standard methods usually exist for good reasons. They encode experience and practicality. At the same time, they also create habits. Part of technical work is knowing when those habits are no longer sufficient for the problem in front of you.

Over time, programming became a natural extension of that mindset. It was less a shift into software and more a continuation of engineering thinking in a different medium. Identify friction, formalize logic, and reduce unnecessary workarounds so that systems become easier to use and easier to trust.

This site started from that same pattern. The unit converter in the Tools section came out of repeated friction working across gas flow definitions, thermodynamic states, and inconsistent unit conventions. It began as a small utility and gradually turned into a broader space to experiment with web development and structured thinking.

Friction as a signal

Friction in workflows, calculations, or communication usually indicates something worth paying attention to. It can point to unclear assumptions, unnecessary complexity, insufficient complexity, or hidden risk.

Addressing it is not only about efficiency. It is about improving the reliability of decisions and reducing avoidable error.

That idea carries across disciplines. In engineering, in programming, anything dealing with systems of interactions, the pattern is similar. Find where systems break down, and reduce the cost of understanding and using them for a defined goal.

The purpose of this space

This blog exists for three reasons.

First, to document technical work and the reasoning behind it, including assumptions, tradeoffs, and decisions that are usually invisible in final outputs. Details that are beyond what can fit in my CV or too nuanced for a general “professional” context (ie social media)

Second, to explore ideas across engineering, programming, economics, systems, and related fields where those boundaries overlap.

Third, to create a space for writing that is slower, more deliberate, and less shaped by external incentives than most platforms allow. I am not particularly interested in constant visibility or self-promotion, and I prefer taking the time to share insights, reflections, mistakes, and ideas in a more considered way.

Some of the work I have done has also involved punctual consulting-style engagements under NDA, where discretion is expected and certain details cannot be shared publicly or included on a CV. In some cases, the most interesting lessons come from these contexts, and can still be discussed in anonymised or modified form as case studies without exposing sensitive information.

Most meaningful work is collective. It builds on shared tools, prior knowledge, and contributions from many people. This space is not about presenting isolated achievements. It is about making parts of that process more explicit.

There is also a practical reason. Writing helps clarify thinking. It forces structure onto ideas that are often messy in real work. Being wrong in public is also a useful way to refine understanding and improve how ideas are expressed.

What to expect

If you find your way here, expect a mix of:

• Technical deep dives into projects, including assumptions and tradeoffs
• Cross-disciplinary exploration across engineering, programming, and adjacent fields
• Reflections on problem-solving, systems, and learning in practice

My background is in chemical engineering, but my interests are broader than any single discipline. Some of the most interesting work I have done has come through consulting-style or project-based work, where problems are ambiguous, timelines are short, and clarity matters as much as correctness.

That is the kind of work I am drawn to.

I do not know exactly what this space will become. I do know that the standard for what gets published here will stay high, even if the cadence is slow.

If you are here, I hope you find something useful or at least something worth thinking about.

Cheers.