Samo Fortuna · design engineer
Convincing people and machines to do what’s actually required.
I turn vague needs into precise specs, and make sure that what gets built, by people or by models, is what was meant.
The shift
The edge has moved from producing code to judging it.
A good spec is now nearly executable. Code is cheap to generate and just as cheap to get wrong, so the bottleneck is no longer how fast it gets written. It’s deciding what to build, seeing where it will break, and standing behind it once it ships.
How I work
Six things generated code can’t do for itself.
-
01
Problem framing
Turning a vague need into a precise spec. A good spec is now nearly executable.
-
02
Taste
What to build and what not to. Clean boundaries, and a system that stays coherent as code piles up.
-
03
Verification
Knowing where code will fail, edge cases included, and proving it with tests, review and observability.
-
04
Context
Domain knowledge and system history that can’t be inferred from the repo.
-
05
Ownership
Accountable for what ships, and able to fix it under pressure.
-
06
Loop speed
How fast you get from spec to generated code to a verified fix. Not how fast you type.
Background
Formerly a software architect. Still the whole stack.
That title used to cover everything from hardware to the business case, and I can still do all of it. With an MSc in management of software projects, the business case sits at the top, not as an afterthought. When generated code reaches every layer, someone has to judge it at every layer.
- BusinessRequirements, economics, the reason it exists
- TeamLeading and managing developers
- CloudDetailed cloud architecture
- ApplicationFull-stack development
- DataDatabase administration, MSSQL
- SystemLinux system management
- HardwareHardware and embedded products
Contact
Have something vague that needs to become real?
Tell me what you’re trying to do, and we’ll work out what’s actually required.
Nabla, Samo Fortuna s.p.