quiet misdreavus miniblog

software ghost trying to make it in the world

Hi! If you’ve made it to this page, then either you’re camping my GitHub repos, or you’re interested in my technical background. If you have an actual job posting you’ll think i’ll be interested in applying to, i can hand you my actual resume with proper names/locations/timeframes/etc on it that actually fits on one page, but this serves as a longer-form spot to host it so i can provide a little more context. I’m not super comfortable making a complete CV/resume totally public information. Consider this a somewhat-less-formal hybrid of those.

I should note: At this time, i’m not looking for a new position. I originally wrote this page to help look for a job, but i’m leaving it up now so that existing links won’t go dark. I feel like it’s still valuable to have a public version of my technical background, even if the “hire me” URL isn’t 100% accurate any more.

If you’re interested and want to reach out, you can email me at (victoria AT quietmisdreavus DOT net).

about me

I’m Victoria! Depending on what internet circles you frequent, you may know me from my work in the Rust community, where i led the Rustdoc Team and the Docs.rs Team. Or, you may know me from my work in the Swift community, where i helped maintain the Swift-DocC documentation tool. I’ve been writing code professionally since 2012, and personally since a little before then. I love to get to the bottom of a system, finding exactly how something ticks so i can fix a bug or find just the right way to add a feature. I love documentation - reading it and writing it! Over the course of my career, i’ve worked in varied enough spaces that i’m not super attached to any one platform or toolkit - i believe there’s a lot of merit to any setup that can get a system running. Instead i like to figure out the capabilities of whatever i’m working with, so i can use it most effectively.

Before i go into my background in detail, here are a few lists of tools i’ve worked with:

history

I grew up in “a moderately-sized city in Texas”. (I’m fairly public about naming it if you’ve followed me on social media long enough.) I’ve been around computers for practically my whole life. There’s an old story in my family that i learned to recognize letters just enough at age 2.5 so that i could find the right floppy disk to play Lemmings.

I didn’t have a strong coding background until around high school, when i discovered that the TI-83 Plus graphing calculator had this weird feature where you could write BASIC on the calculator and it would do things for you. Around the same time i took some “web design” classes, which introduced some JavaScript to mess with the simple web pages we made. (This was the mid 2000’s, so the web is very different now!)

college

I studied Computer Science at “a state school in Texas” for my Bachelor’s degree. The intro classes taught C++ and object-oriented design. (And pointer arithmetic, because that’s kind of necessary at some points in C++.)

Some classes that i took that i think were neat / have helped me out:

I graduated Magna Cum Laude (which at this school meant “GPA at least 3.75 out of 4”) and moved back home for my first job.

job 1: “the VB.NET job”

After graduating, i started working for “a law firm in Texas”, helping them write line-of-business software used internally. These were desktop applications written in VB.NET, connecting to an MS SQL database. There were only a handful of software developers working there, and while the firm had offices all around the state, there were still plenty of other people working out of the office i was in. It was great being able to see and talk to the people who were using the software we were writing - there were moments where some bugfix i had worked on made it out to everyone, and someone would stop me in the hallway and thank me for making their job easier!

Over time i became known as the “special projects” person, because i was the one who was willing to dive into docs and specs and the like. Some of the projects i helped out with were:

job 2: “we can’t really hire for experience with this language that only exists inside the company”

In 2016, i left job #1 and moved to “a suburb of Dallas, Texas” to start the next one. The position was at “a large medical-tech company”, working on a machine that ran medical tests in labs all around the world. The specific area i was brought on for was the maintenance scripts used by the instrument, which were written in a company-internal language that was parsed and executed by the system itself.

Because of the nature of the work - a device that was used to make medical decisions for patients - there was a vastly different process for approving code changes, due to the regulations involved. It didn’t take me long to gain an appreciation of this process - there was also a lot of training material involved that helped to explain it in those terms. Another effect of the position within the team itself was that i was frequently working with people outside of the software team to use the scripts in some new context. It turns out, these maintenance scripts were useful for more than just instrument upkeep, as i would quickly learn.

Much like in job #1, the projects i wound up working on would get more and more specialized, until i was not just “the M&D person” (the scripts were known as “maintenance and diagnostic scripts”, or just “M&Ds”) but also “the one who was willing to go really deep into the system to make things work”. Some standout projects i worked on here were:

rust

Parallel to job #2 was when i got into the Rust community. I’d been interested in Rust for a while, but hadn’t really jumped into learning the language before this. The new surroundings let me focus some extra energy onto getting started. I started writing a Twitter library in 2016 as a learning project.

Over time, i started to hang out in some of the Rust team IRC channels, including the one for the Documentation Team. When i noticed weird things about the docs for egg-mode as i was writing it, i started to ask around about where the documentation tool’s source code was. I was helpfully pointed to rustdoc, and before long i posted my first PR to it. One PR quickly became several, as the change i made could be readily applied to more places. Over time, i got more and more comfortable working with rustdoc, and since i was already in the habit of finding things to update, i started posting more PRs to make bigger and bigger changes.

I was eventually tapped to lead the then-new Rustdoc Team. After a while, when we started supporting Docs.rs in an official capacity, we spun off a separate Docs.rs Team, and i stepped down from leading the Rustdoc Team to lead that instead. I’ve already written the rest of this story (in terms of being a team member in the Rust project) in the posts “on the origin of rustaceans” and “rust ghost, signing off”.

Some of the major things i worked on while working on Rustdoc and Docs.rs were:

I’ve also given several talks about the things i worked on as part of the Rust project, specifically “the dark secrets lurking inside cargo doc”, “Is This Magic!? Ferris Explores Rustc!”, and “The Death and Rebirth of Docs.rs”.

the recurse center

In 2019, my partner convinced me to apply for the Recurse Center so i could focus on my Rust work. I’d heard of RC before, but had hesitated to apply because it would mean moving to New York for three months, and i didn’t have that kind of money to drop everything and move across the country. However, that year RC announced fellowship grants for women and trans and non-binary programmers to come and work on open-source projects during a batch. That combined with my partner’s support got me to apply, and i got accepted! In the fall of 2019, i left job #2, packed up my apartment, and flew to New York to start my batch.

My original goal at RC was to work on the Rust project full-time, and to help teach my batch-mates about Rust while i was there. The plan was, by leaving my job behind and having a dedicated sabbatical to work on open-source, i could get excited about it again. While that did still happen, plans changed when i got to experience the social environment of RC in-person! I really enjoyed getting to know everyone during my batch, and hearing about the kinds of projects they were working on!

Some things that i did specifically at RC included:

hiatus

After finishing my batch at RC in December of 2019, i moved to Denver to live with my partner and started settling in. By now, after a few months away from work, a growing realization had dawned on me: I was terribly burned out. The combination of doubling up job #2 with increasing open-source work, as well as splitting my identity into a kind of double life as i was starting to transition online but not in-person, created an immense drain on my mental resources. RC did help out a bit, but after leaving New York i realized that i needed a break not only from my job, but also from the feeling of being “obligated” to write code. I dedicated the first few months of 2020 to recovering from burnout, and regaining my love for code and documentation.

Over time, i started tinkering on projects, both old and new. A brief summary of my personal projects over this time include:

job 3: “you might have heard of this one”

In 2020, after a year-long hiatus, i wrote everything on this page up to this point and posted it on Twitter. It caught the eye of a manager at Apple, who oversaw a team working on documentation tooling for Swift. I decided to sign up, and joined the team working on what would become Swift-DocC. Since i had gained a fair amount of compiler-development experience working on rustdoc, i was tasked with improving its Swift compiler integration.

It was a lot of fun working on something that took the ideas of a documentation tool and extended them farther than rustdoc did. And since it reached much farther than the “data-visualization” of pure reference documentation, the compiler integration turned out to be one component of a much larger system, which gave its own set of concerns when coordinating with other teammates and components.

When it came time to announce DocC to the world, i got to help record one of its introductory WWDC sessions: Meet DocC documentation in Xcode.

Eventually, Swift-DocC was released to GitHub as open source, and i became one of the main maintainers of some of its lower-level libraries: