Lucas Wojciechowski

The Joel Test is a classic blog post that was written about 20 years ago. It's a list of 12 best practices that every software engineering team ought to follow.

What follows is an updated and maybe harder list of best practices in 2020 that many teams aren't following:

1. Do you require all code pass a code review before being merged into the main branch?
2. Do you reject code reviews that don't have a test plan? (Ideally the test plan is automated unit tests or integration tests.)
3. Do you reject large code reviews that could be broken into several smaller code reviews? 
4. Do you require that large projects begin with a written plan that gets discussed before implementaiton begins?
5. Do you set aside time to pay down tech debt as determined by the developers most familiar with the code? 
6. Do you do regular hallway usability testing? (Ok, this one's on the original Joel test, but deserves more attention.)
7. Do you have an up-to-date roadmap of at least a month worth of work?
8. Do you deploy to production or a heavily used staging server on every commit to the main branch?

A common pattern in the tech industry is “tension.” 

For example: A sales-minded person wants a new feature so they can close a big deal. An engineering-minded person doesn’t want to build that feature for a single customer. 

The two people exist in tension. It’s uncomfortable but healthy in moderation.

Some tensions are specific to a project’s circumstances and personalities. Others pervade the whole industry as sort of archetypal tensions. 

We ought to pay close attention to these archetypal tensions because they concretely point to shortcomings of our worldview. 

One tension I’ve seen again and again: An engineering-minded person wants consistency in UIs because that simplifies implementation and maintenance. A design-minded person wants flexibility when designing UIs because they care about usability and aesthetics. (Consistency is one of many tools a design-minded person might reach for when designing a great UI.)

I’ve seen this particular archetypal tension spiral into grudges, burnout, and resignations. Each side feels very strongly. 

Mutual understanding and compromise are essential.

The compromise comes down to how the UI is abstracted in code. Less abstraction in the UI layer creates more flexibility. More abstraction in the UI layer (if well designed) creates more consistency.

Speaking subjectively, I’ve found that building abstractions that create consistency in basic design elements like colors, text treatments, and spacing tends to make everyone happy. I’ve found that building abstractions that aim to create consistency in domain objects like “the visual representation of a user” or even “the standard callout” tends to aggravate the tension.

Engineering-minded people tend to overestimate the value of consistency in their UIs and underestimate how likely those UIs are to change as the product grows. Erring on the side of less abstraction in the UI layer tends produce a healthier team and a better product.

Laurel Mountain is Mammoth Lake's backyard alpine adventure. It's been a treat to watch it change with the seasons. And humbling to be reminded that its more of an alpine adventure than a backyard adventure.

I climbed Laurel in late November last year, just in time to watch the first big snowstorm of the season break over the Sierra Crest, framed by a red sunset. It was an awesome sight. By the time I started down, the snow was falling on me. I had a hard time finding the way down and got wickedly cliffed out in a few spots. That was a scary day.

Returning to the summit in spring weather feels like a rebirth.

Next to my desk I keep a jar with slips of paper. Whenever I need a break from work I take a slip of paper out of the jar and do whatever it says. I appreciate not being responsible for dreaming up a constructive use of time while my brain is exhausted.

This afternoon I drew one that says "Write Haiku."

Heavy afternoon sun
Songbird in the tree sings
Don't know, don't know