< DevEx • Scientific Software & AI Tooling />
I'm a software engineer with 4+ years specializing in Python, developer tooling, scientific software, and AI infrastructure. I build reliable systems that reduce invalid states, improve observability, and make complex software easier to understand, maintain, and debug.
I'm interested in backend engineering, developer platforms, scientific software, AI infrastructure, and open-source collaboration. I enjoy building tools that help other engineers work more effectively and make complex systems more predictable.
Python backend • Developer tooling • Open Source
Scientific software • AI infrastructure • Configuration validation
CI/CD • PyPI • GitLab • OpenTelemetry • Technical documentation
Software Engineer • Python Backend Engineer • Scientific Software Engineer • Developer Experience (DevEx) • AI Infrastructure Engineer • Open Source Engineer
< 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
< Professional Profile />
Identity
Doby Baxter
He / Him
Current focus
ESA Pyxel · AI workflow tooling · IT mentoring
| < 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 |
-
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.
- Designed schema-aware validation with
typing.Annotated to enforce model-level constraints.
- Built Pyxel Config Lab to guide YAML configuration and reduce invalid states (shipped in Pyxel 2.14).
- Stabilized JSON schema generation against ordering and structural inconsistencies.
- Improved error messaging for faster debugging and clearer feedback loops.
-
GitLab Ecosystem — Backend, Frontend & Reliability
Targeted contributions to core systems, improving reliability, validation, and usability.
- Hardened JSON handling with
Gitlab::Json.safe_parse to prevent unsafe parsing.
- Added frontend input constraints to prevent invalid states and reduce user-facing errors.
- Strengthened GraphQL filtering to enforce correct permission boundaries.
- Delivered a Terraform Provider feature enabling Kroki (Mermaid) configuration via IaC.
|
< Full ESA Pyxel & Project Index />
Get to know my workflow
I use a repeatable workflow that keeps work traceable from planning through delivery.
From the first planning ticket to the delivered case study, each stage leaves a visible,
verifiable trail across the tools I use. This is what working with me looks like in practice.
This describes how I work, not what I disclose. Client projects stay private and secure.
Everything shown here is open-source work, public contributions, or deliberately anonymized
demonstrations, so no confidential client code, documentation, credentials, tickets, or
proprietary information is ever exposed.
1
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.
2
Decide
Significant technical choices are recorded as Architecture Decision Records in Confluence,
including the alternatives I considered and the trade-offs behind each call. Clients can see
the reasoning, not just the result.
3
Build
Implementation lives in GitLab as real source code, merge requests, and CI runs.
Testing and validation happen here as part of building, not as a separate step afterward,
and CI enforces them on every change. The work is auditable end to end, with a clear
history of what changed and why.
4
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.
5
Deliver
Finally, the polished case study version lands here on my site, ready for clients and
employers to review in one place.
The setup behind the work
- Lenovo ThinkPad P15 Gen 2 Xeon W-11855M RTX A3000
< How I think about building />
A few principles I try to keep in mind when working on tooling,
configuration, and developer-facing systems.
Clarity over cleverness
Code and tooling should be easy to read and understand — for
the next person, and for yourself six months later.
Catch problems early
Good configuration handling and clear error messages make it
much easier to spot mistakes before they become bigger issues.
Predictable behavior
Tools that behave consistently are easier to trust, debug,
and hand off to someone else.
Useful errors
When something goes wrong, the error should tell you what
happened and ideally point you toward fixing it.
< My Soft Skills Journey />
A living constellation of personal growth – from empathy to confidence,
advocacy to connection. Click or hover to expand the details for each
milestone.
< A Note on Perseverance />
-
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 employment:
burnout, health flare-ups, and inaccessible spaces made long-term
stability hard, even when the technical work itself 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.
-
For eighteen months and counting, I have applied across nearly every
route into tech — software, IT, automation, public sector, specialist
disability employers, freelancing — and been met almost entirely with
rejection, silence, or automated filters that close the door before a
human ever sees the work.
-
Every avenue turned out to be locked or empty. In freelancing I never
became visible at all. Programs promised links to employers and had
none. Platforms were saturated far past the point of entry. Even the
support services meant to help kept hitting the same walls I did, rather
than removing them.
-
This is happening in one of the hardest markets software engineers have
ever faced — entry-level hiring has collapsed, and disabled applicants
are quietly screened out first. The barrier has rarely been my
capability. It has been role structure, accommodation, and hiring
channels that were never designed with people like me in mind.
-
This is why I care so much about validation, maintainability, and
developer experience. Clearer systems, better tooling, and predictable
workflows are not just technical improvements — they are forms of
accessibility. They reduce friction and make participation more possible.
-
So I keep going on my own timeline. A rover on Mars does not stop
because the terrain is hostile; being built for hostile ground is the
whole point. It keeps moving, keeps gathering, keeps 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.