Samo Fortuna · design engineer

Convincing people and machines to do what’s actually required.

I take a vague need, write it up as a spec someone can build from, and check that what comes back, from people or from models, is what was asked for.

The shift

Models write the code now, and someone has to judge it.

A good spec is close to executable these days. Generated code comes fast and is often wrong in ways that only show up later. So most of my time goes into deciding what should be built, finding where it will break, and fixing it when it does.

How I work

Nine things generated code can’t do for itself.

  1. 01

    Problem framing

    Getting from a vague need to a spec precise enough to build from.

  2. 02

    Agreement

    Getting the client and the team to agree on what’s needed, and to put it in writing.

  3. 03

    Saying no

    Every feature is cheap to generate, but it still has to be tested, maintained and understood. So I turn a lot of them down.

  4. 04

    Taste

    Keeping boundaries clean, so the system still makes sense a few thousand generated lines later.

  5. 05

    Verification

    Guessing where code will fail, edge cases included, then checking with tests, review and logs.

  6. 06

    Risk

    Knowing what can go wrong with data, money and people’s safety, and deciding which risks are acceptable.

  7. 07

    Context

    Knowing the domain and the history of a system, which the repo doesn’t hold.

  8. 08

    The physical world

    Models know it only from text. Timing, current and heat problems don’t show up in a code review, and a wrong guess can cost a board revision.

  9. 09

    Ownership

    I answer for what ships, and I fix it when it breaks.

The same thinking, applied to tickets: six rules for writing issues that people and models can work from.

Background

Thirty years of stack, so I don’t take the model’s word for it.

I started with PHP 4 on Solaris and took up serverless on Azure early. I’ve worked at every layer of the stack, so when a model suggests something, I’ve usually built that or the alternative and know where it breaks. My MSc in Management of Software Projects from the Open University is why the business case comes first.

  1. Business

    Requirements, costs, and whether the thing should exist at all. Requirements captured with Volere. Years of working with lawyers and business owners. Documents in LaTeX.

  2. Team

    Leading and managing developers. I saw the value in Netlify CMS, now Decap CMS, and put together the team that maintains it today.

  3. Delivery

    CI/CD on every project. There’s no excuse to run without it. GitHub Actions by preference.

  4. Security

    Treated as a whole. The CIA triad: confidentiality (only the right people read the data), integrity (nobody changes it unnoticed), availability (it’s there when needed). All three are requirements, and Volere has a place for each. A firewall covers a small part of one. With models holding close to root access to everything, you can only manage the risks you can see, so look wide.

Stack

From the cloud down to the circuit board.

  1. Cloud

    Azure since the early serverless days: Functions, Durable Functions, Service Bus, Event Grid, Cosmos DB, Container Apps, App Service, Static Web Apps.

  2. Application

    PHP since 4.x, C# from .NET Framework to today’s .NET, Node.js, TypeScript, Python. Vue 2 and 3, and jQuery before that. Plenty that never went near a cloud, too: ERP and utility apps, console and WinForms.

  3. Data

    Mostly SQL Server, in depth: T-SQL, user-defined types, efficient indexing. Still my first choice; I don’t know a more complete database, and it just works. A lot of MySQL, some PostgreSQL, Redis, search engines.

  4. System

    Unix before Linux, starting on Solaris. Linux administration ever since. Notes on what a system administrator should be doing.

  5. Hardware

    STM32 and ESP32 firmware on ESP-IDF, in C and C++. SystemVerilog on Zynq. Test setups driven over SCPI. PCBs from TangoPCB to KiCad. Over three years on the Noordung Boombox e-bike: regulation, a team from several disciplines, and a production run too small for the hardware world to take seriously. Notes on getting a hardware product through CE.

I don’t use Kubernetes, on purpose. For most small and mid-sized companies it costs more than it gives back.

Toolbox

And the long list.

Languages

  • PHP
  • C#
  • JavaScript
  • TypeScript
  • Python
  • C
  • C++
  • T-SQL
  • SystemVerilog
  • Bash

Web and apps

  • .NET Framework
  • .NET
  • ASP.NET Web Forms
  • ASP.NET MVC
  • ASP.NET Web API
  • ASP.NET Core
  • Node.js
  • Vue 2
  • Vue 3
  • jQuery
  • HTML
  • CSS
  • WinForms
  • Console apps

Integration

  • REST
  • GraphQL
  • SignalR
  • WebSockets
  • OAuth 2
  • OpenID Connect
  • Entra ID
  • Payments
  • E-invoicing
  • Bank integrations

Data

  • SQL Server
  • MySQL
  • PostgreSQL
  • Redis
  • Cosmos DB
  • Table Storage
  • Full-text search

Azure

  • Functions
  • Durable Functions
  • Service Bus
  • Event Grid
  • Queue Storage
  • Container Apps
  • App Service
  • Static Web Apps
  • Application Insights
  • Azure Monitor

Ops and delivery

  • Linux
  • Solaris
  • Docker
  • Docker Compose
  • Nginx
  • Apache
  • Cloudflare Workers
  • Cloudflare DNS
  • Git
  • GitHub Actions

Embedded

  • STM32
  • ESP32
  • ESP-IDF
  • FreeRTOS
  • Bare metal
  • Zynq
  • CAN bus
  • UART
  • SPI
  • I²C
  • Modbus
  • Bluetooth LE
  • MQTT
  • Wi-Fi

Hardware

  • Battery management
  • Motor control
  • KiCad
  • TangoPCB
  • SCPI test setups

Method and docs

  • Volere
  • CIA triad
  • LaTeX
  • Decap CMS
  • Hugo

Contact

Have something vague that needs to become real?

Tell me what you’re trying to do, and we’ll work out what it really needs.

Email works too. It’s easy to guess from my name and this domain.