Achieving Deep Focus in an Open Office

Writing software is an activity that requires uninterrupted periods of deep focus.

You’re thinking procedurally through the logical implications of minute differences in abstract structures.

Each interruption, or a ‘context switch,’ represents significant wasted attentional overhead, as it can take 20-30 minutes to get back into your flow state.

I explained it once to a product manager friend of mine this way:

Imagine you’re a terrier, and you’ve been asked by a human to go into a gopher hole, and traverse an expansive network of gopher tunnels to eventually locate the gopher and bring it back to the surface.

Every time the human calls you back up to the surface to ask a question or adjust the parameters of their request, you then have to go back down into the tunnels, and reorient yourself. Where are you, again? Which tunnels have you already traversed? Which one were you in the middle of traversing? etc.

Silence is the Absolute Best Environment for Concentration

If you need to achieve a deep focus, the research shows that you really want a perfectly silent environment:

Cognitive processes improved with silence.

Further, if you’re going to listen to music, it’s more optimal to listen to repetitive, non-stimulating music without language or vocals:

Hearing ‘meaningful’ sounds (like language) interferes with concentration.

Stimulative music hampers concentration.

Choosing whether to listen to music or not is within your control, but if you’re working in an open office environment, the conversations of your coworkers are omnipresent and not within your control.

So what can you do to mitigate this focus-threatening environmental factor?

A Software Engineer’s Best Friend

Enter these guys, right here:

3M X2A PELTOR X2 Earmuffs, 24 dB, Yellow/Black

3M X2A PELTOR X2 Earmuffs, 24 dB, Yellow/Black

Total focus for $13.

I have two pairs: one for home, and one for the office. I take them to the library with me. I even combine them with earplugs to even greater effect. They’ve been extremely useful in preserving my ability to focus in any environment.

If you’re working in an open office, I highly recommend giving them a shot.

If you do choose to listen to music, you can even tuck your earbuds inside to get a nice noise-canceling effect.



SOLID Principles Cheat Sheet

SOLID is an acronym representing 5 principles of object-oriented programming that inform the construction of well-designed, maintainable components. These principles apply to functions, classes, microservices, etc.

If you’ve had the experience of recognizing that code is well-written without being able to put your finger on exactly why, it was probably the application of these principles.

The original source of these principles is Robert C. Martin’s paper, Design Principles and Design Patterns (2000).

Martin also wrote a book called Clean Code: A Handbook of Agile Software Craftsmanship that every developer should read; it contains these principles and many more best practices that every developer should have deeply engrained.

Ryan McDermott has a great repo illustrating Clean Code principles (including examples of SOLID) applied to JavaScript.

This is my own cheat sheet, so if you’re already familiar with these principles you might notice that I’ve paraphrased them here, using different wording.

Single Responsibility Principle (SRP)

Each component should do one thing.

Write components that each do exactly one thing. Any related tasks should be factored out into their own components, and composed together.

If your component’s name has the word “and” in it, it’s a sign you need to break that component into separate parts.

Open-Closed Principle (OCP)

A component should be extensible, not modifiable.

Write components that are extensible, so that no one ever has to modify them.

Strategy 1: Write the “what,” and leave the “how” up to the caller.

Strategy 2: Make everything a subclass. The subclasses extend the superclass, which cannot be modified.

I’ve heard it expressed that “modification is the ‘most insulting’ thing you can do to a component.” This is why we have regression testing, why good engineer prefer the lightest touch, and why you should ideally have complete test coverage in place before you perform major reconstructive surgery (a.k.a. ‘refactoring’).

Liskov Substitution Principle (LSP)

You should be able to swap in a subclass without problems.

A subclass must entail superclass behavior. The extension of a component should do everything the original component does.

Subclass output (return values and errors) may be a subset of the superclass, but their interface (methods and their arguments) must be identical.

If you hire a master contractor, but he sends his apprentice instead, the apprentice may be specialized (hanging drywall, maybe), but he needs to correctly handle all of the jobs the master can do to the same standard.

Interface Segregation Principle (ISP)

Create specialized, targeted interfaces.

No component should be forced to depend on methods it does not use.

An (adequate) analogy: if you’re designing a motherboard, don’t combine the printer connection with the monitor connection. If I’m designing a monitor, I don’t want to have to care about printers.

Dependency Inversion Principle (DIP):

Inject everything a function needs to do it’s job, and no more.

Pass dependencies into components, rather than load them globally.

A component should not know any more about the world than it needs in order to fulfill it’s single purpose.

See any native function that takes a callback like It doesn’t need to know anything more than:

  1. the fact that it needs to iterate over an input array,
  2. the fact that it needs to produce a new output array,
  3. the specific way you want it to accomplish (2) given (1).

.map’s only dependency, then, is (3): how exactly it should map the values. So we pass it in as a callback.

This principle is analogous to a “need-to-know” security clearance for classified information, or the “principle of least privilege.”

If a component just needs a value, not the entire object containing the value, then just hand it the value.

If you’re just hammering a nail in, you don’t need to retreive the entire toolbox from the garage. Just bring the hammer.

CLI Management with Navi

If you’re sick of looking through your shell history to find a command to modify and reuse, check out Navi.

Navi is an “interactive cheatsheet tool for the command-line.” You create lists of commands (called “cheats”) you want quick access to. These lists can be grouped by concern (git, ssh, etc.). You can also define the variables within each command.

When you need a command, run navi and start typing a partial command or the description you wrote in your command list. Select the command, and if it has any variables defined Navi will prompt you for those values.

Navi basically allows you to create easy-access templates for the commands you use most often. A good use case is to add anything you’ve had to look up more than once in the last month.

Navi comes with 19 pre-built lists of commands (git, docker, kubernetes, mysql, etc.)

Navi example

The only thing I dislike about Navi is that the command doesn’t also result in a history entry, but this is something that could probably be easily patched.