Your Docusaurus site did not load properly.

A very common reason is a wrong site baseUrl configuration.

Current configured baseUrl = / (default value)

We suggest trying baseUrl =

Don't Let Them Tell You What To Do

Modern labor, as described by employers, is a paradox.

On the one hand, employers attempt to tell you that labor is a purely transactional interaction; you're on their time, and they get to tell you how to spend it. The product of your labor is not your concern. Leave your identity politics at home. If you're leaning, you could be cleaning. These hours have been bought, and no longer belong to you.

On the other, employers attempt to capitalize on your personality and intuition. There is an emphasis on growth in the workplace, and interviews don't measure only for current abilities, they predict how you may be a value-add to the culture of the workplace. Companies spend huge amounts of advertising budget attempting to prove to you that, yes, black people work at Amazon. That the workplace is a family. That the company's success is dependent on you, and therefore, you share in the company's success.

At the end of the day, neither is true. The work relationship in the extreme majority of workplaces is simple. You work there becuase you working there makes them more money than you not working there. Labor is the source of all value, and ironically, especially so in tech work. There are some values driven workplaces, and they are a wonderful compromise - but ultimately, if you clearly are not generating more money for the company than you are being paid, you will have a hard time working there for very long.

A theoretical view of tech is that it is a passive machine. That you build something somewhat analogous to a book that can print itself forever. And then, people buy that book, on a monthly recurring basis, until you have enough money to shoot yourself into space. The reality is that tech, like nearly every other thing humans create, degrades at a shocking speed, and requires a huge amount of labor just to keep functioning at a flat rate, to mention nothing of scaling or growing.

Labor touches everything in tech - the initial designs have downstream effects on the maintainability and scalability of a product, sales staff set expectations, preferences and intuition shape the product, and all of that work only puts you in a position in which bugfixes, oncall response, customer support, and directional leadership can have a chance of generating more income than they cost. If the staff of any website or app, simple or complex, walked away from it, it would cease to exist in a shockingly small period of time.

Folks who are early in their career can easily, as I did, believe that their job is to build a building that will stand forever, and that the value generated by these high-leverage actions will grow over time exponentially. But the reality is that exponential software growth is tightly coupled with exponential labor growth. Some of this is linked to application complexity, a topic for another post. There are outliers, but this trend is unavoidable.

What does this mean for the labor? It means that despite how much your employer may try to convince you that they know what is best for you, your peers, and the codebase, they always must weigh their ideas in this area against the equation of labor to value - so no mandate by an employer is made entirely in good faith, unless your sole goal at the company is to make your employer a lot more money than you make. I know few if any people who fit that description.

Tech workplaces (along with a growing number of other industries), despite needing to make money, have an interesting secondary effect of being wonderful places to grow your skills, because labor makes all the important decisions. I've certainly watched managers attempt to design software, but at the end of the day, every single decision that directly impacts the functionality of a product is made by someone working at an individual contributor level. This means that quality directly correlates with intuition - even the most hands-on micromanager cannot attempt to control every line of code you write. And as all software programmers know, every line makes a difference in maintainability, scalability, and functionality.

How does this effect your job? It means that if your company is being run correctly (which it likely isn't), you and your employer can form complimentary incentives: your employer wants you to cost less than you make them, and you want your intuition and decision making skills to be better (and worth more) than when you were hired. There is, however, a catch.

The catch is that to make your intuition and decision making skills improve, you have to use them. There are no pure problems in consumer software, everything you do must be both guided by computer science principles and an intuition and awareness of the problems you are solving at work.

Therefore, if you work from a list of JIRA tickets that you don't necessarily understand, if you execute against an OKR that you can't explain why it is important, or if you don't know why the thing you're doing is important to the company, you are being taken advantage of. You are generating more value than you are being paid, and you are not receiving any additional benefit (beyond your salary, which we've already shown, will only be paid to you if it is less than your value).

This type of abuse is both rampant and fairly easy to avoid. Simply, don't let anyone tell you what to do. If presented with a task, ask yourself: "do I agree with the goals of this task? Do I want to do this task? Does this task contribute to my growth and the success of the company?" If the answer is no, politely decline and ask for more information. It's possible you misunderstood the task and just need clarity, but more likely that you're the first person to ask this question about the task, and in doing so you will both improve your personal prospects, and contribute immense value to your employer.

The Simplest CMS, Part 1

What is the simplest & cheapest CMS possible?#

As someone who works in tech, I'm often asked to "build a website".

When asked this question, I always try to learn a bit about what they expect the website to do.

What a non-tech person means when they ask this question is usually:

  • Someone types a url into a browser, and sees something special that works as well as other websites but looks more unique and personal than something like a template.
  • The content on this website follows some common patterns. There's an about page or similar, a listing page containing a potentially infinite, but realistically quite small, list of objects. Maybe they're posts, photographs, or items for sale.
  • Search, if it exists, is quite small. It's not often that someone asks for their content to be globally full-text searchable.
  • Being able to update the content whenever they like is imperative. They don't want to learn a complicated system, they would prefer that it were as easy as posting to Facebook.

I've spent a lot of time, in short durations but over a long period of time, trying to build a system that satisfies these requirements, but is neither expensive to maintain nor complex to use.

This blog is one of the attempts - and in this case, I attempted to delegate as much as possible to an existing, maintained system (docusaurus). However, the approach I used here requires fairly strong familiarity with github and markdown, but passes the cost and simplicity requirements with flying colors.

Over Engineering#

One approach I took to this was quite involved, and used the following setup:

  • Parcel to build the frontend
  • Hasura (running on Heroku) for the database (which is Postgres under the hood), API, and authentication layer
  • GraphQL queries for CRUD between the frontend and the database
  • Docker Compose for running Hasura & Postgres locally
  • Netlify as a CDN, for DNS management, and for serveless functions, which are primarily used for generating JWTs.

The goal here was to leverage a shared db to scale this model fairly cheaply, but still has the downside of authenticated transactions on every load. Scaling this could be potentially problematic at the DB level (although realistically, I'd expect the audience of this product to be relatively small). But most of all, it just felt very heavy weight for something that was supposed to be small. It's an interesting idea for something maximally complex, but I realized that the core interaction needed by the person adding content to the website is just the ability to organize lists, add objects to the list, and update content on static pages.

This blog has nearly the same interaction, but since it's built on docusaurus, has a bunch of unrelated and difficult to modify features.

A Project#

After deciding the above approach was too complex for the problem it was solving, I started thinking about a much simpler CMS that follows some common yet new patterns in the industry. It would be composed of the following pieces:

  • The website would be entirely contained in a git repo. All content would be represented by static files in a human-readable format.
  • When the content changes, a CI job (Github Actions) would compile it to a static website.
  • Netlify would act as a CDN, and handle DNS.

This is how this blog works, for the most part. The DSL is markdown, and this site isn't very flexible in terms of object types. Pretty much only blocks of text are supported. And it still has some problems:

  • You have to know how to use Docusaurus to modify the layout, which leaks to React, Babel, and Webpack knowledge.
  • You have to be able to confidently edit the content in a git repo (alongside the source) and generally understand git to update it.

So, I think the simplest CMS would add two personas to the stack:

1: Setup#

  • The site would define one or more editable schemas that define an object type.
  • The site would define one or more simple html layouts and a page layout. The simplest and/or most common templating language should be used here.

2: Update#

  • The site would provide a dedicated interface for adding new files to folders corresponding with the schemas defined at the site level. These would produce the listed objects that the above talked about.
  • The site would provide a dedicated interface for editing page-level content.


When complete, the goal of this project would be to allow a person with mid-level knowledge of html and git to create a website that was completely custom, with simple schemas. This allows for maximal flexibility while still keeping things relatively simple.

If the site is set up in a standard way, a single desktop/mobile client or website will be able to connect to this git repo using Github OAuth or standard ssh/https git authentication, and edit any website built this way. It would simply edit the schemas defined by each website, and central documentation would track the available scalar types for each of the schemas.

The HTML would simply layout and render the content of the schemas based on their scalar types, but the scalar types can expand to be quite complex, for instance media players or observable notebooks could be embedded using simple definitions.

The build step could be centrally developed and versioned, allowing the boilerplate for this type of website to be very cheap.

Finally, since this repo will be a simple static website, it can be deployed to any of the myriad static website hosts that are available, making administration of some of the harder parts of DNS and CDN quite manageable to someone with little knowledge of the underlying systems.

Next Steps#

It's possible that I won't build this. But if I do, I'll need to choose some initial parameters:

  • Which static site host to target first (probably Netlify)
  • Where to run the shared generation code (probably Github Actions)
  • Which html templating language to use (unsure)
  • How to build the client (Web tech with WASM bindings for shared business logic if it gets complex)
  • What scalar values to support
  • Where/how to build the docs (probably just use the same tech as the CMS)

If and when I make progess, I'll update this blog.

Dry Bar

I've been bartending a lot. Today marks a year since I set foot inside a bar, and my home collection has grown sizably. As I gain skill in shaking and inventing cocktails, I find myself exploring the ingredients themselves more and more.

Recently I was having a conversation with a coworker, and I mentioned that my brother had stopped drinking, and talked a bit about the cocktails I was enjoying making that didn't have alcohol. This coworker had included their kids in their cocktail hobby, who he didn't want to get drunk. He mentioned (and sent me a copy of!) a book called Zero. It's published by the Alinea group (proprietors of the Next restaurant and Aviary bar, among other projects, in Chicago).

I also have the Aviary book, and most of the recipes in both are whimsical, but not particularly executable, at least at home. I have patience and persistence, but can't put a bottle of chartreuse in a convection oven for a year, or give up an entire freezer shelf (or glassware shelf) for the purposes of a single-drink. However, the "Back Bar" section of Zero was something I had been looking for and had yet to find: a starting point for an entirely alcohol free back bar.

As I read the recipes, I started to imagine the flavors, and it became immediately obvious to me that I'd want to refine based on the ingredients I would use (for instance, I will use Burlap & Barrel products wherever possible, which will require adjustments to the recipes). It also became clear to me that shopping for these recipes would require some software.

Data Viz for Recipes#

So, I built a product. In the section below, you'll find the names of all the back bar recipes contained in the book. If you select one or more recipes, you'll notice that below it is a table of ingredients. As you add recipes to the set, the list of ingredients will update. The column immediately to the left shows you how much of each ingredient you'll need to make all of the recipes you have selected.

Below the table you will find a shopping list that is generated based on the recipes you have selected. You may have some of these ingredients already. If you check them off in the table, they will be removed from the shopping list.

Once your list is accurate, copy paste it to your favorite markdown application (I use Bear or Quip), and it should convert itself into a checklist. Then head to the store or the internet and check it off.


Source: Dry Bar by Jesse Ditson


This collection of articles is written by me, Jesse Ditson.

I work as a Software Engineering Architect for Quip, which is owned by Salesforce. None of the opinions or ideas expressed in these articles are owned or endorsed by either company.

I live in Joshua Tree, California, in the United States.

I spend my time making music, reading, writing, building and growing things, and taking care of my home and the earth around me the best I can.

I can be reached at, if for any reason you desire to speak with me.

Making A Demogorgon

[originally published on Medium in 2016]

This halloween we decided to stick with pop culture and try a Stranger things costume. I started it the same way I start every year, by taking screen caps, measuring everything, and scaling everything to my height.

Sketch and reference image

For this costume, I wasn't too worried about the proportions, since I was going to be just painting a morphsuit for the body. I figured I'd draw up a slightly more human-like version to play with some ideas too.

The most difficult part was obviously the mask, so I did some searching around for inspiration and found a great tutorial that I stole most of the techniques from:

However, I wanted a mask that I could take on and off, didn't want a long application process (if any), and I wanted to do a better job matching the proportions on the show.

First, using my measurements and screenshots as a guide, I made an armature for the mask and covered it in masking tape, a layer on each side.

Mask Armature Wire Mask Armature with Tape

I used the technique in the tutorial to make the teeth. In my case, it took pretty much exactly a whole bag (6 oz) of Instamorph Moldable Pellets when it was all said and done.

I found that microwaving the plastic and visually watching for them to become clear wound up yielding more easily moldable blobs than dropping the dots in water like the instructions on the bag says.

Be careful and keep the temperature as low as possible while still making the plastic completely transparent. Watch out for superheating the water, which could cause a rapid boil when disturbed. Basically, never heat for over 90 seconds or so.


The teeth pretty much form themselves when you cut them off a strip of plastic, a pretty neat technique.

Painted Morphsuit Leg Partially Painted Morphsuit Finished Painted Morphsuit

The body was just a grey morphsuit, painted with acrylic. I alternated back and forth between making teeth and painting coats on the morphsuit.

I used a large wide brush and thin layers of dry brushing to get a nice "burned" kind of look to match the monster in the last episode, when we get the best look at it. On the shoulderblades and chest, I left some negative space as highlights to give it a bit more of a textural feel.

Face Hole

Next, I moved on to the mask. I used an exacto to cut out a face-sized hole, after measuring right around my eyebrows to just below my mouth.

Tape Hood on Mask

I then folded the flaps inside, and created a duct tape flared ring on the inside of the mask. I then laid tape sticky-side out around a head-sized balloon to create a helmet-like attachment to the back of the mask so I could wear it like a hat.

Latex painted on mask

I mixed some latex with flour and food coloring, which on the first try was a cottage-cheese-like mess. The latex I used had been around since last year, so I think it was a bit thicker than I'm used to. I spread it on the mask anyway, and after waiting a few minutes for it to firm up, planted the teeth directly in the latex.

Latex painted on mask

The second batch of latex was with a different, much thinner latex and flour, which I mixed to a predictably over-compensated thin paste. It ended up being a bit difficult to work with, and the teeth had a hard time getting purchase on the thin coat of latex.

Lesson: it's worth it to focus on pancake-batter consistency before pouring that shit on the mask.

I intentionally saved the big "wings" for last, as I figured I'd get better with practice, and I wanted the wings to be really solid. I finally nailed the latex consistency and got some really nice, scary looking teeth on both sides:

Latex painted on mask

A lot of guides that I've read seem to be convinced that latex dries a lot faster than it does. All said and done, each piece with more than ~1/4" or so of latex took a minimum of 48 hours, and up to 4 days to dry completely, so plan accordingly or go with thinner layers (and expect to have to reinforce the teeth鈥)

I then set up a cast for the inner face part by using an old face cast that I made years ago, (originally used in a Dr. Doom costume, hence the silver + rivets) which I re-use pretty much every year for anything that needs to form to my face decently.

Face Cast without plastic

I generally just used a lot of tape and cardboard to make a decent little bowl, then lined it in saran wrap, and covered the whole mess with a bunch of vaseline so I could pull the saran wrap off when finished.

Face Cast with plastic

I then made up another batch of latex, but added both red and black for a darker color.

I smashed it in there, leaving some rough eye and mouth areas, added some teeth for good measure, and let it dry, which took a solid 48 hours at least.

Face Cast with latex

Your mileage may vary, but ultimately I think I prefer using acrylic to color the latex rather than food coloring, which all ended up being a bit brighter and more pink than red and more blue than black. I ended up having to touch up the mask quite a lot with acrylic when finished cause the colors kind of sucked.

By this time the front of the mask had dried, so I did some touch ups. Some of the teeth weren't staying in great on the too thin or thick areas, so I super glued some of them, and painted on a bunch of mod podge, which had the added benefit of giving the mask some wet-like shininess.

Fix Teeth

I painted the back of the mask with a thin latex coat. You can see the "black" food color is a complete joke. After that was dry, I painted the back with acrylic, then glued in the center part of the mask with mod podge on both sides after a test fit to make sure I could see well.

Back of Mask without paint Back of Mask with paint Front of Mask

I also chopped off the ends of the fingers and made eye & mouth holes in the morphsuit so I could drink and see. I rarely am able to on halloween, so it was nice to make something that I could leave on for extended periods of time.

To get the creepy hands, I just grabbed some finger extensions and painted them black. I tried using some shitty paint on my mouth and exposed fingers, but it rubbed off pretty much immediately. I'll explore other options tonight for better hiding my mouth & fingers, but out on the dark street it was very convincing even without eyeblack.

Full costume with arms crossed

Full costume

As a final step, I bought a bunch of K-Y Jelly and fake blood as well, which I'll use to make the face a bit more drippy/gross. I'll be wearing it around SF this weekend, say hi if you see me!