< 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.
Project board showing To Do, In Progress, In Review, and Done columns
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.
Confluence engineering portfolio page with architecture decision records
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.
GitLab profile showing contribution activity and projects
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.
DEV.to author profile for Doby Baxter
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
My development setup, a Lenovo ThinkPad P15 G2

< 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 />

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 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.