A New Adventure in a Familiar Territory
May 14, 2018
This is one of the strangest things about working remote. On days like this, you wake up like you usually do. You make the same coffee and see the kids off to school. You fire up the computer and check email and your calendar to see what your day is looking like. You might even field a few Slack messages, answer some questions on Skype, and post a few gifs like you always do. But there is no denying it. No matter how normal this routine feels, something has changed. Typically this change is preceded by packing up your office the week before, and today would be all about unpacking and meeting new faces. But instead you're remote. And even though you're starting a new job today, everything feels oddly the same.
Adventure Awaits
So to get it right out, today I started my new role at Microsoft as a Senior Technical Program Manager inside of the Office Shared team! Office Shared team leads the experiences that are to be shared across all of the Office products, which as of recently, includes Fabric React! When I left the Office org last year, Fabric was, despite all of its successes, still a grass roots effort fighting for developer resources. Now there are multiple teams dedicated to the project, and I get the pleasure of helping to drive the product forward.
Familiar Territory
Throughout my entire web development career my only meaningful title change has been from front-end developer to senior front-end developer. This is what I was familiar with, and was the only thing I thought I knew. I built websites. I wrote code to convert static, inaccessible images into a dynamic, accessible pieces of website producing code.
But somewhere along that journey I stumbled across another path. I didn't realize I had veered off course, but there I was starting to become less interested in writing production code, and more interested in the tools and process that empowered developers to write that code. Fortunately I can attach a date to that course deviation.
Off the beaten path
In October of 2014 I created a git repo to capture some of my thoughts on the idea of Front-end Architecture.
I defined Front-end Architecture as:
"... a collection of tools and processes that aims to improve the quality of our front-end code while creating a more efficient and sustainable workflow."
with the following disclaimer stating that:
A Front-end developer's audience is the website user, a Front-end Architect's audience is the developer themselves.
Despite my woeful lack of updates to the repo, it continues to be the top Google result for Front-end Architecture, and the above quotes are even used in the search result's featured snippet. I'd obviously struck a chord.
That repo was the catalyst for a number of speaking opportunities. Those speaking opportunities lead me to write a book about Front-end Architecture and Design Systems. Combined with a successful design system build at RedHat, I somehow landed a job at Microsoft helping to build a next generation design system with TypeScript and React. The next 12 months would see me writing more JavaScript than I had written in my entire career, and I loved it!
Into Unfamiliar Territory
But as time went on I started to feel less comfortable in the role of a Front-end developer, or Design Dev as we were called. We were technically under the design discipline, but had enough engineering experience to understand and document code, or pull together a functional prototype. The problem was that there wasn't a clear career path forward from where I was. Though I loved working in code, and developing for Fabric, it wasn't my role's main responsibility. Eventually I was pulled onto another project where I wasn't writing code, I wasn't architecting solutions, I wasn't doing the things that instilled me with passion.
I knew I needed to better define my career path. I needed to find a role that was responsible for things I was passionate about.
I Knew I Wasn't a Designer
My role was technically that of a designer, but as time when on I grew less and less interested in the actual design, and more interested in the code's ability to produce the design. I didn't want to spend my day writing documentation to help developers find their way around a difficult to navigate system, I wanted to fix the system! I started to wonder if maybe my true calling was to be an engineer.
Maybe I Am an Engineer
I know this is a sore topic for a ton of talented front-end developers out there, but there is a dramatic difference between what we do in HTML, CSS, Sass, SVG, animations, accessibility, or even design systems, and what happens in enterprise level JavaScript applications. I'm not saying you need to have a Computer Science degree to be successful as an engineer, but I am saying that there is a whole other world of abstractions and optimizations that you learn when studying Computer Science that can make the difference between a working application and a scalable, performant, resilient application.
My First Test
Fortunately, my reaction to this realization was to start studying, and to be honest I found it incredibly interesting! At one point I was working through a sample problem a co-worker had given me regarding non-cycling graphs. I creating a working algorithm, sent the code back to him and then did a little self-congratulatory dance. You can probably guess that the moral of this story will be to not perform the dance of joy until you are sure your answer is actually any good.
As it turns out, though my answer was technically correct, it was woefully inefficient. Had I'd known a bit more about graphs, and the multiple ways you can represent them as data (edge list vs adjacency list vs adjacency matrices), I could have improved my code's efficiency from O(n2) to ~ O(n). This was, coincidentally, also the first time that Big O notation made much sense to me, as I could now see how the complexity of each approach could be measured before the code was even written! Check out this Codepen if you'd like to see the final optimized code.
My Second A'ha Moment
The second time I realized that all this Computer Science mumbo jumbo wasn't all hogwash, was when this same co-worker left me a small code challenge late Friday that I picked up and ran with Monday morning. It was a twist on the typical number base conversion, like converting decimal to hexadecimal, but in this case the number was going to be represented by lower case letters of the alphabet. 0 == a, 25 == z and 26 == aa, and so on. I was pretty proud of the quick work I made of the exercise. Converting from one base to another has some tricky math in it, but I tackled it without having to resort to looking up other examples.
The surprise came later that day when my co-worker told me that he had already written an algorithm for this operation over the weekend because he needed it for a css-in-js theming package he was working on.
Wait....what? This wasn't just another pointless Computer Science question to weed out the developers who didn't pay attention during one specific lecture during a sophomore level CS prerequisites?
Nope, this was everyday code that needed to be thought out, written, documented and tested.
Maybe I'm Not an Engineer
With all of this knowledge behind me, I decided to test my mettle and apply for an open engineering position on the newly formed Fabric team. Here's a snapshot of my experience.
- Yes, there were whiteboards involved
- My first exercise was incredibly practical, and was code I could have been asked to write one day
- My second exercise was more theoretical, but required no special CS knowledge. It was tough, but interesting
- I was visibly nervous at times, but am proud of the performance I gave
- They probably would have given me an offer
- It wouldn't have been at a senior level
I enjoy solving problems with code, and I think I could be happy as an engineer, but I wasn't about to take a huge pay cut when I didn't need to. I also have a feeling that my "off the beaten path" mentality would quickly catch up with me and have me looking at the bigger picture yet again. I'd start thinking less about the code that implemented a feature, and more about how easy it was to write that code and how that feature would impact the framework.
Dammit! I'm not an engineer. I'm a Program Manager!
I Guess I'm Someone with the Word Manager in my Title
Throughout this entire experience of self discovery, this is what scared me the most: Can I be the type of person that is excited to doesn't dread having the word "manager" in their title?
I had been obsessing over the title "Advocate" for the past few months, as I felt that it best described the type of work I wanted to do within a design system. I wanted to be the eyes, the ears, and the voice of the design system.
- I wanted keep watch of each developer was using the system, the components they most often consumed, and the documentation they most often referred to.
- I wanted to listen to their concerns, hear their feedback, and strive to make the system better, not just for their sake, but for the sake of all of our users.
- I wanted to start a dialog with our users, helping them get the most out of our system, steering them around common pitfalls, and guiding them towards consistent and sustainable architectural choices.
Then I realized that for some external facing products, this was certainly an Advocate's role. But for other projects, which don't officially have Advocates, the role of eyes, ears and voice falls on the Project Manager.
A new Journey
So here I am starting a new journey, with a title I have never had before. But despite all my trepidation, I have never felt more at home than I do right now. There is still a ton of work to be done in Fabric, and many more major releases to come, but I now have the opportunity to imagine what Fabric can be. After some extensive research, I'll be devising a plan to transform Fabric from a collection of user submitted modules, to a cohesive package of consistent, performant, accessible, and flexible components capable of creating any application, any UI, or scenario imaginable.
In the past, my work in design systems helped me to land a great job. Now my job is to make great a design system. Expect some exciting this to happen in the next several months...and hold me to it! I've got a ton of amazing ideas for inside this organization, and out. And for once I've got the runway, and support to see those ideas come to fruition.