QAnon, Conspiracy Theories, and the Rise of Magical Thinking

Kirby Ferguson, creator of the Everything Is a Remix and This Is Not a Conspiracy Theory video series, has a new video out that attempts to explain the rise of QAnon, conspiracy theories, and magical thinking in America.

Ferguson zeros in on the divide between two different ways people make sense of a complex, chaotic, and uncertain world: evidence seeking and magical thinking. All of us employ both of these techniques to help ease our anxiety about the world, but those who tend towards magical thinking arrive at explanations that are based primarily on instinct, emotion, feelings, and gut reaction while evidence seekers mostly rely on scientific and empirical reasoning.

He also identifies six main aspects of magical thinking:

1. Obsession with symbols and codes (e.g. pizza as a “deep state” code for child trafficking)
2. Dot connecting (e.g. linking 5G with Covid-19)
3. Behind every event is a plan concocted by a person (e.g. Soros and the “deep state” conspiracy)
4. Purity (e.g. the Satanic panic and heavy metal music)
5. Apocalypse is nigh (e.g. the “deep state” again)
6. Preoccupation with good and evil (e.g. liberals are not only wrong but evil)

For me, the key quote about magical thinking is this one for late in the video: “These are not systems of knowledge, and they cannot build solutions. They can only criticize and second-guess.”

Tags: Kirby Ferguson   QAnon   politics   science   video

Tony Wilson’s Three-Way Proposition

Lest we forget, Factory Records impresario Tony Wilson was a digital music pioneer. Marking 13 years ago today since his untimely death, The Guardian profiled Wilson’s ill-fated start-up, Music33. This venture was an online MP3 store, launched three years before the iTunes shop (but, to be fair, a couple of years after eMusic). 

Wilson approached the majors, but they wouldn’t get on board. If you remember, the prominent record labels were, at the time, adamantly opposed to download stores and even more resistant to unbundling songs from their albums, a built-in feature of Music33. “People want to buy songs,” Wilson insisted. He did enlist some cool indie labels like Skam (home to Boards of Canada), Mark Rae’s Grand Central, and Blood and Fire. The latter was a dub/reggae reissue label that I adored and had no idea until today that Simply Red’s Mick Hucknall was partly responsible. 

Music33 didn’t go well, ahead of its time like a lot of Tony Wilson’s endeavors. Download speeds circa 2000 didn’t cooperate, users had to redeem their purchases via passwords, and the management of micro-payments was impossible. Music33 was doomed to fail. 

In just a few years, technology solved all of those problems for Music33’s successors. But there was one idea Wilson had that didn’t carry over to our modern paradigm. From The Guardian piece

Wilson conceived Music33 as an online record store. The price of a song would be split three ways – 11p apiece for the website, for the artist and for their record label. Wilson felt, as he told me in 2000, that “these shits” – the labels – “saying to the artists: ‘You can have so much per cent’ can go screw themselves.”

The three-way split is an intriguing proposition. That arrangement strongly favors the artist as, after recouping, the artist also gets part of that label split — or all of it, if self-released. That’s in addition to a mandatory third of the total proceeds. Of course, the artist would need to be in direct contact with the store to get her 1/3 share which is problematic. But, as we’re dreaming here, imagine that neighboring rights organizations like SoundExchange handle the artist’s portion. That direct relationship for artist payments already exists with SoundExchange, and gathering performers’ royalties from downloads (or streaming) isn’t that far from what the organization already does.

What if Music33 had taken off and set the tone for the structure of download payments, evolving into the standard rates for streaming payouts? With artists guaranteed to receive at least 33% of streaming royalty, today’s landscape would look quite different. 

Update: As I tweeted, songwriters and publishers would still get the short end of the stick in Music33’s alternate timeline.

🔗‘You’ve been smoking too much!’: the chaos of Tony Wilson’s digital music revolution

The post Tony Wilson’s Three-Way Proposition appeared first on 8Sided Blog.

Watch 'Big Gums'

Spending a night up a rare tree.


Bloody nor-wester, hot as heck, gusty and roaring from the centre of Australia. Hairs on my neck raise as I estimate, not for the first time, if the largest gum on my property (Eucalyptus Strzeleckii, declared vulnerable) would hit the house if it was to fall.



Beau Miles sitting in his backyard, contemplating his tree climb, surrounded by ropes.Confined to his backyard, the trail runner and former Human Bean thinks about his next challenge. All photos: Pat Cordon.



Standing on the deck as the wind unfolds I feel the large flat timbers beneath me move, alarmed because it means the house is getting blown about given the deck is tethered to the house, making it feel as if the whole world is moving. It’s all very impressive. I think "gee, that’d be a helluva adventure, spending time in the canopy of those trees during a storm, strapped to a branch to be ragdolled about". Four years later, based on that daft idea, I spent a night in the tree. 



The big gum in Beau's backyard.The big gum in Beau's backyard.


It’s nowhere near as windy when I finally gather up my old climbing kit and various bits of gear from the barn. I’m a dad now, so I choose a fair-weather day and the least perished rope. Up I go using more ladders than I thought I owned, in boots at first, which was a poor choice of shoe. 


This is the story of a man, which is really a story of a unique gumtree, colluding on a backyard adventure... 





Planning the approach.Planning the approach.



A platform to peer out from, while staying home.A platform from which to peer out... while staying in.



Birds-eye Beau view.Birds-eye Beau.





Author Profile



Beau Miles
Beau is a YouTuber, outdoor
type, maker of things, and a
lover of licorice. He is currently
working on a book on

Damian Schenkelman - Principal Engineer at Auth0

August, 2020 blog, twitter, linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I'm a Principal Engineer at Auth0, an Identity as a Service platform. I work in the Systems Architecture group, which today has three Principal Engineers. We work with different teams on strategic initiatives and also shape Auth0's technical strategy, architecture decisions, and guidelines.

At the time of writing, I am working with a group of Identity and Access Management (IAM) teams as a tech lead of a large new product feature, as well as driving reliability and scaling related initiatives with other teams.

What does a “normal” Staff-plus engineer do at your company? Does your role look that way or does it differ?

Within Engineering, we are organized in domains (today Identity & Access Management, Developer Experience, Service Management, and Platform). Auth0's Staff Engineers are people that can technically lead teams within a domain. A Staff Engineer would typically be part of a single team in a domain, while also being able to actively contribute to initiatives across the scope of a domain.

Principal is the next level in our ladder. Principal Engineers can either be in a specific team (depth) or work with multiple teams and their scope spans the entire organization (breadth). Today I am operating in "breadth mode". This means both working on specific initiatives and also the definition of technical strategy, technology choices for our Platform, and leading the Design and Architecture workgroup (a.k.a. DNA).

DNA has 6 members (3 permanent Principal, and 3 Staff/Senior II that rotate every 6 months). The workgroup defines decisions and guidelines to help drive Auth0's technology in a specific direction (e.g. avoid language proliferation so we can build libs once and people can switch teams easily) and also collaborate with teams in technical reviews of large initiatives.

The biggest way in which my role differs, because I have been at the company for 6+ years, 3+ of those as a Director of Engineering, is that I have the "broadest scope". I work with both Product and Platform teams on initiatives and also work often with other parts of the company: joining conversations with high profile prospects, working with our legal team on contract language, or collaborating with Marketing.

How do you spend your time day-to-day?

This varies a lot :). A typical week involves a lot of meetings, so I am trying a new thing: grouping meetings on Mondays, Wednesdays, and Fridays. Thursdays are completely blocked, and Tuesdays are only for urgent matters. Because we are remote all meetings are over Zoom.

On meeting days I have recurrent:

  • 1:1s: to catch up with my manager (VP of Engineering), or a team manager or tech lead. Those conversations are great to stay up to date with them and know their challenges. I feel being too detached from that would impact my ability to get things done effectively.
  • team meetings: Engineering leadership, Design & Architecture workgroup.

Non-recurrent meetings also take place. Some example topics might be:

  • specific initiatives I am tech leading
  • helping a group of teams figure out how to get something started
  • doing a sync design review

On Thursdays (and as much of I can on Tuesdays) I spend my time thinking about:

  • current initiatives and how they are going
  • what we could/should be doing in the future (next quarter, next year)
  • writing docs, guidelines, blog posts
  • (not often) doing POCs and/or writing small tools

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

The biggest impact comes from being able to help achieve "people scale", positively influencing the work of as many people as possible internally. The book Scaling Up Excellence provides an easy to understand analogy: scaling is a ground war, not a one-off airstrike. It requires a lot of time, and patience but to get to your goals you need to align the whole company in terms of goals and how to get to them.

As a Principal Engineer, I try to find opportunities/gaps that I believe will set a direction for as many people as possible in the long term. There's a lot more value to align the ~200 people we have in our Product Delivery organization around a certain topic than to code a solution for a problem myself. The former has more impact, it scales better.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

Before becoming a Principal I was a Director of Engineering at Auth0. The most interesting thing is that as a Principal Engineer people get a lot less defensive when I provide feedback and they seem a lot more open in 1:1s. I think it might be related to the fact that as a Principal Engineer you are not "representing a part of the organization".

In that regard, being an individual contributor feels a lot better.

Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

A common problem for fast-growing companies is that there's usually some "lack of clarity". In our case, there was a lot of confusion about what was coming in the future and that made us slow and inefficient in making technological decisions. Teams were uncertain if they should be using a particular technology because they didn’t know if that technology would be supported in the future, they were uncertain if they should be building a particular product in a certain way because they didn’t know if that approach was aligned with our long-term technical strategy, etc. Naturally, this caused a lot of inefficiencies.

We believed we needed a long-term direction that explained how to approach the technical implementation of problems today and how to bridge the gap between our initial situation and the future vision. More precisely, we needed a documented technical strategy that would detail what we should and shouldn’t be doing to be successful in the long run.

After talking to a great number of people I learned that all of them have been exposed to inconsistent information, and rumors, which made them afraid of making decisions, e.g.: "I heard the company is going for X in the future" or "I heard this particular technology Y is not going to be supported by our platform teams". A lot of confusion was caused by a particular rumor that we were going to support a certain customer need and its technical implications. People kept hearing about it, but concrete plans were never announced. I wrote down these issues, connecting all the dots and aiming to translate that information into knowledge. I realized we needed both short and term ways of solving the problem.

Short term: We had to fill the gap of uncertainty relating to some more urgent and short-term matters. Teams needed to make technical decisions and couldn't wait for a full-fledged technical vision and roadmap. We also realized that once we had that long term vision and decisions, there would naturally be the need to review decisions for specific exceptions. I put together the "design and architecture" (DNA) group, which also wrote guidelines and recommendations, including "approved" technology choices, to guide teams towards independent decisions that don't require review, and also established, and RFC review process.

Long term: I came up with a set of topics that I believed the company needed to make decisions about. I tailored my presentations to suit two different audiences -- executive and technical. For the executive audience, I developed a succinct presentation, applying non-technical analogies and explanations, and providing actionable solutions. The technical presentation was much more detailed and included many technical terms. I used nemawashi (an informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth) and shared with my VP of Engineering, other execs, my peers, and other senior leaders through to get buy-in before formally making a decision. More specifically, I approached people asking them for their thoughts and opinions securing the buy-in, so that by the time we met to discuss our decisions, it wouldn't be the first time they were seeing the ideas. We finally met, discussed tradeoffs, and arrived at a set of decisions. All decisions were documented in a decision log and we committed specific owners -- in writing -- to carry them forward.

How do you keep in touch with how things really work as you spend less time on hands-on development?

There are two aspects of this, keeping up with technology in general and keeping up with what goes on at Auth0 and the current "state of affairs" in Engineering teams.

These are the things I do to keep in touch with things related to Auth0:

  • Internally: keep an ear to the ground both through Slack and having 1:1s with some tech leads and Engineering Managers. This helps me understand what challenges they are having first hand, and also find patterns or arrive at global solutions instead of local ones.
  • Externally: talk with customers/prospects to see how they use the product, read tweets and news, etc.d mentioning Auth0 and the identity space.

I don't feel I am "keeping in touch" as much as I'd like technology-wise, but I do try to :). So many new important new things are happening in our industry every month that it is hard to keep up. Accepting the fact that meetings and not being hands-on means that I will likely be less in touch than I'd like with things is important. Once I accepted that I could start prioritizing what was valuable.

I read books, carve out time to do some POCs or read blogs/papers about specific topics, and ask to lead specific initiatives to stay up to date with how we are developing even if I don't code that often.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

Yes, a lot! I am a member of our Engineering Leadership team. We meet twice a week to discuss topics around the organization. This, together with keeping an ear to the ground, and being part of meetings about mid-term plans helps me know about (and sometimes propose) opportunities that might be available ahead.

Whenever that happens I typically propose the names of people that I believe would benefit from that opportunity, explain why I think they would be good at it, and, if helpful, offer to mentor them in case there are any perceived skill gaps.

You first got the title Principal Engineer at Auth0. Were you hired as a Principal Engineer? If not, what was the process of getting promoted to Principal?

My story here is a particular one. I started at Auth0 in May 2014 as the fifth engineer, ~tenth employee. There were no titles, no ladder, nothing like that. Around 2015, I started mentoring and doing 1:1s with a couple of new hires. Towards the end of 2015, I was working on my initiatives, and also leading others, helping with hiring, etc. Late 2015 Matias Woloski, Auth0's CTO and co-founder, was looking for someone to lead Engineering teams and he asked me if I would be a Director of Engineering.

I've been privileged enough to be able to approach my career in a way that maximizes learning and opportunities for hard problem-solving. That's the main principle that helps me make decisions. When he offered me, a 25 year old living in Argentina, the opportunity to lead the Engineering organization for a "Silicon Valley", remote-first company that was growing exponentially I naturally said "yes". I had never thought "I want to manage", it just happened because I wanted to learn and solve hard problems.

Things worked out great. I learned a lot about building teams, organizations, leading people, etc. Because I was one of the first engineers, had built a lot of the systems and I enjoyed technical conversations I also did a lot of technical leadership in that role, both with Product and Platform/Infrastructure teams. Towards early 2019 as a Director of Platform, I started thinking that I was not learning as fast as before and that I wanted a broader scope than just working on our platform. After many conversations with Christian McCarrick, Auth0's VP of Engineering at the time, I realized that the challenge I wanted to take up next would be being one of Auth0's (a 🦄 by now) technical leaders. I transitioned to Principal Engineer in August 2019.

What two or three factors were most important in you reaching Principal? How have the companies you joined, your location, or your education impacted your path?

A quote I love from Seneca is "Luck is what happens when preparation meets opportunity.". Getting to Principal required getting some things right, but also a lot of luck. I want to call out some of the key factors that got me to Principal and also show how luck played a part in them.

First job

In Argentina it's common to start working while you are in University. When I finished high school I found a job at a fantastic company called Southworks. The two key things about that place were that:

  • the company worked on projects with cutting edge technologies, which gave me lots of opportunities to hone my learning skills
  • the company worked mainly as a Microsoft US vendor remotely, which meant that not only technical skills were valued, but also we got to practice communication, expectation management, and other interpersonal skills often.

The reason I could work in software right out of high school was that when I was 11 I started telling my mom I wanted to "build video games" and my parents found and paid for a high school that taught programming.

How luck played a part: I was about to take a job at another company when a friend of mine from high school told me her brother worked at Southworks and they were looking to hire junior people. He did a good job selling the company to me and I decided to put the other opportunity on hold to see if I could get into Southworks.


I was one of the first engineers at Auth0 and over the years I worked on many parts of its product and infrastructure, which makes it easy for me to help people and provide valuable input on various topics. Being a Director of Engineering also helped me understand many things about our business that help me be a more effective contributor.

How luck played a part: the success of any startup requires a lot of luck at many different points in time. If Auth0 had not grown as it did, I wouldn't have had the opportunities to learn what I did and be where I am. This is particularly important because I live in Argentina where the Software industry is much smaller than it is in the US and most companies don't have dual tracks.

Team sports

I played basketball as a kid and during my teens and I realized early on it felt a lot better to win by scoring any amount of points than to lose scoring lots of points. That shaped how I worked in two ways:

  • it led me to help team members often to see how we could succeed as a team
  • it led me to learn and do things that would be required to "cover gaps", which helped me build leadership and interpersonal skills that are very useful as I grew in my career

There is a popular idea that becoming a Staff Engineer requires completing a “Staff Project.” Did you have a Staff Project, and if so what was it?

I did not. Because of how I grew at Auth0 I kind of "skipped that part". As a Director at a startup, I got the opportunity to technically lead a lot of big, critical initiatives, but there was no specific/explicit "staff/principal project".

I think implicitly the closest thing to a "Staff Project" was the work I led in 2017 & 2018 to increase the reliability and scalability of Auth0, leading some projects to offer higher SLAs for a subset of our key customers.

What piece of advice do you have for someone who has just started as a Staff Engineer?

Staff means different things at different places, so the first piece of advice I would give is to talk to as many people as possible to define expectations where they are.

The next thing I would tell people is to be patient. They probably got to where they are because they are fairly technical and got results, but as you grow in the ladder the outcome of your work takes time to develop. You might be working on more things at once, and the impact of them has a longer time horizon. You are also now influencing more people in different roles, and sometimes it takes them longer to "see" the things that you might see clearly. Being patient, progressively influencing people, and teaching others pays off long term.

Finally: get used to writing things down and repeating them to others. Writing down thoughts, plans, reasoning, and standards is the way you will scale yourself. When you document something you make it easy for anyone to access it and read in the future, it is easier to reference. It is a lot better than "just talking about it": it scales better and it also reduces the chances of things being misunderstood. Repetition is also necessary as just publishing written documents is not useful, so you have to share your ideas with people. Hosting AMAs, brown bags, and other sessions to explain what your thoughts are very valuable.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I wasn't planning for it, but when the opportunity came to be Director I took it. However, my thinking is that there's a pendulum where you can go back and forth between the two paths. How easy it will be will depend on the company and how specialized the skills as a Staff/Principal are, but I think it is possible.

Nowadays I am very interested in continuing to develop my technical skills and leadership skills, as that's what I think will bring the most valuable learnings and challenges.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I try to follow people on Twitter who I think are doing interesting things and from who I can learn. There are so many people doing interesting things and so much to learn! Some of the names that come to mind:

  • Aphyr's work with Jepsen and general content about distributed systems is great.
  • Tanya Reilly has some very good content like RFC process @ Squarespace and Being Glue.
  • David Fowler shares a lot of content about the .NET Framework and ASP.NET internals which I find interesting. There's also this video of him sharing how he became the ASP.NET Architect.
  • At Auth0 I work with Jon Allie who is a fantastic engineer and person. He strives for simplicity, can explain things very clearly, and is extremely humble considering how much he knows.

I haven't found a lot of books or similar content specific to senior "individual contributors" (might be interesting to write one 🤔). I recently read Fundamentals of Software Architecture that does a fairly good job at describing that role while also understanding the nuances and gray areas of it.

Some books about management are useful to get organizational awareness and help with mentoring, 1:1s, hiring which are things one typically helps with as a staff-plus engineer. In High Output Management Andrew Grove refers defines the "know-how manager" as "people who may not supervise anyone directly but who even without strict organizational authority affect and influence the work of others", which sounds an awful lot like staff-plus engineers. I strongly recommend Managing Humans as it shares stories that are easy and fun to read, and also helps generate empathy with managers, which is important as a staff-plus engineer. The 7 habits of highly effective people is also a book that has a lot of good lessons for staff-plus engineers.

Accelerate is another great book that helps tie company success to engineering practices and outcomes in a way that is useful to influence stakeholders, especially at an executive level.

Katie Sylor-Miller - Frontend Architect at Etsy

August, 2020 website, linkedin, twitter

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I work at Etsy, which is the world's leading online marketplace for sellers of handmade goods. We let sellers put their items up for sale and sell them to folks all around the world. We really focus on providing people with unique, special or handmade goods that are an alternative to kind of the facelessness of big box stores.

I'm currently on the Frontend Systems team, which is a product infrastructure team that’s responsible for our frontend architecture - including our PHP view rendering framework, although I'm not super actively participating in the work that the team is doing right now. For the last several months I’ve been focusing on web performance - functioning in an advisory capacity for all things performance - improving our monitoring and reporting systems, identifying areas for improvement, and being available to product teams for help with performance related questions.

Web Performance is something that I think many companies either ignore or don’t focus on. When I started at Etsy, we had a great performance culture thanks to folks like Lara Hogan, but due to organizational changes a few years ago, we no longer had a web performance team, and I think that as an organization, we rested on our laurels and deprioritized web performance. Now, we’re bringing it back to the forefront because there have been a lot of changes in the industry around how “good” performance is defined and measured, particularly for SEO. Google is really pushing for web performance being a criteria that companies focus on as part of their search ranking. So it’s very much a top of mind area, especially for retailers.

What does a “normal” Staff-plus engineer do at your company? Does your role look that way or does it differ?

The interesting thing to me about how we think about the role of a “staff engineer” is that we take two different ways that a person can be senior and we put all of those people into one bucket called staff engineer. But really, there are two different buckets.

Someone can become really senior in their role by being an expert in a particular subject area, by really taking on the role of tech lead, where they are driving their team or org’s technical approach and roadmap. Then there's this other way to be a senior engineer, which are the folks who broaden their scope of work and their focus such that they're thinking about problems that are cross cutting, they're driving the creation of systems and practices that operate across multiple teams. That second bucket is what I think of as an architect. It’s not that you aren't a subject matter expert, but it's just that the scope of influence that you have is greater than operating as a tech lead for a particular team.

At Etsy we have a few levels of seniority: Senior Engineer I and II, then Staff I and II, then Senior Staff which is considered equivalent to a Director level role. I'm technically a Staff Engineer II, and that’s how I think of myself, but my specific role is as the frontend architect. That means instead of being responsible for just what my team is doing, I’m responsible for looking at what all of Etsy is doing in the frontend space. What does the future look like? What are the problems we need to solve? How are we going to get there? I think about all that, and advocate for the technical approaches that will get us there at the company level.

In your role as an architect, do you spend much time doing software development?

Yeah, it's funny. I’m a frontend architect, but by far the main thing I've been writing lately is SQL, because I'm doing a lot of data analysis. I’ve been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it's mostly to help unblock teams or to run small performance-related experiments, or if there is something important that needs to be done but other folks don’t have time for.

I’ve definitely found that I'm moving slower, and it's taking me longer to actually find the dedicated focus time to write code as my calendar fills up with meetings. So I don't think you want me to write much code anymore! I’m much more focused on identifying areas for opportunity and then trying to sell that as work that my team or other teams should be doing.

How do you spend your time day-to-day?

I would say 50% meetings, and the rest of the time it varies pretty widely from day to day. Sometimes I spend the other 50% writing docs, sometimes I'm in SQL doing a lot of data analysis, sometimes I'm in slack talking to people across multiple teams and roles. At times my meeting load will spike a bit as projects come into my lap where I'm reaching out to other teams to learn more about what they're working on, or trying to influence them to make changes. It varies pretty widely.

I’ve found that folks in these roles often struggle to quantify their work, have you found any useful ways to measure your impact?

I'm glad to hear that because it is something that I really, really struggle with. I always have a bunch of different projects and discussions happening at any given time, and I have a bad tendency to get caught up in the newest thing or let my focus wander, so I have to be really thoughtful and cognizant about how I organize my work and my notes. I'm always looking at everything that I could potentially be doing and picking what is the most impactful or the most important thing for me to do that day, and that can be really hard.

I didn't realize, until I moved into the architect role, how much I relied on sprints and JIRA boards and the ritual of completing a ticket and moving it to the “done” column as a way to check in with myself and know that I am accomplishing the things that I need to accomplish. Now that I don’t have that kind of team context to help me organize my day, I've had to rely much more on my own to-do lists and I’m still working to improve my systems for that.

One thing that has definitely been helpful is making sure that I’m keeping track of all of the different tasks I complete every day - logging meetings, emails, slack discussions, etc. Then, when I have my official quarterly goals check-in with my manager, I review all of my notes and realize, wow, I helped engineers fix performance issues on six different experiments, or I influenced this team to take a better direction with their new feature, or I gave that engineer feedback that helped them. These are all little things that in the moment don’t feel like much, but taken together show real impact.

Where do you feel most impactful as a Staff-plus Engineer?

What I absolutely love to do the most is to identify a new or unique problem that hasn’t been tackled before, come up with a wild idea to solve the problem, and then my brilliant coworkers take that idea and really run with it to build something awesome. It starts with taking in a ton of input from the work folks are doing - seeing that this team has a problem doing x, and another team has a problem doing y. Then you mix all that input up with your experience and what’s happening in the industry as a whole and let it sit in your brain for a while, until finally it all clicks and you realize that the deeper cause underlying both problems is z, so you come up with a plan to fix that problem which is really hard to fix.

An example of this process from before I moved into the Architect role was when my team owned our Design System components. Making changes or fixing issues with our shared components was really difficult because we didn't have a single source of truth for the markup and the templates for each component. Rather than everyone in the company reusing the same template file, folks were copying and pasting the HTML into a bunch of different places. So when we had to make changes to a component, it was hard to find all the places to update because the pieces of the component were spread out and managed in different places - sometimes in JavaScript, sometimes in Mustache, sometimes in PHP logic.

So I had this wild idea: what if we extended our custom PHP framework to enable reusable template blocks in mustache that represented all of our components, and we were able to easily compose them together the way that you would in a React application. I went out and made a proof of concept and wrote up a proposal for the project and brought that to the team. Then the team really took the ball and ran with it, they built the infrastructure to support this component system and it turned out far better and more robust than anything I could have done on my own.

The part that I really enjoyed was identifying the problem and thinking creatively about how we can solve it, then shopping the proposal around and getting other people engaged with the work to execute it.

Can people doing frontend work create leverage for a company similarly to folks in developer productivity or infrastructure roles?

Yes, most definitely. I personally only know a handful of other Frontend-specific staff engineers, and I think that frontend as a skillset is not valued in the industry as much as I think that it should be. I'm very lucky that I got my foot in the door at a place like Etsy, which tends to hire “full stack” engineers, by having computer science fundamentals in my background - I went to school for Computer Science, and I have experience working in and understanding the whole stack. But really, my passion and my focus has always been the frontend because it’s what’s in front of your users. I'd love to see more companies value the frontend, because I believe we bring valuable skills and a unique way of thinking to the table.

As far as becoming a staff engineer, I think that the qualities of a good Staff Engineer transcend what stack you're working in. Ultimately, staff engineers need to be able to think about engineering decisions as a series of tradeoffs, and articulating those tradeoffs is a skill that you can have from any perspective within the stack.

I also think that Staff Engineers should have a broad understanding of all of the adjacent fields of work to their own specialty. For me, working in the frontend, I put a lot of time and effort into understanding marketing, business goals, user experience, visual design, the view and business logic layers on the server, how we ship code the browser, how browsers take all that code and turn it into a website, and then how users interact with it. Having expertise in all of these different areas makes it easier for me to see the broader impact of my technical decisions and understand those tradeoffs better.

Having empathy for your users, in particular, is an important skill for all types of engineers to develop, and I think it can be undervalued in many infrastructure or developer support orgs that don’t understand that yes, they actually do have users! I work in Frontend Infrastructure, and we really try to see ourselves as product engineers - it’s just that the products we're building are systems for other engineers to use. So we have customers. We have users. When we think about the API for the systems that we build, we're designing our APIs for users, and we need to understand our users - aka product engineers - to do that well.

So I personally think that frontend-leaning folks make great Staff Engineers, because they're so used to constantly thinking about users and how users are going to interact with what they build. User empathy is a superpower that frontend people bring to the table.

How do you maintain empathy and awareness of the realities of developing at your company when you do less development yourself?

Networking, networking, networking, networking. One-on-ones are particularly important because I'm a full-time remote. Obviously, everyone's remote right now, but as a remote on a not-completely-distributed team, you have to be really cognizant of who you're talking to, and make sure that you have connections across multiple teams and multiple groups to leverage those networks.

At Etsy, we are really lucky that we have a few different Employee Resource Groups for folks to connect across the company. I’m fairly active in the ERG for marginalized gender identities in tech (MAGIC), and it's great because there are folks who are part of that community who work in every single department in engineering. The same is true with the community of remote employees. I make time to mentor more junior folks, have regular 1:1’s, and participate in slack discussions to foster and grow these connections, because it helps so much to have a finger on the pulse of what’s happening broadly in the org. I also try to make sure that I'm talking to engineers throughout product engineering in particular, because product engineers are our customer base.

Something I'm working on getting better about is connecting a lot more with managers. For a long time I've had really good networks inside the Individual Contributor track and I've been working a lot in the last few months on broadening the reach of my network to include more engineering managers. A lot of times the work that I do requires “influence without authority”, I’m not making the decisions myself, but trying to influence the decisions that others are making, and a lot of times, managers are the ones who make the final decisions on things.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

I was very lucky to work with Lara Hogan for a few years at Etsy and she's talked a ton about sponsorship and as a woman in tech I've benefited from and seen the value of sponsorship myself. I definitely put a lot of time and energy into that.

About a year and a half ago, my colleague Andy Yaco-Mink, another Staff Engineer, and I noticed there wasn’t really a good method of communication for product teams to share what they are working on with each other, or to connect with teams working on product infrastructure. To try and fix that, we proposed and started up a monthly meeting that we call the Product Engineering Confab. It’s an open forum for folks to bring up questions, share their work, celebrate wins, and for us folks in infra to share what we’re working on.

Something that I don’t think we fully anticipated is that it's also been a really great way to create opportunities for sponsorship . Every month Andy and I have to figure out what folks are doing that would be interesting to share more broadly. What are experiments that have run that have gotten interesting results? Who’s out there doing cool stuff that should be shared? Then we’ll reach out to engineers on those teams and say, “You should come and talk about what you've been working on at the confab!” It's really easy. It's five minutes. It's super informal, but it's a good way to get public speaking experience.

Since then, we've had a couple of folks who've come and spoken at the meeting, and then went on to speak at company all-hands meetings or local meetups. At least one person ended up giving an expanded version of their talk at a big conference. We’ve also heard from folks that giving a talk at the confab was something they used as evidence of leadership in their promotion packet, which is an amazing feeling!

You first got the title Staff Engineer at your current company. What was the process of getting promoted to Staff?

I was hired as a Senior Engineer because at the time we didn’t hire into the Staff title, although we’ve since changed that policy. I was working in the industry for almost ten years before I joined Etsy, but largely at smaller and lesser known companies. I’d been serving as a frontend tech lead for more than five years before I came to Etsy. Because of that, I was already extremely comfortable in the role of being a mentor and a leader. I’d already spent a lot of time working closely with management, product and design, as well as figuring out roadmaps and execution. Altogether, I felt like I had the tech lead role down pat.

But, when I came to Etsy the scope was much bigger than what I’d seen previously. The engineering department was many magnitudes bigger than any engineering department I’d worked at before. I had a lot to learn about operating at a really big scale and how that’s very different than when you’re at a smaller company. I learned to be more cognizant of looking at data: I had to go out and teach myself basic statistics to understand the experimentation framework.

From the beginning, though, I was always looking around for places we could improve. I came in and said, “Oh hey, we’re not doing this thing. We should be doing this thing.” For example, I noticed that folks had been writing the design system JavaScript components any old way, so I said “Let’s come up with a framework and a standard boilerplate for that.” It was such a small thing and it felt obvious to me, but it was a big improvement in our practices. I think a lot of what gets someone to Staff is noticing problems and acting on solving them proactively, instead of letting them go.

Altogether, I had been at Etsy for a little less than two years when the promotion to Staff came. My manager at the time was brand new and didn’t know my track record, so we worked really closely and collaboratively on putting together my packet. I’ve heard experiences on both ends of the spectrum of manager-driven versus IC-driven, and I’m glad that I ended up being a big part of the promotion process. Especially being a remote, I think that unless you’re proactive a lot of your work can go unnoticed because it happens over Slack, in pull requests or documents, and not out in the open where managers tend to operate. You’re always going to be your best advocate, but that’s even more true as a remote. You have to put a lot of effort into making sure your accomplishments are out there and they’re known.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

I’ve discussed a few things in this vein already: creativity, proactiveness, empathy, etc. Something I haven’t talked about enough is communication and transparency. A big part of being promoted to Staff is making sure that your work is visible, that people know your name and you have a good reputation.

I’m lucky to be on a team that builds frontend infrastructure because we naturally write a lot of emails to everyone in engineering about the work we do, so we get a lot of visibility. But a bigger part of being in infrastructure is customer service - helping folks who come into your Slack channel with questions or issues to be solved. I worked in the service industry for several years before going back to school to finish my degree in computer science, and I always try to model the lessons I learned about customer service from that experience in every interaction I have with folks at work: be available, be humble, and focus on really hearing and understanding people’s needs. When you truly care about helping our colleagues it shows.

Do you think some companies are particularly good at growing Staff engineers?

To be perfectly honest, I don’t really know how Staff engineering works at companies other than Etsy, so I am totally biased! I think Etsy is good at growing Staff Engineers because we have a strong internal culture that values technical excellence combined with a culture of blamelessness and a desire to do good in the larger world. I think that leads to really smart and kind people working at Etsy, and that combination of intelligence and humbleness makes folks great staff engineers. This kind of environment feeds on itself, creating good role models and people who want to emulate those role models in order to get promoted. So I think that on the whole, we have a great cohort of folks who work or have worked at Etsy and model good practices for Staff Engineers.

I think it’s important to remember, though, that there are lots of smaller and less-well-known companies with amazing people who do Staff engineering type work, but aren’t called staff engineers, they’re acknowledged as technical-track leaders in other ways. In many companies people who are strong technical leads become managers, and might not even have the idea of something like a Staff engineer role. It’s easy in a big name company to get stuck on this title of Staff as the end-all be-all, but remember that there are as many different ways of growing your career.

Can you remember any piece of advice on reaching Staff that was particularly helpful for you?

One of the best pieces of advice that someone gave me, and that I make sure to pass on to other staff engineers, is that there's a misconception that you become a Staff Engineer and then you’ll be in control of the work you do, and everyone will listen to you and do what you want them to do. That's absolutely the opposite of what happens! You have this really tangible goal of getting a promotion for so long, and then you become a Staff Engineer, and all of a sudden, everything is vague and ambiguous. You transition from solving somewhat clear-cut problems, to being responsible for finding the right problems, and then figuring out how to convince people that it’s important to solve them. You are going to be challenged in a completely different way than you have been in your career thus far.

What’s your advice to people pursuing a Staff role?

I was nominated for the Staff Engineer promotion twice before I got promoted; the third time was the charm. I think what finally pushed it forward for me was that I had a good sponsor in my Director. So my advice is to make sure that you develop your network and start meeting with your Director or your VP, because those are the people who are in the room making the decision about whether you’re getting promoted or not. It’s not your peers and it’s not really your manager, it’s this other group of people, so you want them to know your name and your work. During that promotion discussion, you want them to think, “Oh, she sent that engineering-wide email about this project.” or “I see him in Slack answering people’s questions all the time.” or “They spoke at that conference, didn’t they?”

When folks, particularly women and non-binary people, come to me for advice, I think they expect me to talk about how to grow as a technical leader, and are surprised when I say “You’ve probably already got the technical chops, what you need to do is work on your reputation at the company.” For better or for worse, you can’t get to Staff without a good reputation. I think people want or expect it to be a meritocracy, when it’s really not. There are so many factors that go into getting a Staff-level role.

Advice for navigating uncertainty and ambiguity that comes with more senior roles?

It’s important to develop a lot of self-knowledge to see when you’re pursuing something because it’s what you want and not because it’s going to be beneficial for the organization. That can be really hard to do. You have to be ready to kill your darlings, pivot, and try something new. If an approach you’re taking doesn’t work, don’t try to force it.

I also really love Dan Na’s talk about pushing through friction, because that’s something you experience constantly when you’re growing as a technical leader. I think about this concept of “influence without authority” a lot, because when you’re a Staff Engineer then your job is to figure out what the team or organization needs to do, align the organization around that goal, and figure out how to get people to do that when you have no authority over staffing or final decision making. It takes a lot of tenacity and you have to flex a whole bunch of quote-unquote non technical skills to push things forward.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

A lot of names that I’ve already said, especially Lara Hogan, Dan Na. I just love everything that Julia Evans does and I am really lucky that I got to collaborate with her on a project. Ryn Daniels who used to work at Etsy blogs a lot on career progression. Tanya Reilly is a big inspiration to me as another badass working Mom who is also a respected technical leader. In the frontend space, Nicole Sullivan, Jen Simmons, and Ethan Marcotte are huge inspirations to me to name just a few. I really enjoyed reading Camille Fournier’s The Manager’s Path. I’ve never done the management track so it was a bit of a black box and anything that gives you insight into the world of management is helpful because as a Staff Engineer you’re almost like a manager without the people aspect.

Staff promotion packets.

This is a draft guide for

Some folks think of their promotion packet as the capstone of reaching a Staff-pus role, but I’ve seen many folks succeed by taking an opposite approach: starting to write their first Staff promotion packet long before they think they’re likely to be promoted to Staff, much the way they might use a brag document. Used this way, your packet becomes the map to accomplishing your goal.

It’s likely your company will have its own format for promotion packets, and eventually you’ll need to translate your packet into that format before it’s submitted to an internal promotion committee or process, but there’s no need to rush it. You’ll spend more time relying on it as a guide than as a formal artifact for official review, so optimize for the former.

For traversing towards your Staff-plus promotion, a general template format that’s useful is:

  • What are your Staff projects? What did you do? What was the project’s impact (including a well-defined goal)? What made this project complex? Keep it very short and then link out to supporting design documents
  • What are the high-leverage ways you’ve improved the organization?
  • Who have you mentored and through what accomplishments?
  • What glue work do you do for the organization? What’s the impact of that glue work?
  • Which teams and leaders are familiar with and advocates for your work? What do they value about your work? One sentence, include data (e.g. survey data) when possible
  • Do you have real or perceived skill or behavior gaps that might hold you back? For each, how would you address the concern? One sentence each

It’s useful to spend some time to write out those answers yourself, but getting promoted into a leadership role isn’t a solo activity – it’s something you can only accomplish with a team of folks supporting you along the way.

The approach that I recommend for iterating on your packet is:

  1. Answer why you’re doing this. Many folks choose not to pursue the Staff level, you should have a reason why this is important to you. If you don’t, you’re liable to find yourself in a role you don’t enjoy.

    Michelle Bu warns, “My first piece of advice to engineers is that they should avoid pattern matching in ways that lead them towards work they don’t enjoy. I’m deeply energized by the work I do, partnering with teams to solve abstract modeling and design problems. It takes a certain amount of fortitude to try again and again after many rounds of feedback, and to be honest, it’s not for everyone. If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want.”

  2. Temper your expectations. Promotions, especially at this level, are built over quarters, halves and years. Avoid the expectation of instant results
  3. Bring your manager into the fold. Bring the promotion packet and to your next 1:1 with your manager, and tell them that attaining a Staff promotion is a goal of yours. Review the empty packet with them, and ask them what’s missing, what to emphasize, and if they’d recommend adding steps to the workflow. You goal is to ensure they know this is something you’re interested in and to solicit their guidance on approach.

    Ritu Vincent suggests, “People frequently come to me and ask, ‘What should I do next to reach Staff?’ One of the things that I tell them is to be super open and honest with your manager about what you want from your career. A mistake I made early on in my one-on-ones was telling my manager what I thought they wanted to hear, instead of what I actually felt.”

  4. Compile the promotion packet. Now write the packet
  5. Edit the promotion packet. Wait two days, reread your promotion packet and edit for content, clarity and context
  6. Edit the promotion packet with peers. Share your promotion packet with several trusted peers to get feedback. Peers are often better at identifying your strengths and contributions than you are, while being closer to your work than your manager might be
  7. Edit the promotion packet with your manager. Share your promotion packet with your manager requesting feedback. Ask for particular focus on enumerating gaps to address. Ask if you can spend time in the following 1:1 discussing the kinds of projects and opportunities to both address gaps and make the packet stronger
  8. Periodically review the promotion packet with your manager. Continue to review the promotion packet with your manager during your career and performance oriented 1:1s. Both you and your manager should use it to steer you towards demonstrating the promotion criteria over time. This is particularly important to do if your direct manager changes. Maintaining this sort of document and reviewing it across managers will help mitigate the loss of progress towards promotion that often occurs after a manager change

If you take a methodical approach to following this advice, then you’ll put together your first Staff promotion packet long before you’re nominated for promotion. From there, you’ll use the packet to focus your attention and your partnership with your manager towards that goal. It won’t necessarily get you there quickly, and it event might not get you there at your current company, but it will consolidate your energy on the development and work that’ll move you towards your goal.

When it finally does comes time to write your formal packet, it’ll be a matter of editing down what you’ve collected into the official template rather than an archival process of dusting through years of effort. Hopefully nothing goes awry in the promotion process, and a Staff title follows.

There Is No Game: Wrong Dimension


We previously covered There Is No Game, when it was a brief tidied up entry to a gamejam. And it was splendid. Now it’s a completely new full game, bearing the same central conceit: it absolutely doesn’t want you to find out that it’s a game. And I cannot under-emphasise at all the scale on which this is utterly brilliant. This is one of the best games I’ve ever played.

I was already immediately won over before I’d even started playing, when in the mix of its demands that I immediately quit (which I had to due to a resolution change issue, and it awarded me a Steam achievement for doing so), ludicrously over-sized Quit button, and imploring of me not to play, it popped up this screen:


What follows is a barrage of ideas, brilliantly delivered, and each and every one spoiled by description. So with apologies, I shall tell you one very brief sequence from the start, during which the game was still trying to keep me out with hefty signs demanding “THERE IS NO GAME” while its narrator berated me for persisting in trying to play:

The T fell off its second heavier attempt at blocking signage, and after I broke a supporting rope it was holding itself up by a large helium balloon. By repeatedly picking up the heavy metal T, it up and dropping it, it wobbled the screen enough to cause a mute button to gradually appear, then fall to the bottom of the screen. Clicking it caused the narrator to stop speaking and let out frustrated “MMPPH MMMMPH!” sounds, until he brought his own cursor on screen to unclick the button. A few back and forths, the narrator increasingly angry, had me snatch his cursor away with mine, and use the pointy arrow to pop the balloon. The sign was down!

Just look at how many great ideas are packed into just that paragraph. And this is minutes in, after the game has already devolved into a momentary Break-Out clone and a game of Rock, Paper, Scissors. And it keeps on coming, all splendidly accompanied by the furious French-accented blustering of the omnipresent invisible narrator. This game is many hours long, and it never slows down, never stops being astonishingly inventive, shifting gears, genres, moods, modes…

And then… argh! Argh! I want to tell you so many other cool things! Like how there ends up being multiple… No! I can’t! Oh this is agony! All the things I could say that would have you respond, “OH MY GOODNESS I’M BUYING THIS RIGHT NOW!” are also things you’d never forgive me for spoiling. Look, I’m going to burst if I don’t give a few of the squillions of examples, so if you trust me, stop reading right now and just buy it. This is straight into contention for my GOTY, and

So suffice it to say this game sorry, not-game, contains lines like, “Things are becoming more and more unusual. It’s even begun raining croissants.” And there’s the best 90s LucasArts spoof I’ve ever seen, and God knows I’ve seen a lot of bad LucasArts spoofs. Seriously, it could have been drawn by Larry Ahern himself it’s so damned perfect.

It then starts spoofing other genres, including one with a boss fight. After I lost it a first time, there was the obligatory return (controlled by the character in the game, not me, because remember, there is no game), the boss started up his spiel again, and perfectly the narrator bellowed “OH SHUT UP, JUST FIGHT!”

I’ve laughed out loud SO many times playing this. It’s a wonderful satire of gaming, while being a wonderful not-a-game in its own right. At one point I genuinely applauded the screen. I’ve also sat with my mouth gaped open in absolute shock at how brilliant some of its ideas are. Oh my goodness, the dollar sign. THE DOLLAR SIGN!

And then it’s capable of so much more than just throwing gags at you. There’s depth here, extraordinary depth. It’s much, much bigger and smarter and carefully thought through than you could ever imagine at the start. This is something utterly exceptional.

This is 2020’s Pony Island, only it dwarfs that extraordinary game in terms of scope and scale. It’s hilarious, inventive, and like nothing else you’ve ever played. This is GOTY material – I find it hard to imagine I’ll play anything else this year that matches it. And yet no one’s heard of it! This has to change. Buy it, play it, and then you won’t be able to help tell everyone you know to do the same. I’ve held back on spoiling so, so much here, and I desperately want to talk about the events in the second half of the game, but I won’t. Just buy this.

All Buried Treasure articles are funded by Patreon backers. If you want to see more reviews of great indie games, please consider backing this project.

"Like a greasy chip butty, oh Sheffield United, come thrill me again"

Hello. (Guardian) How to eat: chip butties. (your terminology may vary) An example of one in Scunthorpe. This chippy uses stotties. Add salad cream to taste, or tomato ketchup, or in Sheffield with Henderson's Relish (nearby posh), or in Barnsley with a side, or in Scotland replace with egg, or add baked beans, or in Gloucester ram it all in with your large battered sausage. A legitimate butty uses margarine (cheapest is bestest), and not butter. A close up. Chip shop chips are best. There are other edible and non-edible uses of chips, and scallops. WikiNot. For meat eaters, the British Sandwich Association has information on the bacon butty. (title and lyrics)

Nick Cave Is Selling Erotic Wallpaper

Last year, Nick Cave released his latest album, the crushing and gorgeous Ghosteen. It was another installment in a remarkably rich late-career stretch from a songwriting standpoint. But in recent years Cave has also undertaken a whole lot of other projects, in the process assuming a new and far more open public identity … More »

How to Have the Best Week Ever

Life is short, so it matters how you spend it.

As Seneca points out, “We are not given a short life, but we make it short, and we are not ill-supplied but wasteful of it.” A minute is long if you know how to use it. A week is plenty of time if you don’t waste it.

So that’s what the Stoics thought so much about: How to break down and organize their time. What to do—and not do—in the course of a life in order to ensure we effectively live the time we have been given.

We now have 2,000 years of stress testing applied to some of their insights and so based on their time-proven wisdom, I present to you how to have a great week, per the Stoics.

1: Rise and Shine

“On those mornings you struggle with getting up, keep this thought in mind—I am awakening to the work of a human being. Why then am I annoyed that I am going to do what I’m made for, the very things for which I was put into this world? Or was I made for this, to snuggle under the covers and keep warm? It’s so pleasurable. Were you then made for pleasure? In short, to be coddled or to exert yourself?” —Marcus Aurelius, Meditations, 5.1

It’s comforting to think that the emperor of Rome (who was reportedly an insomniac) had to give himself a pep talk in order to summon the willpower to throw off the blankets and get out of bed.

From the time we’re first sent off to school until the day we retire, we’re faced with that same struggle. It always seems nicer to shut our eyes and hit the snooze button a few times.

But we can’t—because we have a job to do. Not only do we have the calling we’re dedicated to, but we have the larger cause that the Stoics speak about: the greater good. We cannot be of service to ourselves, to other people, or to the world unless we get up and get working—the earlier the better. So c’mon. Get in the shower, have your coffee, and get going.

2: Prepare Yourself for Negativity

“When you first rise in the morning tell yourself: I will encounter busybodies, ingrates, egomaniacs, liars, the jealous, and cranks. They are all stricken with these afflictions because they don’t know the difference between good and evil. Because I have understood the beauty of good and the ugliness of evil, I know that these wrong-doers are still akin to me … and that none can do me harm, or implicate me in ugliness—nor can I be angry at my relatives or hate them. For we are made for cooperation.” —Marcus Aurelius, Meditations, 2.1

Life is full of suffering, acute and benign. We come down with the flu. We are hit with a costly expense. Someone with power over us abuses their responsibility. Someone we love lies or hurts us. People die. People commit crimes. Natural disasters strike.

All of this is commonplace and inevitable. It happens. Everyday. To us and to everyone else.

That would be bad enough, yet we choose to make this pain worse. How? By pretending we are immune from it. By assuming we will be exempted. Or that only those who have somehow deserved it will find themselves in the crosshairs of Fortune. Then we are surprised when our number comes up, and so we add to our troubles a sense of unfairness and a stumbling lack of preparedness. Our denial deprives us even of the ability to tense up before the blow lands.

“You should assume that there are many things ahead you will have to suffer,” Seneca reminds us. “Is anyone surprised at getting a chill in winter? Or getting seasick while on the sea? Or that they get bumped walking a city street? The mind is strong against things it has prepared for.”

This is premeditatio malorum. What is likely to happen? What can possibly happen? What are the tortures that life inflicts on human beings? And then, more importantly, am I ready for them?

3: Clarify Your Principles

“You’ve wandered all over and finally realized that you never found what you were after: how to live. Not in syllogisms, not in money, or fame, or self-indulgence. Nowhere. Then where is it to be found? In doing what human nature requires. How? Through first principles. Which should govern your intentions and your actions.” —Marcus Aurelius, Meditations, 8.1

In the opening chapter of his book Call Sign Chaos: Learning To Lead, the retired US Marine Corps general and former Secretary of Defense Jim Mattis talks about the fundamental lessons he learned in his early years as a Marine. In particular, he writes: “Know what you will stand for and, more important, what you won’t stand for… State your flat-ass rules and stick to them. They shouldn’t come as a surprise to anyone.” Least of all, you.

Marcus Aurelius called them “epithets for the self.” Upright. Modest. Straightforward. Sane. Cooperative. Disinterested. Those were his non-negotiables. Think for a second about the position Marcus was in. He had absolute power. In his own time, his statue was displayed in homes across the empire. He could have done whatever he wanted.

Isn’t that why people chase power, success, greatness? So they can be freed from trivial rules and regulations? So they can do whatever they want?

But what the truly great know is that complete freedom is a nightmare. They know that no one has less serenity than the person who does not know what is right or wrong. No one is more exhausted than the person who, because they lack a moral code, must belabor every decision and consider every temptation. No one wastes more time than the person who is winging it. Life is meaningless to the person who decides their choices have no meaning. Meanwhile, the person who knows what they value? Who knows what they will and won’t stand for?Who has a strong sense of decency and principle and behaves accordingly? Who possesses easy moral self-command, who leans comfortably upon this goodness, day in and day out? This person has clarity and tranquility.

That’s what Marcus promised would happen if one followed this prescription. “If you maintain your claim to these epithets,” he wrote, “without caring if others apply them to you or not—you’ll become a new person, living a new life.”

What are your flat-ass rules? What are your principles? Your epithets? Don’t wing it. Life is chaotic and confusing enough. Give yourself some clarity and some certainty.

4: Be Ruthless to the Things That Don’t Matter

“How many have laid waste to your life when you weren’t aware of what you were losing, how much was wasted in pointless grief, foolish joy, greedy desire, and social amusements—how little of your own was left to you. You will realize you are dying before your time!” —Seneca, On the Brevity of Life, 3.3b

One of the hardest things to do in life is say “no.” To invitations, to requests, to obligations, to the stuff that everyone else is doing. Even harder is saying no to certain time-consuming emotions: anger, excitement, distraction, obsession, lust. None of these impulses feels like a big deal by itself, but run amok, they become commitments like anything else.

If you’re not careful, these are precisely the impositions that will overwhelm and consume your life. Do you ever wonder how you can get some of your time back or how you can feel less busy? Start today off by utilizing the power of “no”—as in “No, thank you,” and “No, I’m not going to get caught up in that,” and “No, I just can’t right now.”

It may hurt some feelings. It may turn people off. It may take hard work. But the more you say no to the things that don’t matter, the more you can say yes to the things that do. This will let you live and enjoy the life that you want.

For more on saying “no,” you can check out this video, Why You Should Say No, as well as this article, To Everyone Who Asks For “Just A Little” Of Your Time: Here’s What It Costs To Say Yes.

5: Turn “Have To” Into “Get To”

“The task of a philosopher: We should bring our will into harmony with whatever happens, so that nothing happens against our will and nothing that we wish for fails to happen.” —Epictetus, Discourses, 2.14.7

What does a Stoic say to adversity? To recessions? To pandemics? To setbacks and struggles and months stuck inside? To uncertainty and cramped quarters and a collapse of confidence? What do they say to the looming question that has so many people scared—“What if things get worse?”

They say what Bruce Springsteen said:

Bring on your wrecking ball
Come on and take your best shot, let me see what you’ve got
Bring on your wrecking ball

Marcus Aurelius didn’t believe that it was unfortunate that bad things happened to him. He said, “No, this is fortunate that it happened to me.” Because not everyone would have been able to handle it.

But you can. Because you trained for this. Because you know how to find the opportunity inside of difficulty, because you have harnessed the power of amor fati. Other people might be thrown back by what has happened, others still might be able to muddle through, but not you. You’re going to be improved by this. You’re going to triumph over this. You get to prove your mettle.

That’s why you say: Bring it on. That’s why you say hit me with your best shot. Because you have plans to use it. Because you’re going to step up and make something of this moment. Because you know that’s the only part of this that’s up to you.

6: Take a Walk (or a Run)

“We should take wandering outdoor walks, so that the mind might be nourished and refreshed by the open air and deep breathing.” —Seneca, On Tranquility of Mind, 17.8

In his famous Lives of Eminent Philosophers, Diogenes Laertes tells us that the philosopher Chrysippus trained as a long-distance runner before he discovered Stoicism. One can only imagine the influence this training had on Chrysippus, and how it put him in a position to understand a philosophy based on self-discipline, inner-control and endurance. The saying in the ancient world was, “But for Chrysippus, there had been no Porch” (the stoa in Stoicism). But if not for the many miles of running, would there have been a Chrysippus?

There are plenty more philosophers, writers, and poets who have found the same benefits not just in running but in walking. In a notoriously loud city like Rome, it was impossible to get much peace and quiet. The noise of wagons, the shouting of vendors, and the hammering of blacksmiths all filled the streets with piercing auditory violence. So philosophers went on a lot of walks—to get where they needed to go, to clear their heads, and to get fresh air. In the process they discovered an important side-effect: it helped them make better work. As Nietzsche would later say, “It is only ideas gained from walking that have any worth.” Thoreau, another avid walker, claimed “the moment my legs begin to move, my thoughts begin to flow.”

Remember that if you find yourself a little stuck or frustrated today. Go for a walk. Or better yet, go for a run. And in the future, when you get stressed or overwhelmed, take a walk. When you have a tough problem to solve or a decision to make, take a walk. When you want to be creative, take a walk. When you need to get some air, take a walk. When you have a phone call to make, take a walk. When you need some exercise, take a long walk. When you have a meeting or a friend over, take a walk together.

Nourish yourself and your mind and solve problems along the way.

If you’re not yet convinced of the power of walking, I encourage you to read this piece: Take A Walk: The Work & Life Benefits of Walking.

7: Review

“I will keep constant watch over myself and—most usefully—will put each day up for review. For this is what makes us evil—that none of us looks back upon our own lives. We reflect upon only that which we are about to do. And yet our plans for the future descend from the past.” —Seneca, Moral Letters, 83.2

Winston Churchill was famously afraid of going to bed at the end of the day having not created, written or done anything that moved his life forward. “Every night,” he wrote, “I try myself by Court Martial to see if I have done anything effective during the day. I don’t mean just pawing the ground, anyone can go through the motions, but something really effective.”

In a letter to his older brother Novatus, Seneca describes the exercise he borrowed from another prominent philosopher. At the end of each day, he would sit down with a journal and ask himself variations of the following questions: What bad habit did I curb today? How am I better? Were my actions just? How can I improve?

At the beginning or end of each day, the Stoic sits down with his journal and reviews what he did, what he thought, and what could be improved. It’s for this reason that Marcus Aurelius’ Meditations is a somewhat inscrutable book—it was for personal clarity, not public benefit. Writing down Stoic exercises was and is a form of practicing them, just as repeating a prayer or hymn might be.

Keep your own journal, whether it’s saved on a computer or on paper. Take time to consciously recall the events of the previous day.

Be unflinching in your assessments. Notice what contributed to your happiness and what detracted from it. Write down what you’d like to work on or quotes that you like. By making the effort to record such thoughts, you’re less likely to forget them. An added bonus: You’ll have a running tally to track your progress.

If there’s been a silver lining in the COVID-19 pandemic, it’s that we were reminded immediately and unceremoniously that life should never be taken for granted. Sometime during the Antonine Plague, Marcus admonished himself to not put anything off until tomorrow because today was the only thing he controlled (and to get out of bed and get moving for the same reason). The Stoics knew that fate was unpredictable and that death could come at any moment. Therefore, it was a sin (and stupidity) to take time for granted.

Today is the most valuable thing you own. It is the only thing you have. Don’t waste it. Seize it. Live it.

The post How to Have the Best Week Ever appeared first on

The Limits of Experimentation

The absence of a significant musical trend or cultural movement so far in the 21st century: I’ve attributed this to a lack of territorial isolation in that movements (artistic and cultural) would spring out of ‘scenes’ that existed locally but not globally. Now that we have constant connectivity, this separateness is rare, and thus so are movement shifts.

There may also be an element of technology involved, and not just in the advances of global connectivity. Technological progress has created musical trends and genres; think of the increasing number of audio multi-tracks and how that begat Sgt. Pepper’s or Pet Sounds. Or of the fuzz guitar creating psychedelia, the drum machine and sequencer creating electronic dance music, etc.

We can look to film as a guide. There’s a dramatic difference in movies produced in the ’70s versus those in the ’60s and in movies shot in the ’60s compared to those in the ’50s. Many people, especially the young, in the ’70s, would have a hard time watching ’50s movies as they seem old-fashioned. The shift in style and look is pronounced. There are aesthetic differences, too — subjects that were taboo at one time became commonplace decades later, for example — but often, technological developments that influenced the culture inspired these changes.

Think of Jean-Luc Godard and the jump cut. An editing technique that was so radical at the time of Breathless is commonplace in film and TV (and YouTube) now. Godard made it revolutionary because cinema, as a developing art form, still had areas left to explore. As time moves forward, the technology of the medium is no longer one of limitation. 

Another example is the brilliant Russian Ark, an ambitious 2002 film created in a single long camera shot. Digital filmmaking was new, and the hard drive space available to the cinematographer dictated the ‘single shot’ running time of Russian Ark. Compare this to Alfred Hitchcock’s Rope, meant to look as if it is a long, single-shot movie, but throughout, there are several sneaky cuts. The length of a roll of film limited Hitchcock as he had no access to hard drives, but this did not make Rope any less radical in its era. Now, the single-shot film is commonplace — a technique used and overused by modern filmmakers with an almost unlimited amount of digital storage space at their disposal.

Limitations of a medium breed experimentation as the artists push and explore what is possible. With limits removed, this experimentation takes other forms.

The post The Limits of Experimentation appeared first on 8Sided Blog.

Back when software was a craft

Standardization turns homebuilding into a knowledge-based industry.

Tiago Forte

Software is definitely a knowledge-based industry. We have to understand what needs to happen (the business logic that gives software its value), plus how to make a computer do those things.

What if it’s more knowledge-based than it was before?

When I started as a professional programmer in 1999, I had to know C, the standard library, and the Oracle drivers we used. We used Unix and the standard utilities. These few materials were available to us, and we crafted them into software that met customer needs.

Now there’s so much more! There are other languages, and frameworks, and language ecosystems. There are libraries for everything. New utilities every day, at my fingertips with “apt/brew/choco install.”

Software feels more like assembly than craft.

What if software used to be a craft?

What if the standardization of common tasks in libraries and frameworks means craftsmanship isn’t such a big deal anymore? What matters now is knowledge of all those different materials. Understanding the libraries and frameworks and ecosystems and tools and infrastructure and automation. The implications, considerations, and conglomeration of their use.

Now it’s less like wood carving and more like product engineering. Standardized parts improve reliability, while adding flexibility and reducing custom work. Wielding well-defined materials to accomplish new ends.

I’ll take it! I’ll do glue work when it creates many times the value than the same time spent on craft. It’s fine, I can craft on the weekends, for play.

(guard clause: I’m talking about most application development work. Some custom craftwork needs done, and somebody needs to craft those libraries. I suspect that’s not most of us, anymore.)

Surviving Spotify’s Future Landscape

There’s a lot of chatter about Daniel Ek’s recent interview with Musically’s Stuart Dredge. There are more than a few nuggets to dissect, but this one is getting the most attention:

“There is a narrative fallacy here, combined with the fact that, obviously, some artists that used to do well in the past may not do well in this future landscape, where you can’t record music once every three to four years and think that’s going to be enough,” said Ek. […] “I feel, really, that the ones that aren’t doing well in streaming are predominantly people who want to release music the way it used to be released …”

As Liz Pelly has explored on The Baffler, Spotify seems intent on influencing artists to tailor their music to benefit the platform. Yes, some point out that in past decades artists used to release 1 or 2 albums every year, so what Ek proposes is nothing new. But the difference is that artists now almost solely rely on touring for income. It’s impossible for most acts to frequently take months off to record a succession of albums without dire financial risk. No doubt you’ve heard the common refrain that bands used to tour to promote album releases, and now it’s the other way around. 

PRS’s Tom Gray illustrates this using The Beatles as an example. The Beatles stopped touring to concentrate on their studio work and, to Ek’s satisfaction, released a lot more than an album every few years. It’s doubtful a 2020 Beatles could do the same. Without touring income, they would be in the hole. Here’s Tom’s take (click here to read the full thread):

Tom’s numbers get a little fudgey — studio costs and such don’t need to be that high these days — but the point stands. The Spotify age is not kind to bands that camp out in studios. (The streaming model is even crueler to those who write songs but don’t perform, but that’s a whole other harrowing tale I’ll save for another time.)

Damon Krukowski challenges Ek’s statement by looking at current Spotify earnings from his former band, Galaxie 500. Krukowski points out that the band hasn’t released anything in over 20 years so, by Ek’s reasoning, they shouldn’t do well in ‘this future landscape.’ But they get more than one million streams a month. That’s pretty good, right? God knows I wish my catalog got half those monthly streams. 

You might think those numbers put Krukowski and Galaxie 500 in the musical middle class. Instead, those streams amount to about $1250 per band member a month. Here’s Damon (click here to read the full thread):

The concern isn’t what Ek refers to as the ‘top tier’ artists. Those are doing fine. The top artists have always done fine. And, for a variety of factors, they can (for now) live off Spotify royalties and the other compounding advantages of fame and exposure. The problem is the disruption of music’s middle class. This sector relied financially for most of this century (so far) on touring. And with COVID-19 in the air, the absence of touring and the diminished value of recorded music creates a crisis. Music’s middle class was already disappearing — in 2021, it could be gone entirely.

That’s what this interview — and Bob Lefsetz’s defense of Spotify — glosses over. Of course, wildly successful artists, with tens or hundreds of millions of plays a month, make good money from streaming. And it’s disingenuous to imply that artists complain because they feel entitled to the same. I can confidently speak for most artists that we just want an opportunity to earn a living through our music. Opportunity is not entitlement. Even though an artist’s ‘middle class’ was always precarious, there’s very little chance now to make it work. 

The implication from Ek is — and he’s not that far off — in the eyes of Spotify, you’re either a superstar or an unknown. The insult is Ek saying that the latter position is mostly the artist’s fault because she’s a Luddite who’s not “putting the work in.”

(I’m reminded of this insightful quote from author Nancy Baym: “It’s amazing to me to see how so many careers, in music and beyond, have shifted such that it’s no longer enough to do the work. Now you have to do the work of making sure everyone is seeing that you’ve done the work.”) 

But I’m not placing all the blame on Ek, streaming, and the Napster guys who let this genie out of the bottle. All of that became inevitable as soon as the first ones-and-zeroes were digitally encoded on a compact disc. But as listeners and recording artists, we play a part by accepting the notion that Spotify is unavoidable and necessary. Yes, I believe that Spotify is not going anywhere. And I doubt they’ll change anything except notch their monthly price up a dollar or two in a few years. What it’s essential also to understand is we’re not obligated to play along. 

As concerned recording artists, we don’t necessarily need to remove our music from Spotify (though, if you do exit the platform, good on you). The key is to treat streaming as the entrance of a marketing funnel to lead potential fans to our sites and mailing lists. Let’s look at it as if it’s radio. Radio in the US egregiously doesn’t pay a royalty to performers, but performers still allow their music on the radio as it’s an entry for new listeners. But they never say, “You should only listen to my music on the radio.” 

Or as a more musically-inclined Tyler Durden might say: “The first rule of Spotify is you do not talk about Spotify.” Only post links to your site or a store like Bandcamp. Seriously — there is no reason to send your fans to Spotify. The distant hope that the company will return the favor by adding your song to one of their big playlists is a broken motivation.

As listeners, we have a responsibility, too. I frequently write about the seductive appeal of streaming — I know I can’t resist effortlessly accessing an album or band that I just learned about. But we should also support the artists we enjoy by directly purchasing their music, ordering their merchandise, and signing up for their mailing lists. It’s not that difficult, and these gestures mean a lot to the artists. And, like musical Tyler, we should spread the word by posting to our favorite artists’ websites and Bandcamp pages, not Spotify players. 

We’ll all benefit the sooner we start thinking of Spotify as an occasional sampling tool instead of a go-to listening necessity. Let’s happily hand the platform over to the ‘top tier’ with their frequent releases and domination of playlists. It’s evident from the interview that’s who Ek has in mind for his company, anyway (besides Joe Rogan, of course). 

The post Surviving Spotify’s Future Landscape appeared first on 8Sided Blog.

Some common hiring manager mistakes.

There’s a lot to say about hiring, and I’ve written a fair amount about it, but as I was chatting with a few folks over the past couple weeks, I realized one thing I haven’t written about is the frequent mistakes or challenges that new hiring managers often encounter and sometimes struggle with.

If you’re just starting to think about hiring, focus on your hiring funnel first, but if you’re finding hiring to be a challenge, think through whether you’re running into one of these problems.

  1. Not getting to yes (or no). Being indecisive about candidates is the most common mistake I see in new hiring managers. At some point you simply have to make a decision, and you’re going to have to make it with fairly incomplete information.

    It’s better to make a timely decision to hire (or not to hire) and manage the consequences than wait in limbo indefinitely. If you can’t make a decision after following the interview process, then let the candidate know you won’t be moving forward so they can move on with their search.

  2. Overly fluid interview loop. A frequent response to hiring manager indecision is to create new interviews on the fly to attempt to generate new signals. These are usually ad-hoc interviews that haven’t been given before and won’t be given again. Uncalibrated interviews are vectors for bias, which will often help you get to confidence, but that confidence won’t be based on anything particularly solid.

    When evaluating a specific candidate, do your best to make a decision on the information you have. Then analyze across candidates to identify policy or process improvements to get better signal next time.

  3. Holding candidates in stasis for too long. When hiring managers can’t make a decision, they often try to stall the candidate to wait for other candidates to complete their process. It’s totally reasonable to occasionally slow down an interview process sometimes – particularly when it’s the first one or two candidates you’ve seen for a new role – but done frequently it creates a lot of confusion for the candidate and the internal hiring team. It very frequently leads to a bad candidate experience and churns either recruiter or hiring manager time on keeping the candidate partially engaged.

    Give candidates a clear timeline and give an honest update if you don’t hit it, “We’re still excited about you, but we want to interview at least one other candidate for the role to make sure we’re doing the right thing here.” They might be annoyed and disengage, but the alternatives are even worse if you don’t tell them.

  4. Not knowing what you’re hiring for. The first few interviews for a new role are always a calibration period, and the interviews and loop should change frequently early on. However, the scope of the changes should narrow the further you go. If you find yourself still making radical changes over time, for example deciding instead of a Staff Engineer you really want a Technical Program Manager or what not, then you’ve probably not spent enough time thinking about the role you’re hiring for.

    Time spent upfront on ensuring you’re hiring for the right role will repay itself many times over. Spent more time than seems reasonable. Then, spend even more.

  5. Lack of calibration across the hiring panel. Sometimes the hiring manager knows exactly what they’re hiring for, but no one else interviewing the candidate shares that vision. This often leads to the manager and rest of the loop generating opposite hiring decisions and undermines everyone’s confidence in the process.

    Take the time to explain to every interviewer what the role you’re hiring for is, why it matters, the specific work they’ll be doing, and what skills you believe are necessary to be successful in the role. If it’s quite different than seemingly similar roles, also take the time to explain what isn’t as important for this role relative to other hiring loops.

  6. Unicorn hunting. It’s a virtue to aspire for amazing candidates, but it’s a waste of everyone’s time to pursue candidates that generally don’t exist or that you’re not able to incentivize properly to join your team. Many searches start with a prolonged period where the recruiting partner attempts to educate their hiring manager on the impossibility of the role they’re defined, and it’s largely avoidable.

    Start our ambitious, but recalibrate frequently based on candidate interest. If you truly need a unique candidate, then don’t assume a volume hiring approach is going to get them in, and instead treat it more along the lines of a senior leadership hire.

  7. Desperation. If you are getting a lot of pressure to hire and your team is falling behind on commitments, it’s very hard not to hire the candidate you’re talking to, even if you know they aren’t the right person. You will convince yourself they’re the right person, even if someone else was the hiring manager you’d immediately know they aren’t.

    The fix here is to try to avoid falling totally behind in the first place. That said if you have fallen behind – and who hasn’t? – then the secret is to avoid listening to that voice in your head telling you to ignore the other interviewers’ concerns.

  8. Pedigree chasing. If you’re not quite sure how to evaluate candidates, then it can be easy to delegate evaluation to the previous institutions they’ve been involved in. Did they work at a FANG company? Are they from an Ivy League school? This is the hiring version of “No one ever got fired for buying IBM.” A defensible choice but not obviously a particularly great one either. While many folks with academic or institutional pedigree are fantastic, others with those same backgrounds have been those I’ve found most challenging to work with in my career – the correlation here isn’t high enough to rely on it, and these also are usually the hardest to close and most expensive candidates.
  9. Unresponsive to recruiting partners. The vast majority of recruiters are operating under quarterly targets for either number of extended offers or number of accepted offers. If you, as a hiring manager, are not getting back to them quickly, then they can’t rationally continue to prioritize your search. Their job performance depends an inordinate amount on you supporting them well, and being responsive is the single most important aspect of that support.
  10. Just-in-time interview questions. It’s pretty common to run int interview loops that are well-designed, well-structured and yet somehow rely on each interviewer to make up their own questions! This makes it quite challenging to evaluate across candidates, and leads to questions that are simply unreasonable to complete in the allotted interview time frame. (The initial version of pretty much every programming interview question takes three times the allotted time to complete without foreknowledge of the question.)
  11. Cargo-culting their previous company process. It’s totally reasonable to start designing your interview loop and process based on what’s worked for you before. Where some hiring managers get caught up is refusing to deviate from what worked elsewhere even if the funnel metrics give a clear indication it’s not working. This usually happens for a couple different reasons.

    First, it’s common for the hiring manager to have been unaware of some aspects of what made the process work at the previous company. A huge recruiting operations team behind the scenes calibration offers or what not. Second, it’s often that the companies are fundamentally different. What works for FANG doesn’t work for a Series A company, and vice-versa.

  12. Only hiring candidates that’ll be easy to close. It’s easy to project your values and feelings onto a candidate and assume that someone will be impossible to convince to join your team. One variant of this is new hiring managers assuming someone with experience would never work for them and filtering them out immediately. When you’re a new hiring manager is exactly when you particularly need more experienced folks on your team, so work through that discomfort and try to hire folks who you think might not have much to learn from you.
  13. Compensation exceptions as the standard. In my experience, the best indicator of a flawed interview process is frequent compensation exceptions. This is both because I personally don’t like exception-driven systems, but also because these sorts of escalations tend to be slow and inconsistent relative to a well-designed happy path.

    If you find yourself doing frequent requests for compensation exceptions, then you should spend some time to determine if you are misaligned with a well-functioning system or if the system doesn’t quite work.

There are, excitingly, an infinite number of other mistakes you could be out there making, but if you’re avoiding these then you’re probably making a pretty good go of it. Although, inevitably, your funnel and retention metrics are a much better way to evaluate your success than my vague reassurances.)

Why We're All Gardening and Baking So Much

The coronavirus has shown us how little we actually control. It has affected people across the globe—young and old, healthy and ill. You could be doing everything right and still lose your job, or worse, your life. It’s not surprising, then, that activities we can control have surged. Perhaps it’s an instinctual response, an innate balancing act: when the world around us feels huge, complex, and unwieldy, we turn to the small, simple, and manageable.

Though precise data lags, it appears more people have been baking, gardening, creating arts and crafts, and exercising than usual. Kettlebells and dumbbells are out of stock everywhere. Seed companies are running low or sold out. Baking powder has seen a 450 percent increase in demand compared to this time last year.

Yes, many people simply have more time than ever for these activities. But I suspect another reason people are flocking to them is because they satisfy our basic needs for autonomy and mastery.

Whether in baking, gardening, exercising, or creating arts and crafts, you start at point A, do a significant amount of work with your own two hands, and then end up at point B. This journey toward a concrete and tangible goal leaves a wonderful feeling in its wake. 

In 2001, philosopher Matthew Crawford quit his job in academia to become a mechanic. “The satisfaction of manifesting oneself concretely in the world through manual competence has been known to make a man quiet and easy,” Crawford writes in his book Shop Class as Soulcraft. “It seems to relieve him of the felt need to offer chattering interpretations of himself to vindicate his worth. He simply points: the building stands, the car now runs, the lights are on.”

In the case of COVID-19, the bread has risen, the tomato has grown, the necklace has been made, the biceps have become bigger and stronger.

In the early 1970s, psychologists Edward Deci and Richard Ryan introduced self-determination theory. One of the most cited psychological theories of the past five decades, self-determination theory shows that humans are motivated, happy, and fulfilled when three basic needs are met:

  1. Autonomy: Having some control over your environment and, more broadly, the flow of your life.

  2. Mastery: Making tangible progress in your pursuits and being able to trace the outcome of your work back to your efforts.

  3. Belonging: Feeling connected to a lineage or part of a group.

Thanks to COVID-19, people are feeling the fragility and peril of basic human existence more acutely than usual. Thus, many are doubling down on meeting their basic needs. And with belonging not readily available (at least not in the traditional sense; Zoom sessions only get you so far), autonomy and mastery are what we have left.

Perhaps one lesson of the times is that we’d be wise to spend our energy on activities that support autonomy and mastery both now and long after the coronavirus has passed. Once the pandemic ends, we can also add in belonging. We can bake, garden, create, and exercise with other people, in real life. Belonging will only make these pursuits that much more enjoyable and nourishing.

It’s not that these activities distract us from the ultimate uncertainty we live under. Distraction is neither their point nor a viable long-term solution for happiness. Rather, activities with a high degree of autonomy, mastery, and belonging offer us something fulfilling and meaningful amid that uncertainty. 

The ultimate or spiritual realm may be impermanence—constantly evolving matter and energy. But when it comes to the day-to-day realm that we inhabit, we thrive when the bread has risen, the tomato has grown, the necklace has been made, and the biceps have become bigger.

Brad Stulberg (@Bstulberg) coaches on performance and well-being and writes Outside’s Do It Better column. He is the bestselling author of the books The Passion Paradox and Peak Performance. Subscribe to his newsletter here.

Bill Callahan: Knock Knock

Each Sunday, Pitchfork takes an in-depth look at a significant album from the past, and any record not in our archives is eligible. Today, we revisit Bill Callahan’s masterful 1999 record as Smog, a breakup album about discovering new ways of being in the world.

We Quit Our Jobs to Build a Cabin—Everything Went Wrong

We were two or three weeks into building a cabin when the first two-by-four became the target of a sudden, white-hot flash of anger. It was the summer of 2018, in the middle of Washington’s emerald-soaked Cascade Range, and I was on the phone with my father, seeking advice about some framing conundrum, while my longtime friend Patrick (who goes by Pat) was wrestling a 16-foot board toward a miter saw. When the whir of the blade stopped, it became immediately clear that he had cut it wrong. The sawdust still airborne, Pat reached down, grabbed a two-by-four with the conviction of a Baptist preacher, and sent it flying into the forest with a short, crisp, “Fuck.” 

A lot more lumber would end up in the woods. We screwed up countless times from morning to evening, wasting precious daylight hours. Constructing a cabin was a task that one might say we were “not entirely prepared for.” Sometimes, during those months of toil, our anger burned so intensely that we thought the boards we threw into the woods might never land. They’d just keep flying, the wood breaking down over time and separating into smaller and smaller pieces until they vanished, as our brains exploded from frustration and worry.  

In reality, the whole project was borne out of frustration. A few months earlier, Pat and I had what were arguably good careers: I was a reporter at a national magazine in San Francisco, and Pat was a copywriter at a tech company in Seattle. We were lucky enough to have good bosses and colleagues who had become friends. But we were deskbound and felt caged by the typing, phone calls, Slack chats, and emails, all performed under the hum of fluorescent lights. We were overwhelmed by the uniformity of it all and troubled that we seemed incapable of finding contentment in jobs that many of our coworkers appeared to cherish. Sometimes we hoped for an excuse to quit—a blowup after a failed project or an absurd request from a boss.

We knew we were fortunate to have good jobs—and this was well before our country was facing a pandemic and massive unemployment—but we were facing the existential crisis that comes from spending your days doing something you don’t enjoy and wondering if this is how the next five, ten, 20 years will play out. We were in our thirties, young, but not so young. We’d seen the articles linking sedentary lifestyles to heart disease, diabetes, cancer, and misery. We wanted to get out of our respective offices and try something different.

We knew how insufferable it would sound: a couple of discontented millennials deciding to leave stable jobs to do “something more meaningful.” People would think we were a couple of wannabe Foster Huntington dropouts. But being a trope and being free seemed better than being trapped inside for the better part of our thirties. 

For the past five years, we’d joked about various alternatives to our day jobs: scuba dive instructor, skydiving teacher, maybe own a cool hookah café with live music. But one option didn’t seem as ridiculous as the others: leaving our desks to build a cabin from scratch. 

A Skyrim fan is making lovely handmade illustrations of its alchemy ingredients

I once worked in an archive that included a heap of medieval herbals. In some form or another, they were a huge part of our culture and inherited knowledge for thousands of years, and while Skyrim does have a few compendium and guide books, there’s nothing in them that really fits that bill.

But one talented player has recently taken to drawing and painting their own compendium of grumpy Nordland’s flora. Even in its earliest days, it’s got me excited and tempted to dive back into the alchemy game all over again.


The service you build doesn’t do a thing. It participates in a thing.

Cognitive neuroscience likes to assign functions to parts of the brain. This bit does planning. This part does short term memory. This piece perceives faces.

Does that bit really do planning? If you cut it out and held it, would it plan for you?

No. And that other bit doesn’t perceive faces without messages from the eyes and other parts, and further interpretation by yet more parts and the whole person.

Brain sections don’t plan, remember, or perceive. A person plans, remembers, perceives. Those sections of the brains participate. They’re essential, but not sufficient.

Maybe I develop a service that does credit scoring for a loan company. “We do the credit scoring,” I might say.

“Who are your users?”

“The mainframe app calls our service, without any personal identifying information, and we reply with a score.”

Um. My service doesn’t “do credit scoring,” now does it? It participates in credit scoring. But without that mainframe app and the rest of the system, my service does nothing, like a frontal lobe on the dissection table.

It’s tempting to attribute functions of a system to parts of that system, parts that are uniquely active in that function. Those parts may be necessary, but they are not sufficient.

In fancy words, this is called the “mereological semantic fallacy.” Mereology is the examination of part-whole relations. Semantic has to do with meaning. This is a fallacy that attributes meaning to parts, when that meaning doesn’t exist without the whole.

It takes the entire loan company software system and the people entering the data and the credit bureaus we interface with in order to do credit scoring. It takes a whole person to plan, remember, perceive.

We don’t design systems, we design subsystems.

Jabe Bloom

Care about your environment. Practice responsible change (backwards compatibility, advocacy). Get to know the people or software who use your service. Because it doesn’t do anything alone.

This post comes from Turvey, Lectures on Perception (the part you can get free in the Kindle Sample).

Situation Normal

I'm happy to announce that my science fiction novel Situation Normal is being published by Candlemark & Gleam! It'll go on sale December 14th, 2020. Here's the acquisition announcement, and it's time for the cover reveal!

(Cover art is by Brittany Hague, who did a fake book cover as part of ThoughtCrime Experiments way back when.)

My elevator pitch for Situation Normal is "the Coen brothers do Star Trek". It's a military SF story where no one is incompetent but everything goes wrong. Situation Normal is a direct sequel to my Strange Horizons story "Four Kinds of Cargo", but the crew of the smuggling starship Sour Candy is now only one thread of a plot that includes weaponized marketing, sentient parasites, horny alien teenagers, and cosplaying monks. It's the result of a lot of work for me and Athena Andreadis, and I hope you love it!


It was just supposed to be a short trip to pick up some Thai take-out. I headed south on Brock toward the FreshCo in my 2019 Hyundai Elantra. The one that I’d purchased for its safety features and drive-ability, mindful that my two daughters would be learning to drive in it. The light turned red […]


Last night I flipped through the first few pages of Julia Cameron’s The Artist’s Way. People have been telling me to read this book for years. It’s helped them with procrastination, they said, and it might help me too. Of course I ignored them, preferring to ruminate in my muck. It’s that idiot glitch in my brain: This might help me, so I will avoid it.

Cameron’s use of the phrase “creative injury” struck me. It’s a heroic image, the artist suffering a crushing blow that leaves them limping off the field. It suggests they really tried to soar. Maybe this happens to some people. My injuries stem from the dull everyday fears that I’ve allowed to fester. The source is the same, even if the shadows they cast might vary depending on the day: paralyzing doubt versus a brittle kind of rigidity, fear of rejection versus perfectionism, etc.

I know how to fix this because it’s the same thing I tell my students. Give up on inspiration. Show up every day for an hour, or even ten minutes if that’s all you can spare, but write no matter what. Write as poorly as you can and see where that takes you. As long as the keyboard is clicking or the pen is moving, something is bound to happen.

Take my advice, I’m not using it. Instead, I stare out the window. I organize my music library. I make needlessly complicated systems with color-coded index cards. I doodle and wait for a moment that will never arrive.

Several years ago, an old man in New Orleans told me it doesn’t matter if the nail is in the exact right place, so long as it’s holding together two pieces of wood.

Round Three feat. Paul St. Hilaire – Find a Way

Round Three | Main Street Records, 1998 | More

🤩 More