It's been 18-months since I've switched to Linux as a daily development workstation. What started as a memorial weekend deep-dive turned into a daily affirmation of customization and progression of my tools. I've since shifted my Linux usage from "my work computer" to my "everything computer, even for games". Specifically I've learned to love the Arch flavor of Linux for it's minimalism and build-it-how-you-like ethos to Desktops. I've learned more about computers over these past two years then at any point in my life save for those early days as a kid with a PS1. Linux has given me a real understanding of how computer systems work and has made me appreciate open source more than I ever did. That said, as a designer it's often hard for me to find the right place to pitch in and help. This video series serves as me doing something small, and just teaching others what I know. I wanted a linear series that explained everything involved in setting up your own Desktop, and was aimed at beginners who might be migrating over from OSX.
Unfortunately I haven't had much time to game lately, but over the Summer I built out a sunken table for Tabletop games. Over the years I'd gotten used to the digital frills of Tabletop Simulator for setting up my games during Covid, but I wanted to get back to playing in person. I'd seen some YouTube videos that showed elaborate setups where TVs were placed inside tables so you could pipe your maps onto a digital service. I slightly changed the model by allowing my inner TV frame to be removable so the surface you still be used as a regular board game surface if needed. Rather than construct a table base I opted for a cheap Husky table base for more support and so that the whole table top could raise like a standing desk.
My backyard butts up against a fairly large nature preserve. Over this past winter an usually wet, heavy snow caused many of the trees to come down. New to having a real backyard since moving from California I bought a small pole saw and started the weekly work of cleaning things up. I ended up with near a chord of firewood by the end. The problem of course now was that I don't actually have a fireplace. I did have a fairly large yard and a wet-enough climate that an outdoor fire-pit was plausible. I followed a couple (link and link) smokeless fire pit builds on YouTube and adapted things to the material I had on hand. It worked out pretty well and only took a day to build out. Most of the work was in digging out the space. The smokeless bit works OK. I think you really need to have a rager to make it work in a pit of this size.
There is a common trope told to new managers that they should focus exclusively on people management and project definition, leaving the raw work of creation to the individual contributors. The basic thesis is one of dedicated roles, with the manager archetype focusing their time towards enablement, communication, and expectation. This is good thinking and an absolute true statement — don't discount the advice — but the idea of exclusivity in job definition is at best arbitrarily strict, and at worst will create artificial "classes" of work that bring about friction. Like most office dogma, the origin of these mantras spawn more from insecurity than wisdom.
This starts young with
telling kids they can't be good at multiple things. "You need to focus."
or "You can't do everything well" was advice presented to me from
teachers as early as second grade. Well-meaning suggestions from good
people who saw potential in a scattered kid that hopped from sport to
books to computers to art. Luckily this poster of Bo Jackson
adorned my wall to question that thinking. The "Bo knows" influence on
my childhood recently returned to mind while watching his 30 for 30 documentary.
Most of the film focused on his early, multi-sport career. A gifted
athlete, he remains the only All-Star in both Baseball and Football. The
segment that clicked for me was seeing Bo in a shop fletch arrows for
his archery hobbies. My witness was that of a quiet dude who enjoyed
acquiring deep skill, regardless of the subject.
Folks that drink too much from the cup of specialization believe there is no journey to "ten-thousand hours" if we "spread ourselves too thin". Cautious allegories of this kind are abundant, so much so that the most famous one: "a jack of all trades is a master of none" usually leaves out the complimentary second stanza "though oftentimes better than a master of one". We've landed towards a customary "generalist" titling that's morphed into a polite dysphemism.
this modern idea of absolute specialization can get especially
dangerous is when it feeds natural insecurities in people and prevents
them from expanding their horizons. "Should designers code?" is the most
tired example I run across. The answer to any of these questions is
yes. "Should designers become better writers?", "Should designers learn
more about research?". "Should they learn sales?". Yes. Yes. Yes. Always
yes. Answering or expecting no speaks more to insecurities about your
skills than to practical advice. Take on as much you can, shrug off the
bits you aren't interested in, and cast a wide net.
In the strange job soup of tech we've taken this type of backwards thinking to the next level, coining the term "Unicorn" to describe our multi-talented individuals. Let's call them a name and pretend they can not exist! They must be a freak anomaly, not people driven by curiosity and craft. An even bigger lie: let's assume these types of people can only exist in high-profile roles. I've got news for you, I've run into more multi-talented autodidacts in commit histories than meeting rooms. Look no farther than those open-source heroes not just building a library, but somehow balancing the community and their vision as they add to it. The Internet is a river awash with such talent, and you need only look outside your office to see it. Do not contain yourself arbitrarily because of something you read in a blog, including this one.
So, should managers code, design, and in other ways contribute in some way to production code or design? Sure, I don't see any reason they can't. Just understand the boundaries and stay out of other people's way. Having managers that understand the details cuts down on communication time and presentation theater. It's a lot easier to present to a manager that understands what you're talking about than to one that's merely trusting that you do. Better still is one that both believes and understands. They can speak in earnest of your craft and be a true advocate.
Lastly, don't forget that the reverse statement should
also hold true. Individual contributors can sit in the drivers seat and
provide definition. Think always in terms of ownership rather than
reporting lines. I like Elastic's approach. They elevate high-talent
contributors to "Tech leads" or "Design Leads" rather than "Team Leads".
The idea is that you don't need to run a team to be influential. Not
giving folks that opportunity for leadership when they aren't managers
is a disservice to their progression and limits career options. Assume
anyone you work with has the potential to be exceptional. Give them
chances to step up.
For everyone else in management. My
advice? Learn how to run your company's main branch. Pull it down
weekly. Branch it constantly, even if you don't push your code. Do the
same with your skills and you'll be fine wherever you land. Be humble.
Recognize you can't learn everything, but you can always teach the
little you do know.
My children are getting old enough they have need for their own desk space now. I went ahead and built slightly smaller versions of the standing desk I built for myself several years ago. These use the same Jarvis base, which are rock solid frames to build around. The tops are in red oak, sourced from the local lumber provider here in Annapolis. Three coats of Danish oil and then a couple clear poly layers to make it a little more resistant to spills and such.
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.
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.
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.
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.
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.