I am a Python engineer with a data-science background. I have shipped production code in industrial real-time systems and now I am building independently in machine learning and quantitative finance.
Python is the language I work in by default. I write in async by preference: most of what I build has a real-time or event-driven dimension where async patterns make the difference. I particularly enjoy Python performance work, where I lean on numba for real-time tasks and reach for C extensions when needed.
When I am part of a team, I have been the engineer colleagues come to with the new or difficult work: the blank-page problems, the ones where the path through is not obvious. I can also carry a technical case out of the engineering room and into a conversation with leadership. I enjoy mentoring engineers and offering my expertise.
Now
Since the summer of 2025 I have been building an independent algorithmic trading platform, written in Python and now roughly 120,000 lines (tracked through localytics, a dashboard tool I built), built to put my own savings to work.
The system talks to three different live brokers (Interactive Brokers, IG, and OANDA) plus a built-in mock exchange. A single layer lets the same strategy code run against any of them, including a paper account or a simulated one, with nothing more than a single setting changed.
The platform is designed to be used with real capital at stake. Reliability therefore has to extend across every layer of the application: the strategies, the execution, and everything in between. A second application runs alongside the main system and watches it. It tracks profit and loss, Sharpe ratio, and drawdown live, with alerts pushed to my phone the moment anything looks wrong.
The piece of work I am focused on next is a machine-learning model that can veto a trading signal before it ever becomes an order.
The way I work has shifted in the past year. When building software, I usually write the specification first and delegate the implementation to an AI coding agent, though I sometimes still write the critical pieces myself. I review every change before it is committed.
I am continuously experimenting with new tooling and adopting what works.
Good design patterns and clean architecture keep a project future-proof and agile, with components that can evolve independently. I use my own Python Clean Architecture Plugin to push that further. I run the plugin alongside the code as I write it. It flags pattern issues and surfaces refinements I would miss from inside the design as the project iterates.
Previously
From October 2019 to August 2024 I was a senior research engineer at Fortress Technology, in a small, close-knit R&D team of about a dozen, made up of software engineers, scientists, and hardware engineers. The head of R&D trusted me with the projects where the design did not yet exist and the path through was not obvious.
The flagship product was the ICON X-ray inspection machine, which is now running on production lines worldwide. I designed and built the Python software inside it. The software keeps pace with a moving production line, rendering the X-ray image in real time, drawing the contamination markers the machine has detected onto it, and streaming everything to the operator's interface.
I designed several of the inner-loop rendering algorithms (the contaminant-marker drawing, the recursive hole-filler, the coverage-grid update) from scratch, because nothing off the shelf fit the frame budget. Work such as this, where the constraint itself shapes the method, is what I find most satisfying, and what I would like to do more of, whether in industry research or academic collaboration.
I also built the second-screen system that sits next to the machine. It is a SvelteKit application that gives the operator a live multi-camera view of the conveyor belt running through the machine.
Beyond the flagship, some of the other projects came from briefs R&D leadership gave me, and others I proposed myself. I made the case for, designed, and built the image-labelling tool: an internal application that pulls imagery from machines deployed in the field and lets people categorise what they are seeing, to gather labelled data as part of the company's broader effort to develop its machine-learning capabilities.
I also built the translation pipeline that keeps Fortress's user interface working in more than forty languages across the company's machines, and a control application for an external client, Knapp, that drives a pill-dispensing machine.
My practice before release, across every project there, was to test every feature, anticipate the edge cases, and verify performance under production conditions.
Before Fortress, between 2014 and 2016, I worked at British Airways on the testing pipeline for ba.com. I shipped Python tooling that hooked the tests up to the live data streams the production site was using, and a small service that kept stubbed test dates fresh as the calendar moved forward, and both were adopted across the testing teams.
Education
I read Economics at the University of Nottingham, graduating with a 2:1, and went on to do a master's in Data Science (with Merit) at City, University of London.
Interests
Away from the code I have a particular interest in philosophy: the philosophy of economics, the philosophy of probability, and ethics.
Contact
The fastest way to reach me is by email at marckendal@gmail.com. For roles, projects, or anything you have read here, I would welcome the conversation. I am on GitHub and LinkedIn too.