Asynchronous communication ¶

Office workers have the luxury of hallway conversations. In an in-person office, getting feedback takes mere minutes. But in a remote work position where you may be on the other side of the planet, communication may take overnight.

To be effective, you need to master asynchronous communication. This means:

• Know how to send and reply to email
• Know how to ask smart questions
• People may opt to use chat systems (slack/IRC) asynchronously — adjust your expectations accordingly.
• Minimize the amount of back-and-forth
  • Try to anticipate and respond to questions
  • Don’t send contentless pings
  • Write well

Timezones suck ¶

I wish this section was as simple as saying: use UTC for everything, but it’s never that easy. You should definitely give meeting times to people in UTC, but you should tie meetings to a local timezone. The alternative is that your meetings shift by an hour twice a year due to daylight savings.

This all gets more complicated the more countries you have involved.

While the United States ends daylight savings time on the first Sunday in November, many countries in Europe end daylight savings on the last Sunday in October, creating a daylight confusion time.

During daylight confusion time, meetings made by Americans may shift by an hour for Europeans and vice-versa.

I think the only thing to learn from this section is: you’ll mess it up.

Space and Nice tools ¶

Function often follows form. Give yourself a context for capturing thoughts, and thoughts will occur that you don’t yet know you have

– David Allen, Getting Things Done

Working from the kitchen table is unsustainable for your mental health and your back. You need a space that’s primary function is your work, and that space needs to have tools that are a joy to use.

Splurge a bit on tools you’ll use every day: your chair, keyboard, monitor, headphones, webcam, and microphone. These purchases quickly fade into the background of your life. Still, if you ever have to work outside your home office again, you’ll realize how these tools enable your best work.

Buy a nice notebook, and don’t be afraid to absolutely destroy it. I prefer the Leuchtturm 1917 notebooks, but I’m currently trying out the JetPen’s Tomoe River 52 gsm Kanso Noto Notebook. Writing is thinking, and you’ll find your thinking is sharper if you start with pen-and-paper first.

“The beginning of wisdom,” according to a West African proverb, “is to get you a roof.”

– Annie Dillard, The Writing Life

The most important property of your permanent workspace is that it has ample and appropriate light for video calls.

Apart from that, I prefer having a door, but then again, I have a dog and a cat, so your mileage may vary.

1️⃣ Have a point ¶

Make sure you have something to say before you write.

Corporate-speak will write your email for you unless you remain vigilant¹. Jargon lulls the writer into the false belief they’ve said something precise while your reader may wonder whether you’ve said anything at all.

Be direct and start your draft with the purpose of the email. Writing That Works by Roman and Raphaelson offers this advice: try writing what you want to say as if you’re talking face-to-face. Don’t worry if your first draft sounds too casual. You can always wrap your plain language in the requisite business shibboleths later.

2️⃣ Keep it short ¶

Write as if you were dying. At the same time, assume you write for an audience consisting solely of terminal patients.

– Annie Dillard, The Writing Life

Everything you write is too long.

People reading your emails aren’t fans of your writing—they’re trying to get through their email.

When you’ve finished writing your email, use Stephen King’s equation from On Writing: “2nd Draft = 1st Draft – 10%.” Your writing will be more effective.

3️⃣ Make it easy ¶

All visually displayed text involves typography

– Matthew Butterick, Butterick’s Practical Typography

Appropriate typography and thoughtful information architecture make your email easier to parse. It’s not enough for your email to be easy to read; it’s got to look easy to read.

Researchers at the University of Michigan gave student test subjects two identical sets of instructions: one in a hard-to-read font and one in an easy-to-read font.

Despite the steps being identical, the student’s predictions of the difficulty of the tasks differed. Students believed the less intelligible instructions described a more daunting task. The author’s conclusion is the title of their study: “If it’s Hard to Read, It’s Hard to Do.”

Break up long text with headings. Keep your paragraphs short. Use bullet points and short sentences to make your text look less intimidating and easier to read.

4️⃣ Make it ✨pretty✨ ¶

I know. Emojis 🙄.

In her book Because Internet, author and linguist Gretchen McCulloh posits that people embraced emojis because they add body language to our writing. The first two sentences of this section are an example of how emojis succinctly convey emotion.

Emojis help people process the shape of your text at a glance. I use emojis to lead the eye through a text. Emojis are precognitive signposts you can use to reinforce the meaning of your writing.

Emojis can’t substitute for substance, but they can help make your text easier for your readers.

I ❤️ the judicious use of emojis.

Further Reading ¶

• The Elements of Style – The essential text for improving your writing.
• On Writing Well – An extended remix of Elements of Style with specific chapters on writing for business.
• How to Make Sense of Any Mess – Found via the Write the Docs Book Club (another great resource). Tips to improve your information architecture.
• Butterick’s Practical Typography – Your readers should judge you by your ideas, not your typography.

Software ¶

• Hemingway Editor – In-browser editor that points out problems like overuse of adverbs and passive voice.
• Grammarly – I pay $60 quarterly for this. I don’t use the browser extension since that seems likely to send every plain text field I fill in my browser to their servers. I don’t trust this service with my data, but I do like this service.

Audio fidelity ¶

Digital music fidelity gauges the faithfulness of a digital recording to its analog source. The analog source—a piano, say—is a continuous signal. The digital copy—an audio CD, an mp3, or an Ogg—samples that signal at 44.1KHz—a discrete signal.

Deployment fidelity ¶

Your main branch is like a soundwave—it carries changes and changes rapidly—it’s a continuous signal. Your production environment is like an mp3—it carries forward a single sample until your next deployment—it’s a discrete signal—it’s a single SHA1 in the merkle DAG of your main branch.

Everyone at Wikimedia (myself included) devoured Accelerate—it will frame discussions at the Wikimedia Foundation for years. The theme of the book is continuous deployment driving organizational change.

In the book, however, the authors advocate for tracking both change lead time and deployment frequency. But I don’t get the point of measuring both: they’re two ways of looking at the same thing. If you have a shorter lead time, your deployment frequency is higher. If your deployment frequency is higher, you have a shorter change lead time—potato/potato.

There are many ways to measure deployment fidelity: the time it takes for a change in mainline to reach production, the number of deployments per month, or the number of changes bundled into a deployment. These are all measures of the speed at which you deliver value to users. Pick one—not all—to be your North star.

Continuous deployment ¶

Continuous deployment is the highest fidelity deployment.

High-fidelity audio is lossless, and high-fidelity deployment is continuous. The best deployments sling out individual production changes by themselves within minutes of merging to the main branch. This is continuous deployment, and this is the right way to deploy code.

Deploying every change individually right when they merge means your lead time is only limited by your deployment tooling—the fastest it can be. Your batch size is always 1—the lowest it can be. Your deployment frequency is 1*commits—the highest it needs to be.

Sometimes things aren’t ideal. If your deployment tool cranks out one change every 10 minutes, you’re capped at 144 changes in a day—if you’re TheFacebook then maybe that’s not good enough, and you’re forced to batch changes, as Facebook has in the recent past.

Why deployment fidelity matters ¶

This is important because “software doesn’t age like wine; it ages like milk.” Developers can only juggle so many problems at the same time. If you have a high-fidelity production, then the picture in the developer’s mind matches production. If not, then developer assumptions don’t hold. When software languishes undeployed, developers lose their context and, with it, the ability to solve production issues caused by their code.

The longer the release cycle, the longer the development team has to make incorrect assumptions before the deployment occurs, and the longer it will take to fix them

– Continuous Delivery

Think of the developers. Deploy continuously.

Studies from the trenches ¶

An IEEE study titled “Code Reviewing in the Trenches” by researchers at Microsoft found code authors aren’t getting timely reviews, and code reviewers aren’t given enough time to do the reviews they’re assigned. This is a problem.

In 2013, Peter Rigby and Christian Bird—both empirical software engineering researchers—found similar median review times among projects as varied as Google’s Chromium and Microsoft’s Office suite. Compared with the outdated industrial process of software inspection, their study’s modern code review practices were faster, easier, and less formal. Software inspection took 10 days to review a change; projects in their study took one day to review a change.

In 2018, Google compared Rigby and Bird’s findings with review data from inside their company. Among their findings, they discovered reviews inside Google were considerably faster than the reviews from Rigby and Bird’s study—the median time to review code inside Google was about an hour.

Organizations enable timely code review. ¶

Why is code review at Google fast? Google’s code reviews follow the recommendations in Microsoft’s “From the Trenches” study, which says: “how an organization sets the stage for reviewing activities and how it supports and values code reviewing is critical to the success of code reviews.”

• Training: At Google, they offer readability certifications to developers. Developers with python certifications review python and developers with javascript certifications review javascript.
• Ownership: Clear code ownership makes it easier to find the right reviewer. At Google, the OWNERS file serves this role.
• Metrics: Count and celebrate the time spent reviewing. The metrics from both the Google study and Rigby and Bird are a great place to start.
• Time: We need to set aside time for reviews.
• Culture: As noted in the book Accelerate, John Shook, in recounting his experience introducing LEAN manufacturing at Toyota, says the best way to change culture is to focus on behavior. Enforcing good code review behavior makes code review culture better.

The research cited above studies massive, distributed software projects. Startups and independent developers may find these organizational practices don’t apply—and they’re probably right.

Capture ¶

High dynamic range images have a large range of brightness in the scene—some light areas, some dark areas. By blending an underexposed image that captures detail in bright areas of the scene with an overexposed image that captures detail in dark areas of the scene you can capture a range of brightness that would not be possible with a single photograph.

In the picture above, taken on the pinto arch trail in Moab, Utah, there are two exposures of one scene: the immediate surroundings are in a shadow, the sky and butte in the distance are in the bright sunlight. Below I’ve blended the shots into a single scene with a wide range of brightness – an HDR image:

I captured the image above using the following equipment:

• Nikon D610
• Samyang Optics / Rokinon AF 14 mm f/2.8 FE

And that’s it: no tripod and no filters. I shot the image handheld at f/11 ISO 200.

The shutter speed for underexposed photo was 1/400 sec. For the overexposed photo it was 1/60 sec. I varied the shutter speed using the exposure bracketing feature of the Nikon D610.

Processing ¶

After capturing my under- and over-exposed photos I use the following software programs:

• align_image_stack which is part of the hugin package
• enfuse which is part of the enblend family of FOSS photo tools
• Darktable to make final edits and lens correction
• exiftool to manage metadata

First, I import my images using a bash script I wrote that maintains a strict file structure. Next, I use Darktable to do lens correction (based on the astounding achievement that is the lensfun database) then I export as 16-bit tif files.

At this point, since I shot the images without a tripod, they have minor misalignments. align_image_stack corrects the misalignments and creates a perfect stack of images:

#!/usr/bin/env bash

# align.sh
# ---
# By default align image stack tries to find 8 control points in a 5x5 grid
# This finds 16 control points in a 10x10 grid.
align_image_stack \
    -a aligned_ -v -m \
    -g 10 -c 16 -C \
    "$@"

I use the command align.sh *.tif with the above script to create aligned images.

This command creates precisely aligned, stackable tif files with the prefix aligned_ in the current directory.

Notice in the image above – taken just East of Moran Point at the Grand Canyon in Arizona – that the underexposed image shows more detail in the clouds and the sun, whereas in the overexposed image shows much more detail in the canyon and on the rocks in the foreground.

Now I use the enfuse command to produce a not-offensively-garish HDR image of the aligned images: enfuse -o out.tif aligned_000* .

In the final image, we retain both the detail of the sun and clouds in the sky as well as a clear view of the canyon (and its grandeur) and the rocks in the foreground.

This is a technique I use constantly to capture shots that would be impossible any other way, AND(!) it uses tools and techniques that are useful for all FOSS photography nerds. Best of all? No high-falutin cellular phone required.