The Tin Shop

About this archive

Over a decade of mechanical engineering, and why I write it all down.

I am a mechanical engineer, and since 2014 I have been writing one plain-language explanation at a time of whatever piece of engineering or physics I happened to be wrestling with that month, pitched at the level I actually understood it that year rather than the level I understand it now. There are several hundred of them by this point, covering structures, fluids, thermal, mechanisms, manufacturing, tolerance and reliability, and read end to end they amount to a record of somebody getting steadily less wrong about how things work.

I keep it going because writing something down plainly is the cheapest test I know for whether it has genuinely gone in, and because it is very easy to spend a year extremely busy and finish it having learned nothing you could hand to somebody else. If I can take a thing I used at work that week and explain it to a reader with no engineering training, using an object they have already held in their own hands, then I understood it, and if I cannot then I did not, which is usually something I only find out in the middle of trying to write the explanation.

The failure that set the habit

Early on I sized a pressure housing the way you would size almost anything else, which is to work out the stress, compare it against the material's yield strength, add a sensible margin and move on, and every single number I put into that calculation was correct. The housing failed anyway, at a load comfortably below the one my arithmetic had blessed.

What I had done was reach for the wrong equation entirely, because a hull under external pressure does not wait politely until stress exceeds yield and then crush, it buckles, which is a stability problem rather than a strength problem, and a thin-walled cylinder is perfectly capable of losing stability while the material inside it sits nowhere near being overloaded. Yield strength barely participates in the outcome, whereas wall thickness and radius and stiffness do, and they enter the problem as a cube, which means that the intuition you build up from ordinary strength calculations is not merely imprecise in this situation but actively points you in the wrong direction.

None of that was exotic or hidden, since it sits in every textbook on the subject, and the only real reason I did not know it was that I had never had cause to notice that "will it break" is actually two separate questions with two separate answers, which I then discovered by watching the thing fail in front of me.

I did not want to forget it. Writing it down properly, in language somebody outside the field could follow, was the surest way I could think of to make certain I never had to learn the same lesson twice, and that is more or less how the habit started. A good number of the articles here now carry a section called My key error with this, where I set down what I believed at the time, what I did because of it, what it cost, and what replaced the belief.

Where it started

I started building radio-controlled aircraft as a school student, out of corrugated plastic sheet, expanded polystyrene, thin plywood, and bicycle spokes bent into pushrods because they were straight, stiff and free.

Purpose-made hobby adhesives were not available where I was and cyanoacrylate dissolves polystyrene foam the moment it touches it, so every joint on every airframe I built was two-part epoxy mixed by hand on scrap card with a matchstick, while the shaping was done with a scalpel blade, a fret saw and progressively finer sandpaper. That shortage taught me considerably more than a well-stocked workshop would have, because when your only adhesive has a mix ratio, a working time and a real cure chemistry behind it, you end up learning what curing actually is, why surface preparation decides whether a joint holds, and why glue nearly always lets go at the interface instead of through the middle of itself. When your only structural material is corrugated plastic you also work out on your own that it is stiff along the flutes and floppy across them, which is to say that I had rediscovered anisotropy by bending a sheet two different ways several years before I found out there was a word for it.

Around the aircraft there was a flight simulator joystick built out of a gutted computer mouse, an RFID lock for a bedroom door, an automatic dog feeder, and an early and deeply temperamental 3D printer which turned out to be an excellent physics teacher in its own right, between steppers that lose count, belts with backlash, large flat prints that warp as they cool, and printed parts that come out strong in two directions and weak in the third.

The reason it was aircraft in the first place, rather than any of the other things a curious teenager might have chosen to build, is that I grew up in an Air Force household and spent my childhood surrounded by aeroplanes, by the people who flew them, and by their stories, so the question of how a wing holds an aircraft up was never an abstract one for me. It was the thing the adults around me did for a living, and building models was the closest I could get to it at that age.

What the work has been

At university I joined the Formula Student team, where I worked on chassis design and torsional rigidity alongside the aerodynamics, and where I first had to think about a vehicle as a whole system rather than as a collection of parts that happen to be bolted together, since a change to the aero package loads the chassis differently, a change to the chassis moves the mounting points, and nothing you do in one corner of the car stays in that corner. It was also where a good deal of my curiosity finally found an outlet, because I had followed motor racing closely for years and watching cars generate grip they had no business having is what turned aerodynamics from a school subject into a question I actually wanted answered. I ran CFD for the first time there, learned that a diffuser is a pressure recovery device rather than a vacuum cleaner and that getting the mechanism right in your head changes what you do next in a way that an approximate cartoon of it never will, and I learned to weld, badly at first and then adequately. At the end of it I drove something I had helped design and build, which remains one of the few genuinely uncomplicated feelings I have had in engineering.

I moved to the autonomous underwater vehicle team after that, largely because the Formula Student effort was constrained more by budget and manufacturing access than by ideas, and the underwater work offered a much smaller embodiment with an entirely different set of problems in it. The governing constraint turned out to be one I had never designed against before, since the hull had to land at neutral buoyancy and was therefore sized to hit a density close to that of water rather than to hit a strength target, while still holding real margin across bending, buckling, torsion and shear. Everything interesting followed from that, because once density is the goal then waterproofing, sealing and sheer compactness stop being finishing details and become the design itself, and packing a working vehicle into a volume that also has to weigh a specific amount is a puzzle I enjoyed far more than I expected to.

Somewhere in the same period I took on a consultancy project redesigning gas burners, and specifically the pattern of holes that the flames sit on, which is a deceptively small-sounding problem that turns out to govern how completely the fuel burns and how much of the heat released ever reaches the thing being heated. It was the first time I simulated combustion rather than airflow, running premixed reacting cases where the model has to capture the flame itself, and generating the geometry and meshes for sixty-four variants by script instead of by hand. What mattered was not the solver but the discipline around it, since a statistical design of experiments reached the best configuration in a fraction of the runs a one-factor-at-a-time study would have needed, and validating the result against physical test is what decided whether the model deserved any trust at all. A model nobody has checked against reality is a picture, and I have been unwilling to trust an unvalidated one since.

Graduate school split into two quite different kinds of work. The first was assistive robotics, where I helped run a university lab and where the mechanisms were designed for one specific, named individual instead of for a market, which inverts almost every instinct you develop as an engineer, because the usual defences of a design, that it suits the average user or covers the expected range, stop meaning anything at all when there is exactly one person who has to be able to use the thing. Designing with that person in the room, and watching them use a prototype badly because of a decision I had made carelessly, is a different and much more direct kind of feedback than any specification document provides.

The second was life science automation, and it asked for a precision I had genuinely not worked to before. Pneumatic systems became something I had to understand properly rather than approximately, since a compressible fluid refuses to behave the way the incompressible intuition in your head expects it to, and the tolerances involved in handling small volumes of liquid repeatably meant that fixturing, datum choice and statistical tolerance analysis stopped being academic exercises. It was also the first time I was building something genuinely at the frontier, where the answer was not sitting in a handbook waiting to be looked up and the honest position was that nobody had solved this particular problem yet, which is uncomfortable and considerably more interesting than the alternative.

More recently I have worked on mobile robots that live outdoors, which is the first environment I have designed for that is actively hostile, since mud, vibration, temperature and dust do more design work than any requirements document ever manages. I took a machine from concept through sheet metal, machining and printing all the way to deployment, and built a reconfigurable test platform with adjustable wheelbase, track width and centre of gravity height so that recurring field failures could be chased down by changing one variable at a time on real hardware, on the principle that field failures are almost never the failure you simulated. This was also my first experience of genuine startup velocity, where a decision made in the morning is being cut in metal by the afternoon and the cost of being wrong is measured in days instead of quarters, and my first experience of leading people rather than only parts, which meant working out how knowledge actually moves between teams and how much of what one group knows is sitting in somebody's head rather than in any document anyone else can read.

That last problem is what the most recent work has been about, namely the systems that let a team build the same thing twice: hardware version control running through pull requests and review comments so that every machine in the field is traceable to the exact revision it was built from, along with lab and test infrastructure built from nothing. The engineering highlight of that period was a long reach end effector holding about a millimetre at the tip at a metre of extension, which sounds like a precision problem and is entirely a stiffness problem, because deflection scales with the cube of length and no amount of careful machining will rescue a structure that is simply too slender.

The through line

The same mechanisms keep turning up wearing different clothes, so that a bolt is a stretched spring whether it is holding a wing or a manifold, second moment of area explains a bicycle spoke pushrod and a tube frame chassis and a long reach arm equally well, and buckling both sinks a hull and decides how a slender column gives way, which is the lesson I paid for once and have not had to pay for again.

Writing each idea down plainly, in the year I first met it, is what turned a pile of separate projects into a set of ideas I can actually carry from one to the next. I am not finished being wrong about things, which is the reason this continues.

Website changes

For years, this archive lived as a raw collection of markdown files served through a basic static site generator. I recently rebuilt the entire platform from the ground up, transitioning away from Jekyll.

The primary reason for this migration is that modern Large Language Models (LLMs) have drastically lowered the barrier to building complex, highly optimized frontends. With AI-assisted coding, it is now possible to deploy a bespoke, high-performance UI (like this Next.js platform) without dedicating months to boilerplate web development. This allowed me to finally give these engineering notes the clean, minimalist typography and reading experience they deserve.

If you have feedback on the new design or the archive itself, please reach out to me on LinkedIn.

Somewhere to start

Ten pieces that between them cover most of what this archive is, arranged in the order the work happened rather than in order of importance.