Naturally I asked ChatGPT what my options were to containerize or run the agent in some kind of sandbox. To my surprise there was no consensus in the community on what the ideal approach is here. My guess is that there’s so much variance in personal preferences, security concerns or even company-mandated policies that there’s no general-purpose approach that can be recommended to everyone.

These were the requirements I had in mind while looking for an approach:

• I prefer running the software I’m developing locally, with as little indirection as possible
• I want to use the agent as a companion on my computer, and review and edit its output directly in my editor of choice
• I don’t want to allow the agent to independently install software on my computer without my explicit approval
• I don’t want the agent to access any environment variables or credentials on my machine that are unrelated to the project it’s working on
• I want the agent to be able to build, run tests and run the application it is working on. This will almost always mean that it needs to be able to run Docker containers (e.g. to run a database)

Landing on Docker Sandboxes

After searching for a bunch of approaches I found Docker Sandboxes to meet all my requirements. Docker Sandboxes are purposely built for running AI agents and their security model ensures my computer will be safe if Pi ever goes rogue.²

Pi is not one of the pre-packaged agents for Docker Sandboxes (at least at the time of writing) but it’s quite trivial to work around that by creating a custom kit. Here’s one provided by the community. The usage is very simple and that will be enough to get you started and safely experiment with Pi.

Finding the edges

The community kit is fine to experiment with the agent for a bit, but I quickly started hitting the edges of the sandbox when using it in real projects.

The main problems were:

• I wanted mise available in every sandbox and not have to install it every time I created a new sandbox.
• I wanted to start Pi from any subdirectory in a repo, but still mount the repo root (or else there’s no access to .git, for example).
• I wanted Pi to reuse the same config, prompts, extensions, and AGENTS.md across sandboxes.
• I wanted the sandbox to stay open if Pi crashed or exited, so I could debug interactively.
• I did not want to rely on the AGENTS.md that Docker Sandboxes ships with, which is polluting the context with troubleshooting instructions for the sandbox itself.

So I decided to create a custom kit that addressed all of the above.

Custom kit

The kit uses the Docker variant of the shell template, to ensure Pi can run Docker containers. It installs the system packages Pi needs, installs a system Node.js to install Pi, and mise for managing project tools.

schemaVersion: "1"
kind: agent
name: pi
displayName: pi
description: "Pi coding agent with mise, running on Docker shell sandbox image"

agent:
  image: "docker/sandbox-templates:shell-docker"
  # Commented out `aiFilename` to prevent this image from including a base AGENTS.md that is too wordy
  # aiFilename: AGENTS.md
  persistence: persistent
  entrypoint:
    run:
      - /usr/local/bin/sbx-pi-entrypoint

# Cannot use memory because `aiFilename` is commented out
# memory:

environment:
  variables:
    LANG: "C.UTF-8"
    LC_ALL: "C.UTF-8"
    # The sandbox proxy enables Node's env proxy support, which emits a noisy
    # experimental Undici warning on every npm/node invocation. Suppress only
    # that warning code so other Node warnings remain visible.
    NODE_OPTIONS: "--disable-warning=UNDICI-EHPA"
    # Host-mounted Pi config directory. The sbx-pi wrapper mounts this path by
    # default so Pi can load shared settings, AGENTS.md, extensions, skills,
    # prompts, themes, etc. Override together with PI_SBX_AGENT_DIR if needed.
    PI_CODING_AGENT_DIR: "/path/to/agent/pi"

commands:
  startup:
    - description: "Update Pi on sandbox startup"
      user: "1000"
      command:
        - /bin/bash
        - -lc
        - |
          set +eu

          pi update
  install:
    - description: "Install base packages needed for mise, npm packages, and native builds"
      user: "0"
      command: |
        set -eu

        export DEBIAN_FRONTEND=noninteractive

        apt-get update && apt-get install -y --no-install-recommends \
          ca-certificates \
          curl \
          gnupg

        install -d -m 0755 /etc/apt/keyrings
        curl --fail --location --show-error --silent https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key \
          | gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
        echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_24.x nodistro main" \
          > /etc/apt/sources.list.d/nodesource.list

        apt-get update && apt-get install -y --no-install-recommends \
          git \
          openssh-client \
          build-essential \
          nodejs \
          fd-find \
          pkg-config \
          python3 \
          python3-pip \
          unzip \
          xz-utils

        if command -v fdfind >/dev/null 2>&1 && ! command -v fd >/dev/null 2>&1; then
          ln -s /usr/bin/fdfind /usr/local/bin/fd
        fi

        # Keep package indexes for live/interactive sandboxes so later ad-hoc
        # apt-get install commands do not require another apt-get update.
        apt-get clean

    - description: "Install mise"
      user: "1000"
      command: |
        set -eu

        mkdir -p /home/agent/.local/bin /home/agent/.config/mise
        curl --fail --location --show-error --silent https://mise.run | sh
    - description: "Install sandbox entrypoint wrapper"
      user: "0"
      command: |
        set -eu

        cat > /usr/local/bin/sbx-pi-entrypoint <<'EOF'
        #!/usr/bin/env bash
        set +e

        # Configure Git SSH signing from the forwarded SSH agent at runtime.
        # The SSH agent socket is available in interactive runs, but may not be
        # available when Docker Sandboxes executes kit startup commands.
        signing_key="$(ssh-add -L 2>/dev/null | head -n 1 || true)"
        if [ -n "$signing_key" ]; then
          git config --global commit.gpgsign true
          git config --global tag.gpgsign true
          git config --global gpg.format ssh
          git config --global user.signingkey "key::${signing_key}"
        else
          echo "No SSH public key available from ssh-add; skipping Git SSH signing config." >&2
        fi

        # Start Pi in the directory where sbx-pi was invoked on the host
        original_pwd="${PI_SBX_ORIGINAL_PWD:-}"
        if [ -n "$original_pwd" ] && [ -d "$original_pwd" ]; then
          cd "$original_pwd"
        fi

        # Pi runs commands non-interactively, so use mise shims for the
        # inherited environment. Install the active project toolset after cd so
        # .tool-versions/mise.toml in the project is detected.
        eval "$(/home/agent/.local/bin/mise activate bash --shims)"
        mise install --yes || true

        pi "$@"
        status=$?

        echo
        echo "pi exited with status ${status}; dropping into sandbox shell."
        echo "Run 'exit' to close the sandbox session."
        echo

        # If Pi exits and we drop into a shell inside the sandbox, put that
        # shell in the same original directory too.
        if [ -n "${original_pwd:-}" ] && [ -d "$original_pwd" ]; then
          cd "$original_pwd"
        fi

        # Prefer normal PATH activation for the fallback interactive shell.
        eval "$(/home/agent/.local/bin/mise activate bash)"

        exec /bin/bash -l
        EOF

        chmod 755 /usr/local/bin/sbx-pi-entrypoint

    - description: "Install Pi globally"
      user: "1000"
      command: |
        set -eu

        npm install -g @earendil-works/pi-coding-agent
        pi --version || true

Pi config

I created a shared folder that holds the Pi configuration files. Every sandbox mounts it at the same absolute path, so Pi uses the same settings, prompts, extensions, and instructions no matter which project I am working on.

My AGENTS.md is intentionally short and describes the sandbox-specific assumptions:

## Environment

You run in a Docker sandbox with internet access. The workspace is mounted at its host path.
`sudo` is passwordless. Docker is available; nested containers are isolated in the microVM.

Prefer `mise` for project tooling and expose build/test/run commands as mise tasks; use `hk` for git hooks. For one-off
tools, prefer ephemeral execution, e.g. `uv run --with <pkg>`, instead of system installs.

## Work style

Ask clarifying questions only when needed to avoid likely rework.
Fix root causes rather than symptoms.
For bugs, reproduce the issue first when practical; prefer regression tests when the repo supports them.
Before finishing, verify the result; if verification is unclear, ask the user.

Do not revert unexpected user/agent changes. Work around them; if they block you, ask before stashing or reverting.
Ask before destructive actions such as deleting large paths, resetting history, or discarding changes.

## Communication

Be direct. Say when you do not know something or when a request seems wrong.
When asking for guidance, present options and a recommendation.
Use ASCII diagrams when they make complex flows clearer.

## Security

Treat secrets, tokens, credentials, private keys, and `.env` files as sensitive.
Prefer local files and official docs before internet searches. Do not pipe remote scripts to shells without inspection.

Sandbox launcher script

To make life a bit easier I created a launcher script for sandboxes that hides the complexity of creating the sandbox, mounting the required directories, ensuring the git repository root is also mounted and that existing sandboxes are reused. I turned this script into a shell alias (spi, as in sandboxed-pi) that I’m able to run from any directory.

#!/usr/bin/env bash
set -euo pipefail

# Run the pi Docker Sandbox kit from anywhere.
# Defaults to this dotfiles checkout's kit, but can be overridden with PI_SBX_KIT.
KIT="${PI_SBX_KIT:-/path/to/sbx/kits/pi}"
AGENT_NAME="${PI_SBX_NAME:-pi}"
ORIGINAL_PWD="$PWD"

# If invoked from inside a Git repository, use the repository root as the
# primary workspace so the whole repo is mounted into the sandbox. This script
# does not cd, so the host shell remains wherever sbx-pi was invoked from. The
# sandbox entrypoint cd's back to ORIGINAL_PWD before starting Pi.
if GIT_ROOT="$(git -C "$ORIGINAL_PWD" rev-parse --show-toplevel 2>/dev/null)"; then
  WORKSPACE_DIR="$GIT_ROOT"
else
  WORKSPACE_DIR="$ORIGINAL_PWD"
fi

PROJECT_NAME="$(basename "$WORKSPACE_DIR")"
SANDBOX_NAME="${PI_SBX_SANDBOX_NAME:-${AGENT_NAME}-${PROJECT_NAME}}"
PI_SBX_AGENT_DIR="${PI_SBX_AGENT_DIR:-/path/to/pi-agent}"

if ! command -v sbx >/dev/null 2>&1; then
  echo "sbx-pi: 'sbx' command not found in PATH" >&2
  exit 127
fi

if [ ! -f "$KIT/spec.yaml" ]; then
  echo "sbx-pi: kit not found: $KIT" >&2
  echo "Set PI_SBX_KIT to the directory containing spec.yaml." >&2
  exit 1
fi

args=("$AGENT_NAME" --kit "$KIT")

# Keep the Git repository root as the primary workspace when called from inside
# a repo, otherwise keep the caller's current directory. Extra workspaces follow
# it, so the sandbox starts in the project rather than in the shared Pi config
# directory.
args+=("$WORKSPACE_DIR")

# Mount the shared Pi config directory as an additional workspace. Docker
# Sandboxes mount workspaces at their absolute host paths, matching the
# PI_CODING_AGENT_DIR configured in the kit.
#
# Set PI_SBX_AGENT_DIR= to disable this automatic mount, or point it at a
# different host-side Pi config directory if you also override the kit env var.
if [ -n "$PI_SBX_AGENT_DIR" ]; then
  if [ ! -d "$PI_SBX_AGENT_DIR" ]; then
    echo "sbx-pi: shared Pi config directory not found: $PI_SBX_AGENT_DIR" >&2
    echo "Set PI_SBX_AGENT_DIR= to disable, or create the directory." >&2
    exit 1
  fi

  args+=("$PI_SBX_AGENT_DIR")
fi

args+=("$@")

set_sandbox_env() {
  sbx exec -d "$SANDBOX_NAME" bash -lc '
    set -e
    original_pwd=$1
    file=/etc/sandbox-persistent.sh
    tmp=$(mktemp)
    if [ -f "$file" ]; then
      grep -Ev "^export (PI_SBX_ORIGINAL_PWD|GIT_DISCOVERY_ACROSS_FILESYSTEM)=" "$file" > "$tmp" || true
    fi
    printf "export PI_SBX_ORIGINAL_PWD=%q\n" "$original_pwd" >> "$tmp"
    printf "export GIT_DISCOVERY_ACROSS_FILESYSTEM=1\n" >> "$tmp"
    cat "$tmp" > "$file"
    rm -f "$tmp"
  ' bash "$ORIGINAL_PWD"
}

# If the sandbox already exists, run it by name. Recent sbx versions reject
# passing workspace arguments to an existing sandbox.
if sbx ls --quiet | grep -qxF "$SANDBOX_NAME"; then
  set_sandbox_env
  existing_args=("$SANDBOX_NAME" --kit "$KIT")
  existing_args+=("$@")
  exec sbx run "${existing_args[@]}"
fi

create_args=("${args[@]}" --name "$SANDBOX_NAME")
sbx create "${create_args[@]}"
set_sandbox_env
exec sbx run "$SANDBOX_NAME" --kit "$KIT" "$@"

Final thoughts

I had to iterate a lot in order to land on this configuration of sandboxes and I haven’t yet used them in very complex projects. The good news is that with an agent like Pi it’s really simple to state your vision and let it build the necessary scaffolding to make your life easier. The project is still in Early Access so it’s likely that it will keep getting improved to a point where a lot of this is not necessary.

As for Pi, it’s really as great as they say! You can use a Codex subscription to get frontier model tokens at a discount, but you get to use your custom-built harness. That might not sound like much. After all, won’t the Claude Code or Codex team be much better at building a harness than yourself? They might be better at creating a general-purpose one, but if you don’t care about MCPs, subagents, remote access, plan-mode, you’re paying a context penalty on all your tasks for features you never use. ³

The prediction that AI will lead to software engineers being replaced — presumably, by product managers, designers, or anyone able to articulate creative thoughts to an LLM — has been around for a while, and as models get better, the prediction only seems to get more popular.

Naval predicts otherwise. Software engineers will be able to use AI to increase their productivity and will be able to leverage the tooling around it like no one else. They’ll run circles around anyone that doesn’t know how to code or never maintained a complex application for the long term. That will get reflected in the quality of the end product. Naval has a great line on that: “there’s no demand for average”. The best apps will win over all the vibe-coded alternatives.

And then he goes even further. Not only will software engineers not get replaced, they will be the ones doing the replacement. AI as a lever can increase their productivity by so much that they’ll be able to go after even more industries.

I think Naval is right. But while this view is optimistic for the future of engineers in the industry, it also makes it very clear how important it is to turn AI into a productivity multiplier. Engineers that are skeptical of AI will have no edge over everyone else using the ever improving models.

In 2021 I had a short, company-mandated stint with macOS, and it went badly enough that I swore I’d never touch it again. Looking back, most of it was self-inflicted: I tried to force my Linux workflow and keyboard shortcuts into macOS, used an external keyboard whose layout was not Mac-compatible and then made it worse by remapping keys like Cmd and Ctrl in an attempt to bring some familiarity back. I also really, really missed a tiling window manager. Unsurprisingly the whole thing didn’t work and I switched back to Linux as soon as I could.

By the beginning of 2025, a few things had changed:

• I stopped caring about using a tiling window manager. My setup made context-switching too easy: one shortcut to change workspaces and suddenly I’m “taking a quick look” on slack whenever something gets hard or boring.
• The performance difference between my laptop and the Macbooks was very noticeable: running a linter on my company’s main monorepo was taking 2-3x more time than on my colleagues’ Macbooks.
• I missed the ecosystem: my AirPods never quite worked on Linux (to be fair, I didn’t fight it much), some apps like Slack or Spotify were clearly second class on Linux
• LLMs were clearly an industry changing technology and apps like ChatGPT or Claude did not exist on Linux. Although in retrospect these apps weren’t that important I really didn’t want to miss out on the bleeding edge of the industry and Linux was clearly not being treated as a first class target of app developers.

So I switched to a MacBook Pro M4. And, annoyingly for my past self, it’s been great: everything is fast, the screen is so good that I ditched my external monitor, and the keyboard + trackpad combo is excellent.

The biggest difference this time is that I didn’t try to “fix” macOS into Linux. No key remaps, no forcing it. I just learned the shortcuts and everything clicked right away.

As the saying goes: never say never.

Setup

• Install Ghostty terminal emulator.
• Install Xcode Command Line Tools with xcode-select --install
• Install Homebrew
• Disable Spotlight hotkey. Install Raycast.
• Install ohmyzsh to manage zsh (default macOS shell)
• Install zsh-peco-history to improve shell history search using Ctrl+R.¹
• Install mise to manage different versions of tooling (node, python, ruby, etc)
• Install Jetbrain’s toolbox app to manage all IDE’s I use
• Install claude code.
• Setup zsh aliases.²
• Setup ssh for Github and create a GPG signing key
• Setup macOS keyboard with the help of https://mac-key-repeat.zaymon.dev/
  • defaults write -g InitialKeyRepeat -int 12
  • defaults write -g KeyRepeat -int 1
• Change Finder settings
  • chflags nohidden ~/Library to show Library folder
  • defaults write com.apple.finder AppleShowAllFiles -boolean true to show hidden files
  • defaults write com.apple.finder ShowPathbar -bool true to show path bar

That idea stuck with me and, over the years, I’ve been applying it way beyond the type system. It has helped me build and maintain resilient systems, preventing bugs that would otherwise be much harder to find.

Impossible states

An impossible state is a state that should have no way of being represented according to your system’s requirement.

Take these two basic requirements, for example:

• All users in my system have an email
• An order cannot be shipped if no payment has been confirmed

Which results in the following impossible states:

• User exists in the system without email
• An order has been shipped without payment confirmation

How can we design a system so that these theoretically impossible states are indeed impossible?

Database schema design

When defining a relational database table schema, we need to choose the types of the columns, define primary keys, foreign keys, column nullability, and constraints. These are all tools we can use to make our model conform to the requirements. If all users of our application are expected to have an email but the users table has a nullable email column then the requirements are not properly enforced. A theoretical impossible state is effectively possible.

What if the “Sign Up” flow is validating the email ensuring that no users can be created without an email?

There are a few assumptions in that line of thinking:

1. There are no bugs in that flow that could allow users to register without an email
2. There is no bug in dealing with the payload the client sends to the application
3. No one will delete the email in a different application flow after it is created
4. No one will access the database and manually delete it

If the email column is not nullable then all the above can still happen, but they will result in an error, we’ll be alerted and fix whatever hole allowed the error to happen. We’ll catch bugs earlier and make it impossible to have users without emails in our system.

The alternative scenario, where we don’t catch these issues immediately, is that we now have an impossible state in our system that we’re not yet aware of. We’ll have all kinds of flows built with the assumption that an email will always be present which will break when they run.

But when will that happen? If we’re lucky, it’ll happen soon. Otherwise, it can happen months down the line, and we’ll be left wondering how that happened. Was there a fault in the sign-up flow at the time the user was created? Is the fault still present or has it been fixed in the meantime? How do we remediate this? Can we delete the user, force them to fill an email, or will the system need to handle users without emails from now on?

Application code

Here’s a very simplified implementation of an attemptDelivery method, that moves a package status from preparing to in_transit.

type PackageStatus = "preparing" | "in_transit" | "delivered";

interface Package {
  status: PackageStatus;
  update(fields: { status: PackageStatus }): void;
}

function attemptDelivery(pkg: Package): void {
  switch (package.status) {
    case "preparing":
      package.update({ status: "in_transit" });
      break;
    case "in_transit":
      // No-op
      break;
    case "delivered":
      throw new Error("Cannot attempt delivery of already delivered package");
  }
}

This implementation does a good job of declaring its assumptions: instead of assuming the package’s status will be preparing it exhausts all the possible status values and deals with them accordingly. It even documents an impossible state: the attemptDelivery action should never be called for packages that already have been delivered. We could argue the same should apply to in_transit but making the operation idempotent seems reasonable. By raising an error, this state is getting flagged as an issue which can be investigated and fixed.

While this approach handles all the possible statuses as of now, what would happen if a waiting_payment status was to be added in the future? An impossible state is now permitted to go through. The operation that attempts a delivery will not fail for a package that was not yet paid, which is problematic. A good way to defend against such a scenario is to always exhaust the switch statement options and use the default branch to raise awareness of impossible states:

function attemptDelivery(package: Package): void {
  switch (package.status) {
    case "preparing":
      package.update({ status: "in_transit" });
      break;
    case "in_transit":
      // No-op
      break;
    case "delivered":
      throw new Error("Cannot attempt delivery of already delivered package");
    default:
      throw new Error(`Impossible state: status ${package.status} not recognized`);
  }
}

The same can be said for if-else scenarios. Say we have a package that has either a tracking_id or an external_tracking_url.

function trackingUrl(): string {
  if (package.trackingId) {
    return getTrackingUrl(package.trackingId);
  } else {
    return externalTrackingUrl();
  }
}

What happens when both tracking_id and external_tracking_url are not present? The assumption is that one will exist, but that might not always be true. Exhausting all the options via else if is the more defensive approach protecting against impossible states.

function trackingUrl(): string {
  if (package.trackingId) {
    return getTrackingUrl(package.trackingId);
  } else if (externalTrackingUrl()) {
    return externalTrackingUrl();
  } else {
    throw new Error("Impossible state: both tracking_id and external_tracking_url are missing");
  }
}

Closing thoughts

These examples are some of the patterns I regularly use to prevent those impossible states as early as possible.
Still, these are as basic as it gets. Complex software systems have lots of intertwined requirements, which makes it much more difficult to avoid impossible states.

I usually ask these questions when designing new flows:

• “What invalid states could this flow be allowing?”
• “Which assumptions do I currently have that aren’t properly enforced?”

I find them good prompts to help me spot edge cases. Addressing those edge cases makes the software I build far more resilient.

Bugs still happen all the time. I just find them much sooner. And it always makes me smile when I see an alert with a message starting with “Impossible state”, because it means I just prevented a bunch of trouble down the line.

Pioneering Practices

1. Have a bold purpose
2. Get the message to everyone
3. Hire for culture, train for skills
4. Measure impact, track progress, share it widely
5. Put your money where your mouth is

Notes

Chapter mostly focused on Patagonia and how they put purpose above profits and how that drives a lot of their business decisions (sustainable materials, donating to non-profits, etc.). Argues that employees are more engaged/driven when working for companies with clear purposes instead of just maximizing profits.

Chapter 2: From Hierarchical Pyramid to Network of Teams

Pioneering Practices

1. Inverted pyramid
2. Autonomous teams in pyramid
3. Flat organization with autonomous teams
4. Network of teams
5. Ecosystem of mini companies

Notes

• Haier (chinese home appliances/electronics company) organizes their 70,000 employess into 4,000 mini-companies
• Handelsbanken (Netherlands bank) gives complete autonomy to local branches: as far as allowing decisions over which products are offered, how they’re marketed or priced

Chapter 3: From Directive to Supportive Leadership

Pioneering Practices

1. Beware of HiPPos (highest paid person opinions)
2. Destroy the ivory tower
3. Evaluate your manager
4. Split managers
5. Choose your leader

Notes

• “Park your hierarchy at the door” when going into a meeting
• Drop status symbols (corner office, reserved parking space)

Chapter 4: From Plan & Predict to Experiment & Adapt

Pioneering Practices

1. Ruthlessly experiment
2. Kill the budget cycle
3. Create a “safe-to-try” environment
4. Crowdsource experiments
5. Rebel Time (10% hacking time at Spotify, 20% time at Google)

Notes

• “I let go of the naive belief that the world in which we work can be predicted or that every detail can be planned” - Koldo Saratxaga, K2K
• Some Spotify squads have Fail Walls where they post their failures and learnings.
• “We would rather spend out time and energy on adjusting, and quickly recovering, than on futile attempts to predict the future.” - Katarina Berg, Spotify

Chapter 5: From Rules & Control to Freedom & Trust

Pioneering Practices

1. Design your own workplace
2. Results-based working
3. Remove control mechanisms
4. Peer Review
5. Self-Setting Salaries

Notes

• Many agree that around 3% of the workforce is likely to take advantage of the system. Rules implemented to keep the 3% in line stifle the productivity, autonomy and joy of the other 97%.
• One of the main reasons of burnout is the lack of autonomy and control over your own work.

Chapter 6: From Centralised to Distributed Authority

Pioneering Practices

1. Map decision-making
2. Change the language
3. Push authority down
4. Pre-approval
5. Advice process

Notes

• Pre-approval: Leader/manager approves something in advance, before employee made actual decision or found solution. Employee has full autonomy as long as decision fits within pre-defined boundaries: time, cost, requirements.
• Advice process:
  • Someone tries to solve a problem or make a decision
  • They seek advice from people with expertise or experience
  • Advice can be accepted or rejected. You have the final say.
  • All involved are informed of the decision taken
• Consensus is overrated. It’ll slow you down and the solution will end up being a compromise that no one is happy with.

Chapter 7: From Secrecy to Radical Transparency

Pioneering Practices

1. Open communication
2. Openness as the default
3. Transparent performance and goals
4. Open-book management
5. Salary Transparency

Notes

• All information is public (internally) unless there’s a very good reason not to

Chapter 8: From Job Descriptions to Talent & Mastery

Pioneering Practices

1. Identify talents
2. Job crafting by combining roles
3. Unlimited training
4. Self-selected mentors
5. Internal project marketplace

Whichever latest LTS version of Ubuntu.

Terminal

I use Terminator as my terminal.

sudo apt install terminator

Shell

zsh is my preferred shell. ohmyzsh manages its configuration.

sudo apt install zsh

History

I use zsh-peco-history to improve shell history search using Ctrl+R, with the following configuration:

# .zshrc

HISTSIZE=10000000
SAVEHIST=10000000

setopt EXTENDED_HISTORY          # Write the history file in the ":start:elapsed;command" format.
setopt INC_APPEND_HISTORY        # Write to the history file immediately, not when the shell exits.
setopt SHARE_HISTORY             # Share history between all sessions.
setopt HIST_EXPIRE_DUPS_FIRST    # Expire duplicate entries first when trimming history.
setopt HIST_IGNORE_DUPS          # Don't record an entry that was just recorded again.
setopt HIST_IGNORE_ALL_DUPS      # Delete old recorded entry if new entry is a duplicate.
setopt HIST_FIND_NO_DUPS         # Do not display a line previously found.
setopt HIST_IGNORE_SPACE         # Don't record an entry starting with a space.
setopt HIST_SAVE_NO_DUPS         # Don't write duplicate entries in the history file.
setopt HIST_REDUCE_BLANKS        # Remove superfluous blanks before recording entry.

Aliases

I make heavy use of aliases on my ~/.zshrc file to help me navigate to common directories or open projects on the appropriate IDE. Some examples:

export EDITOR='vim'

# .zshrc
alias ezshrc="$EDITOR $HOME/.zshrc"
alias szshrc="source $HOME/.zshrc"

# projects
export PROJECTS_HOME="$HOME/projects"
export AOC="$PROJECTS_HOME/aoc-2022"

alias aoc="cd $AOC"
alias iaoc="launch_rubymine $AOC"

# functions
launch_rubymine() {
        nohup $HOME/bin/rubymine $1 > /dev/null 2>&1 &
}

I can type ezshrc from anywhere in my terminal to edit my zsh config file and then szshrc to source it.

I can also type aoc to access the root of my Advent of Code project or iaoc to open the project in RubyMine.

Window Manager

i3wm is my preferred tiling window manager. Regolith provides a bunch of sane defaults for i3 on Ubuntu, so that’s I use in order to simplify my setup.

Regolith install instructions.

Regolith Config

# ~/.config/regolith3/i3/config.d/40_workspace-config

# Custom Bindings
bindsym $mod+m move workspace to output left
bindsym Ctrl+Shift+Print exec --no-startup-id maim --select | xclip -selection clipboard -t image/png

# Workspace assignment

## Notion Chromium App
assign [instance="crx_jpebhcbfinglhpgbfclggnfppgbkklnh"] $ws8

assign [class="thunderbird"] $ws1
assign [class="Slack"] $ws3
assign [class="Google-chrome"] $ws4
assign [class="jetbrains-rubymine"] $ws5
assign [class="jetbrains-idea"] $ws6
assign [class="jetbrains-datagrip"] $ws7

# workaround for spotify
for_window [class="Spotify"] move container to workspace $ws9

# ~/.config/regolith3/Xresources

gtk.font_name: Ubuntu
gtk.monospace_font_name: Ubuntu Mono
i3-wm.font: Ubuntu Mono

wm.workspace.01.name: 1: 1: Email
wm.workspace.02.name: 2: 2: Terminal
wm.workspace.03.name: 3: 3: Slack
wm.workspace.04.name: 4: 4: Chrome
wm.workspace.05.name: 5: 5: IntelliJ
wm.workspace.06.name: 6: 6: RubyMine
wm.workspace.07.name: 7: 7: Datagrip
wm.workspace.08.name: 8: 8: Notion
wm.workspace.09.name: 9: 9: Spotify
wm.workspace.10.name: 10: 10:
wm.workspace.11.name: 11: 11:
wm.workspace.12.name: 12: 12:
wm.workspace.13.name: 13: 13:
wm.workspace.14.name: 14: 14:
wm.workspace.15.name: 15: 15:
wm.workspace.16.name: 16: 16:
wm.workspace.17.name: 17: 17:
wm.workspace.18.name: 18: 18:
wm.workspace.19.name: 19: 19:

asdf

I use asdf to manage different versions of tools (Ruby, Python, Node, etc) on my machine.

IDE

I use Jetbrain’s toolbox app to manage all IDE’s I use.