Understanding Engineers as a Designer

I've spent most of my career in pursuit of the love of Engineers. The reason is fairly simple to grok: you can build a product without a Designer, but you can't without an Engineer. Solo startups are myopic in this revelation. Every time I've built something, I was working with a partner by necessity and no matter how much I thought I led the vision, my partner Engineer(s) always owned the output. In a sense that meant they were always my boss to be convinced. One of many contradictions you'll find is that many Engineers don't actually want to be a public boss, but very much do want to be the secret one. Accept this and lean into it. Like any good marriage, the Engineer-Designer bond is a fragile one built on trust and transparency.

Another trait you'll learn quickly about great Engineers is that most of them have near-perfect memories. This makes sense and is likely a reason I've struggled when moving beyond the template layer as a Designer. I don't have the logical processing power to keep nested functions, recursion and object oriented patterns in my head. The level of attention it requires is mountainous, and you'll understand why most engineers eschew meetings and want to be left alone to their craft. Distractions are not minutes from conversation lost, but hours of their previous concentration dropped that must be rebuilt anew. If you wish to be loved by engineers remember this golden rule: value their time and stick to schedules if you can.

The core craft of Engineering is tool building, not tool usage, which is our domain. Engineers are concerned with removing repetition and optimize towards flexibility of a documented system. This is the reason they love Frameworks and rally around standards. The reason such standards are hot topics for them is these decisions dictate their day to day and future work. We don't have anything like this in Design and instead talk in term of "trends". Trends are temporary, standards are not.

A common stereotype that exists outside of Engineering is that Engineers focus too much on details. Usually I've found this only a half-truth. They enjoy the details near the trunk of the tree, but tend to dislike the details near its branches. The branches you can't optimize, because the surface area is too large and unique. For most Engineers the detail work along that surface is not very exciting and tends to be filled with tedium. It's why you'll find large Engineering projects tend to slow down near the end — the busywork stage of applying those elegant patterns they created is near. Designers love this part, and it's why we make good QA testers.

Designers also care about deep details, but ours tend to be more individual in scope: a small animation, a rogue but important deviation, and the oft-lionized pixel perfection. Engineers generally don't care about pixel-perfection — it's a perfunctory step that can be completed near the end. After all, the tool works regardless, and we might as well get feedback early. Both frames of reference are correct of course, but understanding the differing points of view hints at where you should spend your time with Engineers. Start early. Try to be explicit about the core experience during definition because you will very rarely have the buddy capital to change it later. Even then, if you can advocate for a late change, it'll likely come in the form of a new version of the first attempt, rather than an adjustment of the original one. This is terribly expensive and why I tell designers to try to provide two designs when possible: the skateboard and the car. Engineers need to know about both even if they only deliver one.

In my experience Engineers love Designers who can code a little, but Designers don't appreciate the reverse. This gets back to the tree metaphor. Designers will never code near the trunk (we only understand it vaguely), but Engineers will always need to design in the branches because that's all Design has. Designers that can code usually don't break things too much, their work is thought superfluous, and their contributions are a welcome way to finish parts of the job that Engineers don't want to work on anyway. If it's done in a PR, even better, and you've suddenly gained some empathy for Engineering work. In contrast, when Engineers fiddle with designs late in the game, they very much can mess up Design's grand plans. Why grand? Design teams often work horizontally, while Engineers run vertically deep into a vein of expertise. These perpendicular aspirations force ideals that are often in combat with each other until you take a few steps back. Step back far enough and you'll find your Product Manager... which well, produces its own art. They own the full scope.

The most effective way to be loved by Engineers though is to work hard at the beginning and the end of the project, leaving them alone in the middle. Provide a checklist of requirements for project completion and let them know what success looks like. This telegraphs when the project can end, which is their main ask. Respect that end and take any learned mistakes from your bad definitions into the next project, not the current one. You'll just piss them off otherwise. Win the war so to speak, build trust.

Engineers greatest worry is feature-creep and project unknowns. This fear is so great that most engineering books are written around spec definition, and why a lot of their culture is focused on Request For Comment (RFC) theater and the naming of things. These documents and early decisions when done well are defensive against us (in a good way) and provide a reference for their rule of law. As a good partner provide a design document along with your actual design as a means of shaping these RFCs, since that's where the project really is defined. Include your checklist of requirements and try to stick to it.

As a Designer the most fun part of the project is near the end. This is when things start to get tedious for Engineering, which is unfortunate timing, but sort of something you'll need to navigate. Good designers are most busy in this period. You'll find the design feels completely different when it's on the page and a slight panic will creep in as you realize your mistakes. Past the early stages of definition, the skills you bring to the table as a Designer are most powerful here near the end. If your relationship with Engineering is healthy they will be happy to humor you with small changes at this critical time, but don't overshoot it and ask for anything too big. They have their own loose ends to tie up, usually this is their time to rewrite code and make it maintainable before it's too late. This comes back to the golden rule: respect their time.

It's no surprise that the majority of my life-long friends are Engineers. They are fun to drink with and tend to be the most voracious hobbyists I know. They take their deep minds into their outside passions and become experts at novel things. I nodded my head learning that many of my wife's Bluegrass friends were Engineers. It made sense. They like the complexity of the music and its focus on standards. My guess is that's why so many of them enjoy Metal as well.

Most Engineers are skeptical optimists and carry their love of optimization towards that optimism. They always think BIG. Mostly I try to listen and learn from them, playing devil's advocate to their theories with a slight impish goading. They seem to enjoy this revolving dance, and every fight is made with a wink. After all, good design acts in support of engineering, not in conflict with it.

Thank you to Andy McCurdy and Sean Coonce for giving feedback on a draft of this essay.


Learn your tools

As a hobby I spend my weekends building small furniture to furnish my house. I started with a toy chest for my children, then quickly moved to tables and more complicated fixtures. Over time I added light electronics to the mix and worked up to arcades, keyboards and button boxes that required some soldering. I learned the basics of how to do this from Steve Ramsey, a woodworker from Marin who works out of his garage on YouTube. He purposefully keeps it simple, constructing projects from cheap lumber and a minimal set of power tools. His peers on YouTube are better artists, and their channels act as a showcase for their expensive shops and output. I enjoy their videos, but look to them for inspiration rather than education. Steve taught me how to use tools, while the others taught me how to appreciate furniture. I'm glad I found his channel first.

My day to day work is as a web designer, or a design engineer, or whatever label we want to give it these days. I found woodworking easy to pick up, and it's a common hobby in our profession. So much so that Elastic had an active woodworking Slack channel before I even got there. The two professions are similar and follow the same methods. Draw something, measure it out, double check your math, and pay attention to the details. You have to be more confident in your choices with woodworking — as they say: "measure twice, cut once" — but otherwise the parallels are pretty obvious. Kerf cuts, or the part of the wood removed by the blade, are something I've needed to account for with box-borders in CSS for decades. In both professions I found repair harder than creation, and it's harder to learn from a finished state than a started one. Since wood isn't as consistent as pixels I've also learned to slow things down. I wish that part of the metaphor was transferable, but slowing things down is why it makes for a good hobby.

What surprised me and probably shouldn't have was how much time I spent on my tools and not the projects themselves. This too was eerily similar. Honing blades, building jigs, and rearranging my garage shop were part of the routine. Like web design I found I enjoyed the tooling as much as core work. I found I left many projects unfinished once I finally figured out how to complete them. Now that I knew how long it would take to finish, that part of the work wasn't as interesting. There are Github repos of mine that served a similar purpose. They were good ways to learn.

As a hobbyist I bought a lot of used tools from local craftsman who were finally making their big upgrade. They were friendly and eager to explain things to an attentive novice who shared their passion. As we'd load the tool onto my truck I noticed they'd pat it one last time and sort of smile first at it, then finally back to me. In these moments I wanted to tell them about when I watched those early Rails videos. It wasn't so much that Rails itself was impressive, but the creator of that video's mastery of TextMate. Instead I'd say thanks and chuckled to myself on the drive home, eager to try out my new toy.

Your projects and jobs will change, but your tools move with you until you decide to adapt, which you should do often. The most efficient coworkers I've known were completely different in their setup, but entirely similar in how deep they'd dived. They all shared the same speed and mastery, took regular inventory, and cleaned out the garage to share what they knew without being pedantic. "Don't do it my way, here are some other tools you might like".  They too are craftsmen.


Good luck San Francisco

This week I packed up my house and put all of my family possessions on a truck for Maryland -- time to head back home. I made it exactly twenty years in California and moving here was one of my best decisions, right next to marrying my lovely wife Nicole. We leave not because we found fault within the state's borders, but because the distance they created from family was too great. It took a global pandemic to make us realize the importance of having family close. I leave saccharine, with an eye over my shoulder.

It's easy to feel nostalgic for my career in the Bay Area. I built three companies in my first ten years here. None of them became profitable while I was running them, but they were popular and smart and scared folks who knew the business side better. I could never figure that part out. The oscillating boom and bust of starting something from scratch was the part I latched to like a tick on a dog. For an over-dramatic, emo kid living in early-oughts chat rooms the realization that my metaphysical tenor could be tied to the daily fitness of work was addictive. I'd check the scales whenever I could. A thousand people came to the site today! A million! The chat died during the stream because we had too many people! Our library is being used where? I was the cliché founder that slept at work, not out of pressure, but because I very genuinely enjoyed the rush so much I couldn't be pulled away. From 2001-2012 I was a part of the launch of eight major brands. In some sort of miracle, in an industry where websites are tissue paper, half of them still exist.

People will tell you not to move to San Francisco. Fuck them. San Francisco is awesome and it will always be the Mecca of tech. There's so much bone in the soil that it springs new flora constantly. In San Francisco I watched friends build billion-dollar companies week by week over beers. I watched other friends found award-winning video-game companies. Some became Internet famous for reasons we all couldn't believe. Still others became core contributors to open source. The more boring of us (of which I count myself) had the terrible misfortune of being hired into extremely successful companies and helping them grow. Our destiny bound not for great individualistic success, but in ordinary team stewardship as grizzled mentors who'd seen some shit and wanted to do things better this time. Each sentence in this paragraph I witnessed multiple times to good people who deserved their success. I don't see them as much, but I still feel warm in memory of their radiance. As anyone who sits down for a drink with me knows I can drown you in such stories.

It's very easy to be cynical about San Francisco, the tech-bro culture, mega-corporations and the conversations about mundane App ideas had aboard dubious private transportation. It's a stereotype for good reason and I won't discount the reasons, since a lot of them are valid. I lived in the genesis of creation and my experiences could have been contrary in that I worked almost exclusively with positive humanists: people with big ideas who started every sentence with "How can we make this better...". Put more succinctly I came to San Francisco in 2004 and mostly met a bunch of nerds who felt a lot like me. In the first decade that could be taken quite literally, as I worked with a lot of awkward, white dudes. In the last decade the landscape became more diverse, but it's clearly a work in progress for everyone involved. Regardless of background most of the people I met shared a similar origin story. San Francisco is a city of transplants after all. None of them fit in wherever they came from and I found myself surrounded by oddballs whose only common thread was their oddness. Quite a few were genuinely brilliant and their glow was evident. On the whole most were honest and good people.

It's that last line I think we take for granted about San Francisco. Laugh all you want about ping-pong tables, bars in the basement and open floor plans; nearly all the tropes of big tech were born out of folks trying to improve the status quo now that the nerds were in charge. Most of us weren't popular in high-school and we all had a bad manager at some point. It is natural to try and change things for the better, sometimes in those moronic ways that only good-meaning people can do, and it's important to consider those failures (without excusing them) through the lens of intent. "How can we make this better..." is a starter for ideas beyond the technology after all. I've watched San Francisco, and tech at large, try to figure these things out for the better part of two decades. There was a lot of arrogance along the way, and there's a good amount of regret to be had, but the battleship inches towards the correct currents all the same.

So I don't know, if you like building things, you should probably move to San Francisco, at least for a bit. I've been told the area is past its prime and rent is getting cheaper. I remember that line or something similar when I moved there originally in 2004. "Dave, you should of been here for the boom". I suspect there will be another one. There always is here. Good luck San Francisco. I hope someone with better ideas fills my spot.


Make a terminal theme with Base 16 - tying it all together

Since my last update I've now fully configured Flavours to manage all the config files in my Linux system. I now can run simply one-liner scripts to trigger styling between my three "Mars Trilogy" themes. This video is mostly a summary and show off of all the systems in play. Moreover I cover the usage of Flavours hook system to reload config files into each program as they change. Lastly I spent some time with basic color theory as it relates to picking good tokens for Base16.


Make a terminal theme with base16 - use Flavours to manage your theme

Part two of my tutorial series on theming terminals. This video walks through Flavours, a command line script to apply and manage base16 files across all your configs. I show how to set up Flavours and set up templates for applications like Alacritty, Rofi and Vim. Once everything is applied, you'll be able to run flavours apply solarized-dark to apply that theme across all your configs.

One bit I didn't learn till after the video is that Flavours allows you to set a hook per configuration. That makes it so you can restart programs like I3wm without having to manually restart them as I did in the video. For the next tutorial I'd like to show off these hooks, working with a fully templated system.

Make a terminal theme with Base16 - introduction

I'd like to make a family of terminal / Linux themes inspired by Kim Stanley Robinson's Red Mars trilogy. There will be three themes, with each having a separate light and dark mode. In total, these six themes should have a similar feel and be interchangeable. We should be able to change the theme using a single script and have those changes cascade through our various theme files.

DnD for Tabletop Simulator: part one

Dungeons and Dragons is one of my primary hobbies. I was mid-campaign DMing a Curse of Strahd campaign when the pandemic hit in March and had to move everything online. Luckily there are more ways than ever to play a game online. My favorite solution though is using Tabletop Simulator to recreate an in person board with physical figurines. I find Tabletop Simulator's janky chaos to fit will with the spirit of DnD's nerd improv sensibilities and though it was initially a bear to learn, I'm now able to set up a new session in under an hour. That's similar to the amount of physical prep I do for our in person sessions and while I still prefer playing around a table with some pizza and beer, this works well enough and has given my friends and I a way to hang out during these weird times.

I plan on making a series of videos under the same theme. This first one is more an introductory to what's possible and why I like the software.

New year's resolution 2021: teach one thing a week

I've always been a big fan of new year's resolutions. The vague life philosophies I've held onto over the years are around self-betterment and auto-didactic learning. Resolutions and big events, even manufactured ones like a new calendar year, are a great way for me to deep dive and focus towards a specific pursuit. As a college drop-out with a chip on his shoulder, I'm constantly fighting an inferiority complex over my skills.

2020's resolution was to get a pilot's license. Due to the pandemic it didn't go as planned. Below is a photo from my introductory flight just over a year ago. I'd flown in simulators for nearly a decade, but this was the first time I actually flew in a small, general aviation plane. I'll admit I don't really have any real need to learn to fly, it was just something challenging that could fit into the before-mentioned self-discovery. My training started off well enough. For two and a half months I went to the airport twice a week, clocking nearly twenty hours into my log book. I also did weekly ground school classes through the local airport. Then in March the pandemic hit and the idea of being in a classroom or a small two-person flying box of shared air sort of killed the dream, if at least temporarily. What I did gain over that brief time was a deep respect for how much commitment and safety goes into flying. I hope when the pandemic settles down I'll find time to redo the resolution and pick it back up. I've had similar failures with resolutions, usually from my own lack of stamina, and fail or succeed I tend to enjoy the journey.

For 2021 I'm thinking a little bit more inwards, since inwards is what I have access to as lockdown continues! I've always felt lucky to grow up with the birth of the Internet, acting as a digital carpenter building tools and websites for others. Almost all those skills were self-learned from the Internet itself. Outside of a couple early books I bought for Flash in the late 90s, I've mostly learned through the written word or video tutorials on a computer of some sort. For 2021 I'd like to give back, flip it around and do a little teaching. My goal is simple: to put up one piece of content a week that teaches some deep skill, no matter how trivial or mundane I think it will be. Outside of my profession as a developer / designer I am a person that has picked up quite a few hobbies over the years - from woodworking to games to basic home repair. These all come with opportunities to share. If you want to follow along, I'll be posting here and on my YouTube channel.

So I'll try and teach what I know, which I mostly learned from others who shared their knowledge in a similar way over the Internet. Hopefully my small contributions to the great Pangea of knowledge will help some folks out. I've seen some decent reactions to videos I uploaded around terminal programs, and my hope is that I can put some of my talents as an extroverted nerd to good use. 


NNN file manager and plugin system (revisited)

It's been roughly a month since I started using NNN as a daily driver for file management. I've found it indispensable in my toolkit and getting into the spirit of open source was happy to provide some PRs to allow their icon system to utilize nerd fonts. The team there saw my first video and asked me to make one that showed off the plugin system in depth. I went ahead and re-shot the video, which  feels a little more complete now that I'm more familiar with the NNN source code. I enjoy the gig of explaining super-nerdy open source programs and might continue making more of them for the community.


The town of Bellhold

Started a new Eberron campaign based on a 3.5 encounter published around 2001. The great thing about DnD is that there is nearly 50 years of writing, both amateur and professional to draw from. I've learned that while I enjoy the "go where the adventure leads" backdrop of a Homebrew setting, I still really enjoy pulling from a playbook as my base. It's easy to change out the main villain and adapt the story to fit your needs, but I like having the skeleton encounter figured out. This makes old modules really attractive, since the core plot is there, and you can just mix and match your story as you go.

Usually these old PDFs are only available in black and white with crude drawings. If it's going to be crude drawings, I may as well make my own! I like to call my aesthetic "13-year old kid before Photoshop". I limit myself to a flat hour, which is hard in watercolors since you have to wait for things to dry. You live with mistakes and move forward.

Spending time on this stuff makes the adventure more personable. It's now a real place, and only my party has ever been there.

I guess that's a waterfall? I don't know.