Introduction

I'm James, and I like helping people solve problems.

I work almost exclusively in Rust these days (or integrating Rust with other components), and I am pretty happy working anywhere in the stack, down to the embedded/kernel level.

I might be a good person to call when you (or one of your teams) need help:

• Building something very specific, either very quickly, and/or very reliably, and/or very performantly
• De-risking a project by proving out technical concepts, or ensuring specific assumptions are true before you start building on them
• Getting a very weird or very complex (or very complex and weird) thing working or integrated, especially if that thing is hardware
• Getting "unstuck", or is feeling lost, and could use someone to help them step back and figure out what the "big picture" plan needs to be

I work on a contract basis, ranging from two weeks to "until the work is done". I'm based in Berlin, Germany and generally work remotely, though I can travel for on-site workshops, deliveries, or trainings.

Interested in working together? Send me an email and let's chat!

Rapid Prototyping and System Bring-Up

I tend to find myself doing a lot of rapid prototyping and/or bring-up work.

This involves setting up environments or building/integrating the first couple of demos. Sometimes this is to build something to discuss with investors or other development teams, other times it is to build the "base layer" so that other developers can make progress.

I know a little bit about a lot of things, which helps in figuring out how to get systems working for the first time. More often than not, my work in this area is on bare metal (or RTOS) embedded environments, as well as a fair amount of resource/time/reliability critical userspace systems and components.

Digital Communication

I also do a lot of "make computers talk to computers" work, either writing/designing protocols, or observing how they can fail, or doing integration work between lots of different systems.

Sometimes these computers are embedded systems, sometimes they are just two applications or two computers that need to talk to each other. Sometimes this is low level I2C/SPI/UART hardware comms, sometimes its IPC/shared memory/unix sockets comms, sometimes it's TCP/UDP/REST network comms.

Systems Engineering Fundamentals

The other main thing I find myself doing a lot of is helping teams out with "systems engineering fundamentals" - usually I find a lot of teams struggle to set up requirements or processes that actually work for them.

Development teams typically know they should have some kind of documentation, and maybe some kind of architecture document or diagram, but more often than not they either don't have anything like that, or if they do, they don't really find a lot of value in it (or time to do it).

I talk about a lot of this in this post. For these teams, I usually help them find the most important documents to write, and the most important decisions to make that end up having the largest payoffs in keeping teams working together smoothly.

These documents help by making it easy for them to communicate to project managers, other tech teams, marketing folks, or investors on what the teams are (or are not!) doing, what state the project is in now, and what to expect from it.

Project Discovery and Kickoff

When I get brought in early in the project, I can help by combining my skills in "bringing things up" and "planning things out".

I tend to help teams:

• Figure out the scope of what they are trying to do
• Identify the "risky bits" that need to be built/experimented with first:
  • Figure out what requirements are needed
  • Figure out what capabilities are actually reasonable in practice
• Planning out an architecture and development roadmap that is:
  • Good enough for now
  • Flexible for when we know enough to make better informed decisions
  • Something that can be refined over the life of the project

Contact us for a consultation