Flakt Group
Colchester/Remote
Walk into any office and look up: the ceiling is quietly doing engineering. Chilled beams cool the room, diffusers deliver fresh air, grilles draw stale air away. Behind each one is a decision somebody made — the right product, at the right size, in the right place, cool enough for the heat load, with enough airflow for the people, without being noisy. Building-services engineers make thousands of these selections by leafing through manufacturer datasheets and selection charts. It is skilled work, but repetitive — and easy to get subtly wrong. I spent six months at FläktGroup, a leading manufacturer of this equipment, building a tool that automates the selection. Describe a room — its size, purpose, cooling load and noise limit — and the engine works out what the room needs, sifts the product catalogue, rejects anything that would breach the manufacturer's own rules, and returns a shortlist of valid designs with the reasoning written out: which products, how many, where they go, and why. By the end of the placement it covered fifteen products across the full chilled-beam range plus diffusers, valves and grilles, protected by an automated test suite of thirty-nine checks that run on every change. The placement confirmed what I want to build next: rigorous, transparent software for the physical world.
I was the sole developer on the tool, with a level of ownership unusual for a placement: the architecture, the data model, the test suite and the documentation were all mine to design and defend, steered by my line manager, who set priorities and reviewed the engineering decisions. My contributions ran end to end. I designed a "generic selector" that knows nothing about individual products — each product describes itself, so new ones can be added cheaply and safely, which I proved by growing the catalogue from two products to fifteen. I built the safety layer: an AI assistant makes the final judgement call between valid designs, but only from a shortlist that conventional, checkable code has already validated, and its answer is re-checked line by line before anything is accepted. I also built the honesty layer: the engine records where every number came from, flags anything I could not fully verify against the original datasheets, and tells a human expert exactly which page to check. Finally, I wrote the handover — a documentation pack designed so the next engineer can pick the project up cold, without me in the room. Everything I quote here is verifiable in the project's history and its passing test suite.
The placement drew directly on my degree — software architecture, data structures, and turning informal requirements into precise, testable logic — and stretched them against a real product. I designed a plug-in architecture where the core engine has zero product knowledge; built a rigorous testing discipline, with "golden" regression outputs that lock behaviour byte-for-byte and a quality gate under which one change that improved the average but worsened a single case was measured and deliberately reverted; and learned to integrate modern AI responsibly, giving a language model the judgement calls while deterministic code keeps the final say on validity. The newest skill was data engineering against messy reality: manufacturer datasheets contain chart-read values, gaps and the occasional misprint, and I learned to model them honestly — recording provenance for every number, flagging what could not be verified, and designing the system to warn rather than guess. I also picked up a new domain from scratch: the physics and conventions of building ventilation, from noise criteria to air-throw behaviour.
The deepest lessons were professional, not technical. Working in a company whose numbers carry real liability taught me to value being defensibly right over being fast: I learned to justify every decision in writing, record every assumption, and present work so it can survive review — a discipline I now apply to everything. Communication was the core of my role. As the only software specialist among domain engineers, I learned to speak in two registers: plain language to orient an audience, cited detail to withstand scrutiny — and to explain results in the domain's own terms, so anyone can audit them without reading code. I learned to respect other people's time: arriving at reviews with a concrete recommendation and its reasoning rather than open questions, and packaging requests so experts can act on them in minutes. And I learned to make decisions under uncertainty — judging when data is too thin to model and saying so honestly, rather than papering over the gap. Above all, I learned how automation earns trust: not by claiming authority, but by showing its working and admitting what it does not know.