Professional background and personal notes, 2021

February 19, 2021

I've had multi-year careers in engineering, product management, design, and research. With traditional resumes, I'm usually leaving out large portions of my experience to make a cogent narrative. But, I'm not looking for a traditional, single function role. I'm looking for a role that takes advantage of all of my experience. So: select highlights from my career through the lenses of the IAC21 roles.

Technical work

From disruptor, to guide, to explorer.

Disruptor

"My contribution seeks to shake up the status quo, raise awareness, and provoke discussion." Even though I was creating new things, I was just taking (what I saw as) next steps, putting together things that already existed in novel ways. There weren't original theories or frameworks here, but rather contrarianism.

In early 1999, I led a skunkworks project at an ex-IBM consultancy to develop a Palm VII wireless mobile app (a "web clipping app" or "Palm query app," competitive with WML and WAP at the time, analogous to AMP today). I developed the front-end in Palm's subset of HTML 3.2, with another engineer producing the back-end. The news reading app ended up being the first third-party app for the device, and was demonstrated by 3Com at the Palm VII launch event.

In late 1999, after working with a real estate development client and learning of the long render times of architectural design applications and the lack of self-evidence in building information management (BIM) applications, I left to prototype an architectural visualization application that could run in real-time on a desktop PC. Using a 3D renderer from a video game, I stripped out the gameplay, and implemented a virtual tour guide character (analogous to Amazon Sumerian hosts today) to lead a user around an office building, using the renderer's proprietary programming language. New functionality I implemented included leading the user around; waiting for the user to ask for more information and responding with text, voice and animations; gesturing to objects in space; and accurate lip-synching. After presenting the prototype at an industry conference, I founded a startup to develop and promote it as a product and a service. Customers included domestic real estate developers, universities, startups, foreign banks and NASA.

Guide

"My contribution seeks to teach, counsel, and advise, using my gift of well-earned discernment and wisdom." Working for the company I had licensed technology from, to help others never again experience the problems I did.

From 2001 to 2004, based on my experiences using licensed technology for my startup, I built the first developer relations program of its kind in the video game industry: a community of practice, instead of a static documentation library. I was a full stack developer and manager for this project: I researched, evaluated, chose, deployed, and administered both the software platform (an early commercial adoption of wiki software) and server hardware; I implemented the custom front-end in HTML/CSS/JavaScript; I managed a team of developers producing custom plugins and integrations for content creation and search; and I managed and edited a team of developers and artists producing technical documentation and example content. According to public estimates, the program supported over 30 teams, over 60 products, over 3000 end users, and enabled over $21MM of licensing revenue before royalties (with lifetime figures of 5-10× for each). I also proposed, directed the development of, and established the licensing model for a new product vertical for educational, enterprise, and other non-game markets. The developer relations program and non-game licensing model remained virtually unchanged for a decade after my departure.

Explorer

"My contribution seeks to find new territory, further explore or provide more details on old ones." Technical work for technical work's sake had lost interest to me at this point. I needed there to be reasons for doing things, but once there were genuine needs and use cases, I was prepared to be much more involved.

In 2006, working for a telecommunications hardware company, I was tasked with implementing the UI for our new two-factor authentication hardware token, including security features like scrambling the order of digits on the PIN entry keypad. How does one render a unique image of a PIN pad on an embedded microprocessor with only double-digit MHz and mere kilobytes of RAM? After a close reading of various image file specifications, a solution: hand-tuning a JPEG image, and shuffling its pixels (more accurately, macroblocks) in flight to the display, without generating any intermediate artifacts. After proving the solution out in Python, I went on to implement it and the rest of the front-end in C.

In 2013, I developed a fully-automated cross-compilation infrastructure for the JavaScript MESS project, which ported the MESS and MAME vintage computer and arcade emulators to JavaScript using Emscripten. I started by supporting a single machine (the Canon Cat c. 1987) using the project's handmade Makefiles. I then updated the project to support the latest Emscripten version, and began rigorously testing cross-compilation parameters and outputs. With these learnings, I was able to partially automate the creation of custom Makefiles for each machine by parsing the MESS and MAME source code. Finally, I wrote additional tooling to replicate the functionality of an object file linker, in order to fully automate dependency discovery and generation. To ensure the project was able to continue to support this work on their own, all of this work was done in their preferred languages: Makefiles and shell scripts. The Internet Archive launched a public library of three hundred emulated platforms using JSMESS a month later. The custom compilation infrastructure was retired two years later as cross-compilation became natively supported by the upstream MESS/MAME projects.

In 2018, I presented a talk at an industry conference discussing methods for reverse engineering the security of the Near Field Communication (NFC) tags used in various lines of toys. This was the culmination of technical and legal work over multiple years. To understand how the NFC tags were used in the toys, I wrote a Python web application to visualize NFC radio hardware output in a browser. The NFC radio hardware was controlled using pexpect to script its client software, its output was transformed into JSON, and rendered in HTML via JavaScript. To manage access to finite hardware resources, I wrote a web service in Python to check an Amazon SQS message queue, manipulate the NFC radio hardware as directed, and post the results to Amazon S3. As my understanding of the NFC tags matured, I wrote Python command-line applications mimicking the GNU coreutils (ls, cat, file, and cp) to manipulate arbitrary, non-NDEF data on NFC tags. Finally, as part of the talk, I documented the security algorithms, as well as commonplace tools and workflows, all in Python.

Design and research work

From experimenter, to weaver.

It's important to call out that only one of these things I did "for my job." Otherwise, they're all things I did independently. While I did do well-regarded design and research work over the past decade, and I have portfolios for both interaction design and research, this is the work I'm proud of and which informs what comes next for me.

Experimenter

My contribution seeks to innovate, pioneer, and invent. The journey is inherently risky and participants will be expected to help course-correct. After transitioning my career to design, I wanted to better understand how to know if designers — and my own designs — were "good" or not. What models for practice and critique were there?

In late 2009, I conjectured there should be a practice group for UX and interaction designers: a regular workshop where members can practice designing, discussing, critiquing and presenting user experience and interaction design projects. We don’t always get the variety of projects we’d like. Junior designers need practice with unfamiliar design patterns. Senior designers need practice leading groups. Lead designers need practice mentoring. Directors and architects need practice with new interfaces and technologies. When it’s time to move on, we all need a yard stick independent of our employer’s titles or agency’s client list. I committed to hosting them every other week, and in 2010, I held fifteen, free, two-hour design workshops to let user experience designers, interaction designers, interface designers, graphic artists, developers and students practice different aspects of design.

Weaver

My contribution seeks to connect people, places, organizations, ideas, and/or movements. The workshops connected me to community members, but the community itself was fragmented, a city of designers who didn't know each other. What would help that?

In late 2010, I took over AustinUX.org from its original owner and turned it into a cross-meetup community calendar, listing design-related events from groups across the city. I attended countless events, collaborated with meetup organizers, sponsored groups, and worked to coordinate conversations for the benefit of current and future attendees.

In 2011, prompted by a more senior community member, I designed a 27-question survey for Austin’s design community. I asked a mixture of questions I felt would help define the community’s makeup, engagement, and experience. I found the most senior people don’t have time to attend events, the most junior people don’t know what events are happening, and everyone still wants to learn the basics. Local organizations have constant problems with leader burnout, with funding, with finding speakers, with advertising, with technical infrastructure, with awareness within their potential member base, and more. I wrote up my hypotheses and findings, and produced a new baseline survey and feedback form for meetups to use to track their communities better in the future.

In 2012, I conducted the survey again, not to connect the community with itself, but to connect it with its future. The best work on enterprise software won’t help us invent the future. We have to work on important problems — even if we’re not able to work on them all the time. In this second essay, I argued for ways to better support forward-looking design work, and examples of themes which would prove out as relevant for years to come. I did not, however, yet recognize the privilege inherent in some of the arguments I was making.

Later, other connections you'd probably recall:

Something next

I've been a disruptor, and these days it's easy to disrupt for the sake of disruption, without considering the downstream effects. I've been a guide, but one has to want to sit in the same space for a long period of time, and at some point I've imparted all I have to impart, as accessible as I'm able. I've been an explorer, but going deep on a single thing doesn't often have a large enough impact radius. I've been an experimenter, but needing to bring participants along is something I wasn't prepared for at the time. I've been a weaver, but connecting others has sometimes come at the expense of my self.

I'm a bit too pragmatic to be a healer; I'm a good storyteller but I don't like using narrative alone to convince people; and I think the lionizing of visionaries we do as a society can keep us from doing the work to support discovering and enabling the visions we are all capable of imagining.

Bridge builder

My contribution seeks to develop and implement ideas, practices, people, or resources in service of a collective vision. Being a bridge builder might let me do the work of exploration without having too narrow a focus, the work of experimentation without needing to bring participants along myself. I can hold pieces of the vision or tell parts of the story without having to do the whole thing.

I want to build bridges using the breadth of my skills: not just engineering, not just design, not just research, not just management, but being able to work cross-functionally across these roles and holistically build something. "Wouldn't it be neat if" ideation followed by "yes, and" discussing it with users and co-designing variations with them, testing a technical prototype with them, and building out a business case for it, to be adopted by a production team.

Personally, I think there's a vision worth pursuing at the intersection of:

Any work that lets me explore parts of that and share findings more broadly would be of interest to me.

— Vitorio Miliano