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:
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!
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.
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.
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.
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:
OneVariable UG (haftungsbeschränkt)
AG Charlottenburg : HRB 239904 B
CEO (Geschäftsführung): Anthony James Munns