There's a difference between "What you do" and "What you really do."

An I mentioned earlier, I'm looking for work. Given that I'm not working, and doing the looking only takes half the day, I'm spending the other half of the day diving back into Rust. Those two events came together in a conversation I had today with a "career coach" in an unexpected way.

My career coach loves my elevator pitch:

I have a very broad range of experiences, but what I do comes down to this: using industry standard application servers like Django and Swagger for the back-end and familiar tools like React or Backbone for the front-end, I build user interfaces for complex business process that make them easy to understand and a pleasure to use.

I also talk about other things that I've done, and how much I love mentoring and training, engineering leadership and project planning, and how my skillset includes everything from cloud deployments to writing Sass plug-ins. I don't consider myself a graphic designer, and usually I (or my employer) hires someone to build the initial screen shots, but I can do the CSS on my own, thank you very much.

As I said, I've been diving back into Rust. Straying far from my usual academic fare, I decided to just write a basic application server. I've built an application server from some business process every year since 2008, and prior to that I built out the same application server, the Isilon UI, single-handledly, for eight years. So the "application server" part ought to be easy, right?

Nope.

I'm building a very limited, headless CMS for note-taking. It has some oddities, and it's going to involve parsing (and re-parsing) some markdown, and storing all of that in a database to enable search, web-of-knowledge, and some other niceties about how people take and use notes. That's the business process.

The "application server" part is to put a web-server in front of this thing that makes adding, finding, organizing, and updating your note collection "easy to understand and a pleasure to use." In Python you'd have those as separate libraries glued together with some simple ports & adapter code. In Go or Rust, everything gets compiled together. And it turns out, without having my beloved Swagger or Django compilers behind me to put all that together, doing this by hand has been absurdly hard.

It literally took me all day to get to "hello world." I'm using Warp, which looks functional enough, but Rust is still a language with a lot of rough edges, much more a dirtbike than a comfortable touring motorcycle like Python or C#. Type signatures, asynchronous runtimes with and without threads, and the verbosity of designating request/response features has involved a nearly (but not quite) overwhelming list of new low-level aspects of programming HTTP.

I realized as I was doing this that the business logic is, literally, trivial compared to this. That once this part is off the ground, I'll have a mental framework and textual template for several different projects that I've had in mind for a long time, and all of them have been stymied by this: not knowing how to write an application server's network layer in a systems language.

That's how I figured out what I really do: understand the customer's needs about how their business logic should be presented to users, and then I use the most comfortable tools, the fastest tools, the easiest tools and, frankly, the tools with the best meta-tooling around testing, bundling, containerizing and deploying that presentation, to make it all possible.

Without those tools, I'm struggling. Just a little bit, and it's been fun, but I can't say it's been easy. It hasn't. This is a challenge, and I'm up for it.