Hey! That portfolio, or rather the cover letter for it (sort of), is exactly what I'm working on building right now. Lots of stuff on my github, but that's not very well curated. Or my personal CV, but that info hasn't made it to my consulting website yet. Also starting to put together a more project focused portfolio archive here, but it's ALSO not fully fleshed out yet.
I was able to (and so far: still do!) coast without having a full portfolio for a long time, as I was just active on twitter (over many years), so folks following me were pretty aware of the stuff I was doing. I'm sure cohost will end up the same given more time, I've just been busy with client projects for the last months, so haven't been posting as many personal/research projects lately.
I tend to find it easier to be conversational about what I do instead of writing Brand Copy, so I'll dump a little info here, since it'll probably help me write things later. Thanks for asking the right question at the right time, that really does help unblock my mental state :).
I think you've gotten it pretty right in your list! I do almost entirely rust (or gluing rust components to other things) these days, and pretty happy working at anywhere in the stack, down to embedded/kernel things, pretty much up to any point, other than GUIs.
I tend to find myself doing a lot of rapid prototyping and/or bringup things: setting up environments or building/integrating the first couple demos, then helping teams get ramped up so they can start being productive. I have a pretty wide, niche set of skills around there, and it tends to work out pretty well. More often than not, that's on bare metal (or RTOS) embedded environments, though also a fair amount of resource/time/reliability critical userspace stuff as well.
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 are embedded, 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 process that actually works for them. They typically know they should have some kind of docs, 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 "small effort docs/decisions they should document" that end up having pretty huge payoffs in terms of keeping them on the same page, or make it easy for them to communicate to project managers, other tech teams, marketing folks, or investors on what they are (or are not!) doing, what state its in now, and what to expect from it.
The combo of "bringing things up" and "planning things out" is usually when I get brought in pretty early in a project: 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 first (usually to figure out what requirements/capabilities are actually reasonable in practice), then planning out a "good enough for now, to be revised when we know enough to make better informed decisions" architecture and development roadmap that gets refined over the project.
So, in short, I might be a good person to call when you (or one of your teams):
- Needs help building a very specific thing, either very quickly, and/or very reliably, and/or very performantly
- Needs help getting a very weird or very complex (or very complex and weird) thing working or integrated, especially if that thing is hardware
- Needs help getting "unstuck", or is feeling lost, and could use someone to help them step back and figure out what the plan needs to be
- Needs help de-risking a project by proving out technical concepts, or ensuring specific assumptions are true before you start building on them.
