< About Doby Baxter Computing />

Doby Baxter Computing is my independent software engineering practice, based in Sheffield and working remotely with clients anywhere. My work is software reliability: finding the quiet failures before your customers do, for fixed prices agreed before any work starts. No account managers and no hand-offs: you work with me directly.

I'm Doby Baxter, a software engineer with 4+ years in Python, developer tooling, scientific software, and AI infrastructure. One rule sits under all of it: software should never fail a person in silence. I build systems that stop invalid states early, explain failures in words a person can act on, and keep the responsibility with the software.

That rule is not a market position. It came from years inside systems that failed me quietly, and it is written down as a standard anyone can use, on the Philosophy page.

Python backend • Developer tooling • Open Source

Scientific software • AI infrastructure • Configuration validation

CI/CD • PyPI • GitLab • OpenTelemetry • Technical documentation

See how I can help → Not technical? Start here, in plain English →

< Where I Work />

Doby Baxter Computing is based at Electric Works, the digital and creative hub opposite Sheffield station. Every engagement is fully remote, so you never need to travel to me.

The Electric Works building in Sheffield: a curved glass front reflecting the sky, the electric works sign on the roof, and a lawn, trees and a bus in front.

Doby, in sunglasses and a black T-shirt, working on his laptop at the table in a bright meeting room at Electric Works, seen from the side.

Doby, in sunglasses and a Marvel Comics T-shirt, sitting on a white office chair in an Electric Works meeting room, with his laptop open on the table behind him.

Doby, in a dark brown jacket, light blue shirt, pink tie and sneakers, standing in an Electric Works meeting room with one hand resting on the table beside his laptop.

Click or tap a photo to see it bigger.

< Business Profile />

Business

Doby Baxter Computing
Independent software engineering

You work with

Doby Baxter (he / him), directly, from the first email to the findings

Based

Sheffield, UK · fully remote, with clients anywhere

Current focus

Fixed-price reliability reviews for small businesses · Odoo custom modules · ESA Pyxel

How I work

Fixed prices agreed before any work starts · a read-only look first · run in line with the UK GDPR

Registered

UK Information Commissioner’s Office, ZC217487

< Professional Endorsement />

"Doby has demonstrated strong technical skills, thoughtful system-level thinking, and a clear focus on usability and maintainability. He played a key role in developing innovative tooling driven by real user and community needs. He is proactive, reliable, and communicates clearly, particularly when working on complex or cross-cutting features."

Mission Payload Senior Software Engineer, European Space Agency

< Skills & Experience />

< Technical Competencies />
AI Engineering	LangGraph • MCP • RAG • ROS2 • Vector Databases • LLM Evaluation • Structured Outputs • Prompt Engineering
Programming	Python • TypeScript • JavaScript • Node.js • Bash
Cloud & Developer Tooling	Azure AI Foundry • Git • GitLab CI/CD • Docker • Linux • PyPI • OpenTelemetry
Architecture & Validation	JSON • YAML • JSON Schema • AJV • Configuration Validation • Deterministic Workflows
Systems & Security	Secure Configuration • Input Validation • Wireshark • Nmap
Scientific Software	Detector Simulation • Technical Writing • Open Source Collaboration
Communication, Enablement & IT Mentoring	Translating technical concepts for non-technical audiences, as an engineer and as an IT mentor • Technical writing • User-facing documentation & learning resources • Developer enablement
PLC (Industrial Automation)	Ignition SCADA (Perspective) • Siemens TIA Portal • CODESYS • Ladder Logic • Motor Control • PLC Simulation & Debugging
Engineering Experience	OpenSPP: Social Protection Platform (Python / Odoo) Contributed data-integrity, upgrade-safety, and state-correctness fixes to an open-source social protection platform recognized as a digital public good, where a wrong value can mis-serve a real person. All three pull requests were merged by the maintainers. My OpenSPP contribution log has a writeup for each pull request. Added a server-side constraint rejecting future birthdates in the beneficiary registry, closing a gap that produced impossible negative ages (`spp_registry`, PR #397, writeup). Made antivirus-scan schedules and retention windows survive platform upgrades, so deployments no longer lose administrator-tuned values (`spp_attachment_av_scan`, PR #479, writeup). Cleared the current-plan flag when a case intervention plan completes, so finished work is no longer reported as active, with a unit test (`spp_case_base`, PR #478, writeup). ESA Pyxel: Scientific Simulation Framework (Python) Contributed validation, simulation, and developer tooling to a scientific detector-simulation framework, improving configuration safety, robustness, and developer clarity. My ESA Pyxel contribution log has a writeup for each merge request. Designed schema-aware validation with `typing.Annotated` to enforce model-level constraints (MR !1141, writeup). Built Pyxel Config Lab to guide YAML configuration and reduce invalid states (shipped in Pyxel 2.14, writeup). Stabilized JSON schema generation against ordering and structural inconsistencies (MR !1167, writeup). Improved error messaging for faster debugging and clearer feedback loops (MR !1093, writeup). Named in the peer-reviewed ESA & ESO paper Pyxel 3.0 as having led development of Pyxel’s new GUI, recorded there as the first application built on Pyxel’s JSON Schema. Published `pyxel-config-core` to PyPI: the same validation core exposed as an MCP server, so LLM-generated configs are checked against a schema pinned to a Pyxel release rather than trusted. Lemmel, F., Affatato, V., Jha, A., Hernandez, E., Prod’homme, T., Serra, B., George, E., and Mansour, M., “Pyxel 3.0: New features and applications for the collaborative instrument simulator,” Proc. SPIE 14157, X-Ray, Optical, and Infrared Detectors for Astronomy XII, 141571I (19 August 2026). doi:10.1117/12.3104656 GitLab Ecosystem: Backend, Frontend & Reliability Targeted contributions to core systems, improving reliability, validation, and usability. My GitLab contribution log has a writeup for each merge request. Hardened JSON handling with `Gitlab::Json.safe_parse` to prevent unsafe parsing (MR !225533, writeup). Added frontend input constraints to prevent invalid states and reduce user-facing errors (MR !222561, writeup). Strengthened GraphQL filtering to enforce correct permission boundaries (MR !222739, writeup). Documented that the Pipelines API’s `branches` and `tags` scopes return only the latest pipeline per ref, so a caller no longer mistakes a filtered list for a complete one (MR !225372, shipped in GitLab 18.10, writeup). Delivered a Terraform Provider feature enabling Kroki (Mermaid) configuration via IaC (MR !3012, writeup).

< Full ESA Pyxel & Project Index />

< Standards & Observability: OpenTelemetry />

Ongoing contribution to OpenTelemetry, the CNCF observability standard, on its GenAI and agentic semantic conventions. It is standards and design work rather than merged code: analysis, friction reports, and collaborative proposals.

Friction log: instrumenting a deterministic workflow layer.
Instrumented my LLM Workflow Router with the OpenTelemetry GenAI semantic conventions and documented where they fit poorly for a content-blind, deterministic enforcement layer that takes part in execution without generating anything.
From friction to a shared proposal.
That friction log became a collaborative proposal in the semantic-conventions discussion, turning a set of concrete gaps into a direction the community could take up together.
Method provenance in agentic authorization.
Contributed analysis to the agentic-authorization discussion on how producer-emitted agent scores can signal when the measurement itself changed, not only when the agent did.

< Full OpenTelemetry notebook & writing />

Get to know my workflow

My workflow keeps every piece of work traceable, from the first planning ticket to the delivered case study, and each stage leaves a visible, verifiable trail. This is what working with me looks like in practice.

This shows how I work, not what I disclose. Client projects stay private: everything shown here is open-source work, public contributions, or anonymized demonstrations, never confidential client material.

Plan

Work is broken into tracked tickets on my board, moving through To Do, In Progress, In Review, and Done. Every task maps to an epic and a clear outcome, so progress is always transparent.

Project board showing To Do, In Progress, In Review, and Done columns

Decide

Significant technical choices are recorded as Architecture Decision Records, kept in Confluence and published on my Decision records page, including the alternatives I considered and the trade-offs behind each call. Clients can see the reasoning, not just the result.

Confluence engineering portfolio page with architecture decision records

Build

Implementation lives in GitLab: source code, merge requests, and CI runs. Testing and validation are part of building, not a step afterward, and CI enforces them on every change, leaving a clear history of what changed and why.

Explain

I write up the deeper technical story and the lessons learned as public articles on DEV.to, so the thinking behind the work is open and easy to follow.

Deliver

Finally, the polished case study version lands here on my site, ready for clients to review in one place.

Need help? Take the workflow with you

Download this workflow as a free sheet and use it on your own projects. It covers the five stages above, the loop I use to prototype with AI, and the validation checks I run before I call anything done.

Download the free workflow sheet (PDF)

The setup behind the work

Lenovo ThinkPad P15 Gen 2 Xeon W-11855M RTX A3000

My development setup, a Lenovo ThinkPad P15 G2

< How I think about building />

Six musts a system needs to be fit for purpose, whether it is a client's pipeline, an open-source tool, or a public service I depend on. The shortest of them: failing is allowed, failing quietly is not.

< The standard in full, and where it came from />

< A Note on Perseverance />

This is where the standard comes from. Every one of the six musts I hold a system to, set out on the Philosophy page, is a failure I met from the other side first.

A small rover continuing alone across a dusty, wind-worn landscape

I am disabled and neurodivergent, and my path through education and work has been shaped far more by the absence of accommodation than by any lack of ability.
I left university because the environment was not built for the way I learn and recover, and the same pattern followed into work: burnout, health flare-ups, and inaccessible spaces made stability hard, even when the technical work was never the problem.
At one point, severe burnout left me unable to work for nearly two years. That experience reshaped how I think about systems, sustainability, and what meaningful support actually looks like.
This is why I care so much about validation, maintainability, and developer experience. Clearer systems, better tooling, and predictable workflows are forms of accessibility: they reduce friction and make participation possible. That conviction is now written down as six musts: No Silent Failure.
So I keep going on my own timeline. A rover on Mars does not stop because the terrain is hostile; it was built for hostile ground. It keeps moving and doing the work, whether or not anyone is watching. Through every closed door, I never stopped building.
I have always been capable. I have not always been allowed to participate.
Like that rover, arrival has never automatically created belonging. For me, belonging comes through curiosity, imagination, and building the structures that help people, including the ones the system was never designed for, move forward, together.