DEV Community: Garrin Costa, Jr.

Audio Development and C++

Garrin Costa, Jr. — Thu, 16 Jul 2026 18:04:00 +0000

Introduction

I came into programming from a background in music production and audio engineering. I'd been interested in programming for a long time, but only in the last couple of years have I dug in seriously, working primarily in JavaScript and its libraries and frameworks. I wanted to go deeper and there are so many compelling paths. Of all of them, C++ emerged as a logical next step.

Coming from JavaScript, C++ felt more familiar than I expected. Both derive their basic syntax from C, so control structures like if-else and for loops look familiar. Both support object-oriented programming through classes and methods, and both support functional concepts like first-class functions and closures. But what really caught my attention was noticing the role C++ was playing in audio development. Once I started looking, it kept turning up, in the plugins I use and in the DAWs that host them.

So what makes C++ so widely used in this area? What problems arise in audio development that C++ solves, and what makes it well-suited to solve them?

C++, briefly

C++ was designed by Bjarne Stroustrup at AT&T Bell Labs and had its first commercial release in 1985, as an extension of C with object-oriented features added on top. It has since expanded to include functional features and facilities for low-level memory manipulation. It compiles ahead of time to machine code rather than being interpreted at runtime, and it is standardized internationally as ISO/IEC 14882, maintained by the ISO/IEC working group JTC1/SC22/WG21.

Audio processing and deadlines

Audio processing runs on a fixed deadline. In the browser, for example, the Web Audio API processes sound in blocks of 128 sample-frames, which works out to roughly 3ms of audio at a sample rate of 44.1kHz (128 samples ÷ 44,100 samples per second ≈ 2.9ms). If a block isn't finished before the next one is needed, the hardware is forced to play back stale data, silence, or interpolated samples, resulting in audible clicks, pops, or dropouts. Everything below follows from this constraint.

Garbage collection

Languages with a garbage collector, including JavaScript, clean up unused memory automatically. A background process decides when to run, and while it runs it can pause the whole program. The pause is brief, but its timing and length are unpredictable, and under a deadline of a few milliseconds, the risk of running into even a brief pause is unacceptable.

This is a major problem that C++ solves, as it has no garbage collector. A program allocates and frees memory as needed, happening exactly where the programmer writes them, rather than being left to the timing of a background process. The catch is that allocating can itself take an unpredictable amount of time, so real-time audio code goes a step further and moves every allocation out from under the deadline, doing it all before playback begins.

JUCE, a C++ framework for building audio plugins, builds its plugin structure around this. Its AudioProcessor class gives a plugin two functions with two different jobs. prepareToPlay() runs once, before playback starts, and the host tells it roughly how large the audio blocks are going to be. That's the moment the plugin sets aside all the memory it will need, mainly its buffers, the arrays that hold each block of samples while the plugin works on them. processBlock() then runs over and over during playback, once per block, under the deadline, doing the actual audio processing with memory that already exists. Since nothing in C++ allocates except what the code explicitly allocates, keeping every allocation in prepareToPlay() leaves processBlock() with no hidden step that could stall it, ensuring no calls to new, malloc, or vector reallocations occur during playback.

Avoiding locks on the audio thread

The garbage collection problem above is about one kind of unpredictable pause. Another kind comes from threads.

A thread is a single sequence of instructions that a CPU executes, one after another. A program can run more than one thread at once, each with its own place in the code, while sharing access to the same memory. This is how an audio plugin is built. One thread might run the user interface (drawing knobs, handling clicks), and a separate audio thread is called by the host repeatedly to fill each block of samples. Both run at the same time, possibly on different CPU cores, and both can see the same variables.

This situation is less common in standard JavaScript, where the main execution thread processes one statement at a time via an event loop. While Web Workers and AudioWorklets now allow multi-threading in the browser, the standard model for UI and logic remains single-threaded, whereas C++ audio plugins require parallel threads for UI and DSP from the start. An audio plugin's UI and audio threads run in parallel, and any data they share has to be coordinated.

Two threads reading and writing the same variable at the same time can corrupt it. One way to prevent this is through a mutex, short for mutual exclusion, which is a lock that guarantees only one thread can access a piece of shared data at a time. A thread has to acquire the lock before it can touch the shared data. If another thread already holds the lock, the second thread waits until the first releases it with an unlock operation.

Mutexes are a standard synchronization tool in most multithreaded software, and for good reason. However, for audio code, the wait behavior of a mutex creates a major problem because it has no time limit. When the audio thread needs a lock that the UI thread happens to be holding, and the UI thread gets paused by the OS scheduler or just takes longer than expected, the audio thread sits blocked for as long as that takes, and the deadline passes. This failure mode, where a high-priority thread ends up waiting on a low-priority one, is called priority inversion, and it's the main reason real-time audio code avoids mutexes.

For passing a single value between the two threads, like a plugin parameter, the common alternative to a mutex is an atomic variable. At the lowest level, std::atomic wraps a variable to ensure that read and write operations are indivisible. When you call load() or store() on an atomic variable (like std::atomic<float> as opposed to plain float), the compiler translates this into a single CPU instruction that cannot be interrupted. A plugin's gain parameter, for example, would be declared as a std::atomic<float>. When the user moves the gain knob, the UI thread writes a new value into it. Each time the audio thread runs processBlock() to fill a block of samples, it reads the current value and applies it to the audio.
To ensure this remains lock-free on all hardware and prevents instruction reordering, production code typically uses std::memory_order_release on the write and std::memory_order_acquire on the read.

No mutex is needed because of what "atomic" guarantees. An ordinary write to memory can take more than one CPU operation to complete, and a thread reading at the wrong moment can catch the write partway through, picking up a value that is part old number and part new, a number that was never written. That torn value is the corruption a mutex exists to prevent. An atomic read or write completes as a single, indivisible operation, so the audio thread always gets either the complete old value or the complete new one. The protection the lock provided is built into the operation itself, so there's nothing left to guard and no waiting to do. The UI thread writes whenever the user turns the knob, the audio thread reads whenever it needs to, and neither one ever blocks the other. This approach, coordinating threads without any locks, is called lock-free programming, and it's the standard way code running on the audio thread shares data with the rest of the program. To ensure the CPU doesn't reorder these operations and break the logic, production code typically pairs the write with std::memory_order_release and the read with std::memory_order_acquire.

However, while atomics guarantee thread safety, they do not prevent audio artifacts. If the parameter value changes instantly between samples, it creates a discontinuity known as a 'click.' Therefore, the atomic variable should strictly serve as the target value. Inside the audio loop, the processor must read this target and then smoothly interpolate (or 'slew') the actual processing parameter toward it over a few milliseconds, ensuring the audio signal remains continuous even when the control data changes abruptly.

Direct access to plugin SDKs and OS audio layers

Plugin formats are defined as C++ (or C-ABI-over-C++) interfaces. Steinberg distributes the VST3 SDK directly, built on COM-style interfaces implemented in C++. Avid’s AAX format, used by Pro Tools, expects its plugin developers to work in object-oriented C++. Native Instruments maintains ni-media, an open-source C++ library for reading and writing audio streams, and its NKS standard operates as a metadata specification that enriches standard VST3 and Audio Unit plugins with hardware integration, keeping them on the same C++ foundation.

Below the plugin formats sit the operating systems' own audio layers, which follow a similar hybrid model. On macOS, Core Audio handles the system's audio through pure C programming interfaces, though Apple provides an optional C++ SDK to wrap these APIs for easier development. On Windows, low-latency audio goes through ASIO, a driver protocol developed by Steinberg, with an SDK likewise written in C/C++. A C++ audio engine talks to the plugin host above it and the operating system below it primarily in its own language. However, to ensure stability across different compilers, these interactions cross ABI boundaries (such as COM on Windows or C-interfaces on macOS), acting as a standardized translation layer that allows C++ code to interoperate safely without binary incompatibility.

Layered architecture

Not everything in audio software is written this way, and the exceptions are informative. Cycling '74's Max/MSP is a visual, patch-based environment. Its SDK supplies the headers, source, and libraries for building external objects (plug-ins) in C or C++, so the underlying engine and its high-performance extensions are C/C++, while the patching layer end users work in is not.

Ableton's Max for Live integration adds another layer of abstraction. While the DSP inside a Max device may still rely on C++ (via the Max engine or gen~), controlling the host application itself happens through the Live Object Model. This is accessed via specific Max objects or a JavaScript interface, meaning the plugin author can script complex interactions with Ableton Live without writing a single line of C++.

This demonstrates a consistent industry pattern: C++ dominates the DSP and engine layers where nanosecond timing is critical, while higher-level scripting layers (JavaScript, Python, Lua) are deliberately used for control logic, UI, and arrangement, as these tasks are not bound by the real-time audio deadline.

Shortcomings

Manual memory management brings inherent risks such as forgetting to free memory, freeing it twice, or accessing it after release. These bugs can be subtle and difficult to track down, often requiring rigorous discipline or modern C++ idioms like RAII to mitigate.

C++ also lacks a standardized ABI (Application Binary Interface), meaning the memory layout of a compiled class or function call is not guaranteed to match across different compilers or versions. Plugin formats must design around this limitation. VST3, for instance, separates the audio processing component (IAudioProcessor) from the UI controller (IEditController) behind defined COM-style interfaces. This creates a stable binary contract—a "translation layer"—that allows a host and plugin to communicate safely without relying on raw C++ class layouts at the boundary.

Finally, the language is significantly more verbose than many modern alternatives. It demands a deep understanding of systems programming concepts, resulting in a steeper learning curve and longer development times compared to higher-level languages.

Open Problems

Audio development also faces challenges that the language itself cannot fix.

Format Fragmentation remains a major hurdle. VST3, AU, and AAX are separate, largely incompatible standards, forcing developers to build and test each plugin multiple times. CLAP, an open, MIT-licensed format launched in 2022 by Bitwig and u-he, was created to solve this. Adoption has grown rapidly: Bitwig, REAPER, and FL Studio now fully support it, with Studio One and Cubase following suit. However, industry giants like Ableton Live, Pro Tools, and Logic Pro still do not support it, ensuring a multi-format world for the foreseeable future.

Denormal numbers represent a lower-level hardware quirk. Extremely small floating-point values near zero can force CPUs into a slow "microcode" path, causing massive performance spikes. Preventing this still falls to the programmer—typically by enabling "flush-to-zero" CPU flags or adding a tiny, inaudible noise floor to the signal—rather than being handled automatically by the language or compiler.

Rust is the most frequently named alternative to C++ for this work. Its ownership system guarantees memory safety without a garbage collector, meeting the same real-time requirements as C++. While early frameworks like nih-plug focused on VST3 and CLAP, newer frameworks (e.g., truce) now offer native support for AU and AAX as well. Despite this technical maturity, Rust’s audio ecosystem remains a fraction of C++’s decades-old library collection. Whether it achieves mainstream adoption depends less on the language itself—which already handles the central requirements—and more on how quickly its ecosystem and tooling fill the remaining gaps.

Summary

Audio code has a few milliseconds to produce each block of samples, and that one constraint accounts for most of what this piece covered. A language running on the audio thread can't have a garbage collector pausing it at unpredictable times, can't afford to wait on locks, and benefits from sharing a language with the plugin formats and OS audio layers it connects to. C++ meets all of those conditions, and the industry's foundations, from VST3 and AAX to Core Audio and ASIO to JUCE, are already written in it. Where the deadline doesn't reach, as in Max/MSP's patching layer and Max for Live's JavaScript API, the same industry uses friendlier languages, which says a lot about why C++ holds the real-time layer in particular. The language costs something in return, in memory bugs, binary incompatibility, and time spent learning it. While new formats like CLAP are gaining traction in FL Studio and Studio One, and languages like Rust now offer native AU and AAX support via frameworks like truce, the work on the audio thread still gets written in C++.

Sources: Web Audio API specification, W3C CR-webaudio-20180918 (w3.org/TR); C++ history and ISO/IEC 14882, en.wikipedia.org and stroustrup.com; JUCE AudioProcessor class reference (docs.juce.com); MDN Web Docs, "JavaScript execution model" and "Concurrency model and Event Loop" (developer.mozilla.org); Ross Bencina, "Real-time audio programming 101: time waits for nothing" (rossbencina.com); Fabian Renn-Giles, "Using locks in real-time audio processing, safely" (timur.audio); Steinberg VST3 SDK (github.com/steinbergmedia/vst3sdk) and VST3 architecture documentation (deepwiki.com/steinbergmedia/vst3_public_sdk); Avid AAX developer/alliance documentation (developer.avid.com); Native Instruments GitHub (ni-media) and NKS developer page (native-instruments.com); Apple Core Audio Overview and Core Audio Essentials (developer.apple.com/library/archive); Steinberg ASIO driver documentation (helpcenter.steinberg.de); Cycling '74 max-sdk GitHub repository; Ableton Help Center, "Controlling Live using Max for Live" (help.ableton.com); CLAP announcement (bitwig.com) and CLAP adoption status (producergrid.com); Rust ownership documentation (doc.rust-lang.org/book); nih-plug ProducerGrid, (CLAP Plugin Format: Everything Music Producers Need to Know in 2026); truce.audio Documentation and GitHub Repository (truce-audio/truce); Intel® 64 and IA-32 Architectures Optimization Reference Manual (Section on MXCSR/FTZ/DAZ flags) or Stack Overflow, "Flushing denormalised numbers to zero".

On Optimization Objectives in Reinforcement Learning

Garrin Costa, Jr. — Thu, 11 Jun 2026 19:26:10 +0000

Reinforcement Learning: Optimization and Objective Methods

There are a few paradigms or methods of training involved in machine learning. Each employs a different approach to presenting a model with data and what the model should do with that input. Reinforcement learning is one such method we will explore in more detail.

In supervised learning, you give the model labeled example data and then test the model with examples it has not yet seen. Think of it like studying with access to an answer key. In unsupervised learning, you give the model unlabeled data and it finds structure. Imagine watching a painting in pointillism render from start to finish. There's no order to it in the beginning. Eventually though, you might start to recognize an image forming. From there you might have an easier time predicting what the finished painting will look like.

Reinforcement learning (RL) takes a different approach, in that there may be no explicit training data provided as examples - labelled or unlabelled. Rather, the input data received comes as progression of its own experience. The agent makes decisions, interacts directly with an environment, and receives feedback as a reward or penalty signal. It is essentially training by trial and error.

(minecraft gif)

By aiming to maximize cumulative reward over time, the agent 'learns' how to behave in a given environment. This seems simple in theory but in practice, it’s one of the harder optimization problems in ML. You’re not minimizing a fixed loss function over a static dataset. The data the agent trains on depends on the actions it took, which depend on the policy it’s currently learning, which depends on the data it collected. It’s circular by design, and that circularity is where most of the difficulty comes from.

What the Agent Is Actually Optimizing

Looking at RL objectives, we have the policy (the agent’s decision-making function), a discount factor between 0 and 1, and the reward at a specific time. The discount factor controls how much the agent weights future rewards versus immediate ones. If it is too low, it becomes concerned with only the next reward. Too high and it treats rewards 100 steps away as nearly equivalent to rewards right now. Balance is generally the ideal.

This works differently from supervised ML objectives like MSE or cross-entropy. Those are computed over a fixed dataset — you know what you’re optimizing against before training starts. In RL, the objective depends on trajectory data the agent generates during training. You’re optimizing a target that shifts as the agent improves, using data the agent collected under an earlier, 'worse' version of itself.

Three Approaches to Optimization

There are three broad families of RL algorithms, each one taking a unique approach addressing policy improvement.

Value-based methods estimate how good each state or state-action pair is, then derive a policy from those estimates. The foundational example here is Q-learning: the agent learns a Q-function — Q(s, a) — that estimates expected future reward for taking action a in state s. Policy improvement is implicit: pick the action with the highest Q-value. The optimization objective is minimizing the Bellman error*, the difference between the current Q-value estimate and the target computed from actual experience.

Policy gradient methods skip the value estimates and optimize the policy directly. They compute the gradient of J(π) with respect to the policy parameters and step in that direction. REINFORCE* is the classic version. The problem that arises here is policy gradients have high variance, especially early in training when the agent has seen little of the environment. The gradient estimates are noisy, and that noise slows convergence.

Actor-critic methods combine both. The actor is the policy and decides actions. The critic is a value function and evaluates how good those actions were. The critic’s estimates reduce variance in the actor’s gradient updates. Most production-grade RL systems — PPO, A3C, SAC — are actor-critic architectures for exactly this reason.

Problems in Practice

Credit assignment: An agent plays a game and wins 200 moves later. Which moves mattered? The reward is clear but the attribution is not. Discount factors and value functions both exist, in part, to address this.

Exploration vs. exploitation: An agent that only takes actions it already knows are good stops learning. An agent that constantly explores won’t converge on anything useful. Balancing these two is a design decision. Common approaches include epsilon-greedy exploration (taking a random action with probability ε) and entropy regularization (adding a term to the objective that rewards taking varied actions).

Sample efficiency: RL needs a lot of experience to learn from. A person can pick up a new video game and achieve competence in under an hour. A RL agent usually needs millions of environment interactions to do something similar. Model-based RL addresses this by building an internal model of the environment and planning ahead from it, rather than learning purely from direct experience.

Reward Design as the Objective Function

Clean mathematical formulation glosses over the fact that in most real RL problems, you don’t have a natural reward function. You must design one. Designing an effective reward function can be painful.

The agent optimizes whatever you give it. If you reward a robot arm for moving toward a target but don’t penalize inefficient paths, it finds paths that increase the reward metric without doing what you wanted. This may not be a bug in the algorithm so much as it is the algorithm working correctly on a poorly defined objective.

A good example comes from OpenAI’s early research: an agent trained to move fast in a simulated environment learned to make itself tall and then fall over repeatedly, because falling generated high velocity without the actual cost of locomotion. The reward function said “go fast,” and it did.

This connects directly to a concept in a supervised ML context where objective functions and performance metrics are often different things. You optimize one to improve the other, and they don’t always agree on which model is best. In RL that gap is almost always present. The reward function you are optimizing is in general terms, an approximation, of the end goal, and the agent will find every corner case where the approximation breaks down.

How This Connects to Standard ML

RL uses the same building blocks covered in core ML such as neural networks as function approximators, gradient descent for parameter updates, regularization to prevent overfitting (entropy terms work similarly to L2 penalties), and held-out evaluation environments that parallel cross-validation. The main difference is the sequential, interactive data collection process.

Standard supervised learning assumes training data is independent and identically distributed. RL violates that assumption constantly. Each action changes the state of the environment, which affects what data gets collected next. The dataset and the model are coupled. That’s what makes RL its own subfield rather than just another model type — but the mathematical machinery underneath it is mostly the same machinery covered everywhere else in ML.

Source material: M. Clark, Models Demystified — Chapter 10: Core Concepts in Machine Learning and Chapter 11: Common Models in Machine Learning

*This is the Bellman equation. It may be simplified even further if the time subscripts are dropped and the value of the next state is plugged in:

V(x)=maxa∈Γ(x){F(x,a)+βV(T(x,a))}.

Know Your Environment: Building Fluency with Shortcuts, Terminals, and Git

Garrin Costa, Jr. — Tue, 02 Jun 2026 14:09:43 +0000

Cmd+C, Cmd+V, Cmd+Z — the basics settle into procedural memory quickly. Beyond that, most shortcuts remain things we intend to learn eventually.

The resources are easy to find. Most applications expose shortcuts directly in their menus, publish reference pages, and allow custom key bindings. Yet a 2005 study by Lane, Napier, Peres, and Sandor found that even experienced users relied on keyboard shortcuts less than 10% of the time, and that time spent using a program had little relationship with keyboard shortcut proficiency. Exposure alone doesn't build skill.

What builds it is intentional repetition — and a willingness to be slower before you're faster. Fitts and Posner's three-stage model of skill acquisition describes the progression: cognitive (active recall, slower execution), associative (familiarity forming, still requires attention), autonomous (fires without thought). Remington, Yuen, and Pashler put a number on the crossover: after roughly 200 repetitions, keyboard shortcuts became consistently faster than menu navigation. A new shortcut might cost you a beat every time you reach for it on day one. By the end of the first week of consistent use, that friction is mostly gone.

For developers working in digital environments all day, the environment itself is part of the work. Every unnecessary trip through a menu is a small interruption. Repeated across a session, across a week, those costs are real — and avoidable.

What follows is a practical reference organized by layer: operating system, browser, VS Code, terminal, and Git. The goal is not completeness, but a high-value subset of shortcuts and workflows that address genuine friction in day-to-day development.

Operating System

Developers move constantly between editors, terminals, browsers, documentation, and communication tools. A handful of OS-level shortcuts reduces the overhead of that navigation significantly.

Purpose	macOS	Windows/Linux
Switch applications	`Cmd+Tab`	`Alt+Tab`
Switch windows (same app)	`Cmd+`	`Alt+Esc`
Open system search	`Cmd+Space`	`Win+S`
Hide application	`Cmd+H`	`Win+D`
Minimize current window	`Cmd+M`	`Win+↓`
Quit application	`Cmd+Q`	`Alt+F4`
Screenshot / screen capture	`Cmd+Shift+5`	`Win+Shift+S`

Spotlight (Cmd+Space) deserves particular attention. It launches applications, locates files, performs calculations, and searches system settings — all without leaving the keyboard or touching the Dock or Finder.

Window Management

macOS Sequoia introduced native tiling via drag-to-edge. For keyboard-driven window management with more control, Rectangle (free) and Magnet (paid) both provide configurable shortcuts for snapping windows to halves, thirds, corners, and specific displays.

A typical development layout — editor on one side, browser or DevTools on the other, terminal on a second display — can be arranged entirely from the keyboard. Once those positions are muscle memory, context switching between tools stops requiring any deliberate navigation.

Browser

Browsers function as documentation readers, debugging environments, and research platforms throughout a development session.

Purpose	macOS	Windows/Linux
Focus address bar	`Cmd+L`	`Ctrl+L`
New tab	`Cmd+T`	`Ctrl+T`
Close current tab	`Cmd+W`	`Ctrl+W`
Reopen closed tab	`Cmd+Shift+T`	`Ctrl+Shift+T`
Switch to tab 1–9	`Cmd+1–9`	`Ctrl+1–9`
Navigate back / forward	`Cmd+[` / `Cmd+]`	`Alt+←` / `Alt+→`
Hard refresh (bypass cache)	`Cmd+Shift+R`	`Ctrl+Shift+R`
Open DevTools — elements	`Cmd+Opt+I`	`Ctrl+Shift+I`
Open DevTools — console	`Cmd+Opt+J`	`Ctrl+Shift+J`
Find on page	`Cmd+F`	`Ctrl+F`

Cmd+Opt+J / Ctrl+Shift+J opens DevTools directly to the console — no clicking through panels. For frontend work specifically, that one earns its place in muscle memory fast.

Cmd+L / Ctrl+L focuses the address bar immediately. Combined with typing a URL or search term and pressing Enter, it removes the mouse from routine browser navigation entirely.

VS Code

Navigation & Interface

Purpose	macOS	Windows/Linux
Open file by name	`Cmd+P`	`Ctrl+P`
Command palette	`Cmd+Shift+P`	`Ctrl+Shift+P`
Global search	`Cmd+Shift+F`	`Ctrl+Shift+F`
Toggle sidebar	`Cmd+B`	`Ctrl+B`
Toggle terminal panel	`Cmd+J`	`Ctrl+J`
New terminal	`Ctrl+Shift+`	`Ctrl+Shift+`
Split editor	`Cmd+\`	`Ctrl+\`
Go to definition	`F12`	`F12`
Rename symbol	`F2`	`F2`
View all keyboard shortcuts	`Cmd+K, Cmd+S`	`Ctrl+K, Ctrl+S`

Cmd+P / Ctrl+P opens any file by name — type a few characters and it filters in real time. With Cmd+B to hide the sidebar and Cmd+J to toggle the terminal, the file explorer panel becomes largely optional.

Cmd+Shift+P / Ctrl+Shift+P opens the command palette. For any action without a memorized shortcut, it's the fastest path.

Cmd+K, Cmd+S opens the full keyboard shortcuts editor. It's worth exploring — and anything that conflicts with existing habits can be remapped there.

Editing

Purpose	macOS	Windows/Linux
Move line up / down	`Opt+↑` / `Opt+↓`	`Alt+↑` / `Alt+↓`
Duplicate line	`Shift+Opt+↓`	`Shift+Alt+↓`
Select next occurrence	`Cmd+D`	`Ctrl+D`
Select all occurrences	`Cmd+Shift+L`	`Ctrl+Shift+L`
Add cursor	`Opt+Click`	`Alt+Click`
Add cursor above / below	`Cmd+Opt+↑/↓`	`Ctrl+Alt+↑/↓`
Add cursors across lines	`Cmd+Opt+Shift+↑/↓`	`Ctrl+Alt+Shift+↑/↓`
Toggle comment	`Cmd+/`	`Ctrl+/`
Column selection	`Shift+Opt+Drag`	`Shift+Alt+Drag`

Multi-cursor editing is worth investing time in. Selecting all occurrences of a variable, renaming across multiple lines simultaneously, or applying the same edit to a column of values — these are the kinds of tasks that used to require find-and-replace or repeated manual edits.

Terminal & Shell

Before building terminal shortcuts, it's worth knowing which shell you're actually in:

echo $SHELL

A shell is the command interpreter between you and the operating system — handling command execution, history, aliases, functions, environment variables, and startup configuration. Most modern macOS installations default to zsh. Personal configuration for zsh lives in:

~/.zshrc

After editing that file, reload it without opening a new terminal window:

source ~/.zshrc

The shortcuts and aliases in this section assume zsh, though most apply equally to bash.

Command Line Navigation

Purpose	Shortcut
Move to line start	`Ctrl+A`
Move to line end	`Ctrl+E`
Delete to line start	`Ctrl+U`
Delete to line end	`Ctrl+K`
Delete previous word	`Ctrl+W`
Search command history	`Ctrl+R`

Ctrl+R initiates a reverse search through command history. Start typing any fragment of a previous command and it surfaces matches interactively — useful for long commands you remember running but don't want to retype.

Useful Commands

Display command history

history
history | grep git

Useful when you remember running a command but not its exact syntax.

Print working directory

pwd

The fastest way to confirm where you are in a directory structure.

View large files

less server.log

Unlike cat, less allows scrolling through large files without flooding the terminal output.

Repeat previous command

!!

A common use case: rerunning a command with elevated privileges after it fails without them:

sudo !!

Shell Customization

Aliases turn repetitive commands into single words. A few practical examples to add to ~/.zshrc:

alias ll="ls -la"
alias gs="git status"
alias gp="git push"

Small improvements compound. A few well-chosen aliases, combined with history search and readline shortcuts, reduce a meaningful amount of low-level friction every time a terminal opens.

Git

Common Commands

git status
git add .
git commit -m "message"
git push
git pull

git status is the most frequently useful of these. When uncertain about the state of a repository — what's staged, what's modified, what branch you're on — it provides an immediate summary.

Aliases

Add these to ~/.gitconfig under [alias]:

[alias]
  st   = status -sb
  aa   = add .
  cm   = commit -m
  ps   = push
  pl   = pull
  lg   = log --oneline --graph --decorate
  undo = reset HEAD~1 --mixed

Or as shell aliases in ~/.zshrc:

alias gst='git status -sb'
alias gaa='git add .'
alias gcm='git commit -m'
alias gps='git push'
alias gpl='git pull'
alias gl='git log --oneline --graph --decorate'

gl is worth calling out specifically. The --oneline --graph --decorate flags render commit history and branch structure in a format that's actually readable — a significant improvement over the default git log output.

Recovery Commands

Most Git commands create history rather than destroy it. A few commands that help when things go wrong:

Inspect unstaged changes

git diff

Review modifications before staging or committing.

Restore a file to its last committed state

git restore filename.js

Save work temporarily without committing

git stash

Useful when switching tasks mid-work. git stash pop restores it.

Switch branches

git switch feature-branch

A more explicit alternative to git checkout for branch switching.

Deliberate Practice

Reading about shortcuts can be useful. Acquiring them requires repetition. Deliberate action.

To accompany this article, I built a small workshop repository designed around that idea. The project walks through common development tasks using the same layers covered here — OS navigation, browser workflows, terminal commands, Git operations, and VS Code shortcuts.

Participants can fork and clone the repository, navigate the filesystem, open the project in VS Code, and complete progressively larger tasks. Instructions are embedded in the project files, and automated tests provide feedback as each task is completed.

Developer Shortcuts Workshop

Start Small

Pick one shortcut — ideally one that addresses something you actually do repeatedly. Use it every time that action comes up, even when it's slower than what you'd normally reach for. That's stage one of the acquisition arc. It's temporary.

By the end of a week of consistent use, the shortcut is close to automatic. At that point, add another.

The environment stops being an obstacle when the tools in it no longer require conscious attention. That happens one shortcut at a time.

Source Notes

Lane, D. M., Napier, H. A., Peres, S. C., & Sandor, A. (2005). Hidden costs of graphical user interfaces: Failure to make the transition from menus and icon toolbars to keyboard shortcuts. International Journal of Human-Computer Interaction, 18(2), 133–144.

"Results showed that shortcut use was very low (less than 10% of the time) and that the number of hours participants had been using the program did not predict the frequency of shortcut use."

Fitts, P. M., & Posner, M. I. (1967). Human Performance. Brooks/Cole.

Original source for the three-stage model of skill acquisition: cognitive, associative, and autonomous. The model describes how a learner moves from effortful, conscious execution of a skill toward automatic execution requiring minimal attentional resources.

Remington, R. W., Yuen, H. W. H., & Pashler, H. (2016). With practice, keyboard shortcuts become faster than menu selection: A crossover interaction. Journal of Experimental Psychology: Applied, 22(1), 95–106. DOI: 10.1037/xap0000069

"It is widely believed that a graphical user interface (GUI) is superior to a command line interface (CLI) for novice users, but less efficient than the CLI after practice. However, there appears to be no detailed study of the crossover interaction that this implies... The predicted crossover was observed after approximately 200 responses. Experiment 2 showed that following training all but 1 subject in the CLI-trained group chose to continue using shortcuts. These results suggest that frequency of shortcut use is a function of ease of retrieval, which develops over the course of multiple repetitions of the command."

Full References

Lane, D. M., Napier, H. A., Peres, S. C., & Sandor, A. (2005). Hidden costs of graphical user interfaces: Failure to make the transition from menus and icon toolbars to keyboard shortcuts. International Journal of Human-Computer Interaction, 18(2), 133–144.
Fitts, P. M., & Posner, M. I. (1967). Human Performance. Brooks/Cole.
Remington, R. W., Yuen, H. W. H., & Pashler, H. (2016). With practice, keyboard shortcuts become faster than menu selection: A crossover interaction. Journal of Experimental Psychology: Applied, 22(1), 95–106. DOI: 10.1037/xap0000069
Fagarasanu, M., & Kumar, S. (2003). Carpal tunnel syndrome due to keyboarding and mouse tasks: A review. International Journal of Industrial Ergonomics, 31(2), 119–136.
Jardina, J. R., Peres, S. C., Nguyen, V., Megasari, A., Griggs, K. R., Pinales, R., & Amos, A. N. (2009). Keyboard shortcut users: They are faster at more than just typing. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 53(15).

What’s Actually Happening When You Use Git

Garrin Costa, Jr. — Mon, 25 May 2026 13:48:05 +0000

I’d been using Git comfortably for months before getting uncomfortable with how little I actually understood.

git add. git commit. git push were memory at this point. But ask me what Git was actually doing under the hood? I couldn’t tell you. I had some (mostly wrong) assumptions but that was about it.

Then I discovered the .git/ directory…

Git Is Not What You Think It Is

Many people think of Git as a “track changes” tool. That’s the way I thought of it. Like the version history in a Google Doc. That’s not wrong, but it’s not the whole picture.

Git’s creator, Linus Torvalds, described it more precisely:

“Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.”

So, what is a content-addressable filesystem?

Instead of storing files by name or location, Git stores them by their content. Every piece of data gets run through a hashing algorithm (SHA-1) that produces a unique 40-character fingerprint. That fingerprint is the file’s identity in Git’s database. The same content will always return the same hash, always.

Understanding this immediately explained much of what felt confusing about Git.

The `.git/` Directory Is Your Entire Repository

Open any Git project and run this:

ls .git/

You’ll see something like:

HEAD    config    description    hooks    info    objects    refs

.git/ is a hidden directory created when a Git repository is initialized.
This directory is your entire repository. Every commit, every version of every file, the full history — all of it lives inside .git/. Your working directory (the files you actually edit) is just a projection of what’s in there.

You can copy .git/ somewhere else, and you’ll have everything. On the other hand, if you delete .git/ you lose your entire history. Not just your latest changes. Everything.
It’s hidden for a good reason, but it is hugely helpful to be aware of it.

Two very important directories:

objects/ — Git’s content database. Every blob, tree, and commit lives here.
refs/ — Pointers. Branch names, tags, remotes. All of them are just pointers to commits in objects/.

Three Objects. One Chain.

Git stores everything as one of three object types. Understanding these three types makes everything else click.

Blob — The File

A blob (Binary Large OBject) is an immutable object with a header. It contains the raw file content and nothing more.
It does not store the filename or its location. It has no reference to itself or any other files.
If one character in a file changes, Git creates a brand new blob with a completely different SHA. The old one stays untouched.

Run this on any blob SHA to see for yourself:

git cat-file -p <blob SHA>

You’ll see the raw file content. No filename. No path. Just the content.

Tree — The Snapshot

A tree object represents a directory. It’s a list of entries — each one containing a file mode, object type, SHA, and filename.

This is where filenames live. The tree connects a name to a blob. Run git cat-file -p on a tree SHA and you’ll see something like:

100644 blob b7aec520dec0a7516c18eb4c68b64ae1eb9b5a5e    README.md

Mode, type, SHA, filename. The tree is the snapshot of your project at a given moment.

Commit — The Pointer

A commit object is simpler than most people expect. Run git cat-file -p on a commit SHA:

tree 7102e6ffc1a508e552d53f28bbeb0a976124d7e6
parent d48a0fbe5c378c69ad9522883d1d2f8dbe5ebd69
author garrin <abcdefg@123.com> 1779654747 -0500
committer garrin <abcdefg@123.com> 1779654747 -0500

second commit

That’s it. A commit is:

A pointer to a tree (the snapshot)
A pointer to its parent commit (the history)
Metadata that includes the author (who made changes/wrote the code) and committer (who made the commit), as well as when the commit was made, and the commit message.

The chain is always:

commit → tree → blob(s)

There’s actually a fourth object type — the annotated tag. I won’t go into detail here, but the annotated tag wraps a commit with its own metadata and SHA, and is often used for marking official releases.

The History Is a Graph, Not a Line

The chain — commit → tree → blob — implies something linear. It isn’t.

Every commit points to its parent. Most commits have one. Merge commits have two. Over time, those parent-child relationships form a DAG: a Directed Acyclic Graph.

Directed means the edges go one way — a commit points to its parent, never the reverse. Acyclic means no loops — you can’t follow the chain and end up back where you started. Graph means the structure branches and rejoins freely.

This is why git log can look like a tree but isn’t one. Trees don’t rejoin. A DAG can. Every time you merge two branches, the merge commit has two parent pointers — two incoming edges — and the graph folds back on itself.

Understanding that Git’s history is a DAG explains a lot: why git log --graph draws forks and merges the way it does, why reachability matters (an object is “live” if you can reach it by following edges from a named ref), and why Git’s garbage collector targets objects with no incoming path from any branch or tag.

The Stuff That Trips People Up

A Branch Is a Text File

Run this:

cat .git/refs/heads/main

You’ll get a single SHA. That’s your main branch. A 41-character text file. That’s the entire concept of a branch in Git — a file containing the SHA of the commit it currently points to.

Creating a branch creates a file. Switching branches changes which file HEAD points to. Deleting a branch deletes the file.

Which brings us to something important.

Deleting a Branch Doesn’t Delete Your Commits

When you delete a branch, you delete the pointer. You do not delete the objects in .git/objects/. The commits, trees, and blobs that branch pointed to are still in the database. They’re just unreachable by name.

You can prove it. Delete a branch, then run git cat-file -p on a commit SHA that was on it. It’s still there.

Git’s garbage collector (git gc) will eventually clean up truly unreachable objects — but not for at least two weeks by default. Which means if you accidentally delete a branch, git reflog can save you.

Staging Already Writes to the Database

Most people think git add just “queues” a file for the next commit. It does more than that.

When you run git add, Git immediately:

Hashes your file content
Creates a blob object
Writes it to .git/objects/
Updates the index (staging area) to track it

The blob is already stored before you ever run git commit. The commit just formalizes it — creating the tree and commit objects that make the blob part of your permanent history.

`git reset` Moves a Pointer. It Doesn’t Delete Data.

git reset --hard <SHA> feels destructive. It’s not — at least not immediately.

What it actually does: moves the branch pointer back to the specified commit. The commits you “reset away” are still in .git/objects/. They’re just unreachable from your current branch.

Run git reflog after a reset and you’ll see every place HEAD has pointed. Your “lost” commits are listed there, recoverable by SHA.

git revert works differently. Instead of moving a pointer, it creates a brand new commit that applies the inverse of a previous commit’s changes. History is preserved. This is why git revert is safe on shared branches and git reset is not — reset rewrites history, revert adds to it.

Merge Commits Have Two Parents

When you merge two branches and there’s a conflict, Git compares three blobs: the common ancestor, your version, and their version. This is called a three-way merge.

If the same lines changed on both sides, Git writes conflict markers to your working directory and waits for you to resolve them. Once you do, git add creates a new blob. Then git commit creates a merge commit — the only commit type with two parent pointers, one for each branch tip.

That two-parent structure is exactly what the DAG looks like in the object database.

Why This Mental Model Matters

You don’t need to know this stuff to use Git day-to-day. But once you do, a few things happen:

Detached HEAD stops being scary. It just means HEAD is pointing directly at a commit SHA instead of a branch name.
Merge conflicts make sense. Two commits changed the same lines. Git can’t pick — it’s asking you to resolve a pointer conflict.
“Lost” commits stop feeling lost. The objects are almost always still there. git reflog is your safety net.
You stop being afraid of git reset, git rebase, and other commands that feel dangerous.
git log --graph stops being decorative. It’s a literal rendering of the DAG — every fork is a branch tip, every convergence is a merge commit.

Git isn’t magic. It’s a content-addressable filesystem with a great interface. A few text files, a database of hashed objects, and a set of rules for how they point to each other.

Open .git/ and look around. It’s less mysterious than you think.

Further reading:

What is jQuery Really? A Look Under the Hood

Garrin Costa, Jr. — Sat, 25 Apr 2026 18:25:40 +0000

What is jQuery Really?

jQuery can drastically simplify working with HTML, CSS, and JavaScript. Taking a little time to understand how a tool works — the mechanism that drives it — is often the difference between having access to a tool and having command over it.

To better understand what jQuery is doing under the hood, it is helpful to understand a little bit about the DOM. The DOM (Document Object Model) is a programming interface, built by browsers, which represents the structure of a web document in memory. It is created when a webpage is loaded, representing the document with a tree-like structure. The DOM can be thought of like a bridge or a hub, allowing a webpage's content, styling, and interactivity to be accessed and manipulated dynamically.

A look under the hood — engine components exposed, illustrating the mechanism beneath the surface.

The DOM Problem jQuery Solves

The DOM exposes a set of built-in browser APIs for accessing and manipulating elements. These APIs offer a world of capabilities and give us precise control, but they are verbose and low-level by design, requiring a lot of explicit instruction for even simple operations.

jQuery wraps those verbose native APIs in shorter, more readable methods. We write the jQuery shorthand — jQuery handles the verbose part under the hood.

The example below demonstrates a simple DOM interaction. We're going to grab a button on a webpage and change its color when clicked — the same operation written first in vanilla JavaScript, then in jQuery:

document.getElementById('button')
  .addEventListener('click', function() {
    this.style.backgroundColor = 'red';
  })

As you might notice, the code needed to perform relatively simple modifications can get cumbersome. This is just ONE modification.

Now here's the same operation done with jQuery:

$('#button').click(function() {
  $(this).css('background-color', 'red');
})

jQuery collapses our JavaScript into just a few lines of clean, readable code.

$ is Just a Function

As we pull back the curtain on jQuery, let's first look at the $ symbol.

A common misconception many beginners have about this is that $ is special syntax — something built into JavaScript itself. Perhaps assuming JavaScript just knows what $ means.

However, that is not the case. We know that $ is a valid character to use when naming variables in JavaScript, but that's all. On its own, $ means nothing to JavaScript unless defined — which is exactly what happens when jQuery is imported. Both jQuery and its alias $ are defined as the jQuery function. By convention, most developers use $, but either works — what matters is consistency.

We pass element selectors into the function as arguments. It returns an array-like container (the jQuery object) that contains the selected DOM nodes. This gives us access to jQuery's methods, which we can execute on the selected elements.

To get access to the jQuery library and use it in a project, you can download the library and then in your project's HTML file, create a script tag with a src attribute that points to your copy of jQuery:

<!-- Local download -->
<script src="jquery.js"></script>

Another option is to load jQuery via CDN:

<!-- CDN -->
<script src="https://code.jquery.com/jquery-4.0.0.min.js"></script>

What You Actually Get Back

Unlike vanilla JavaScript which returns raw DOM elements directly, jQuery returns an array-like container holding the nodes. With jQuery, we manipulate elements through this container, not directly.

You can see what this looks like for yourself. Open your DevTools console on any jQuery page and run $('p'). What you get back should look something like this:

T {0: p, 1: p, 2: p, 3: p, 4: p, 5: p, 6: p, 7: p, 8: p, 9: p.copyright, 10: p, length: 11, prevObject: T}

What you're seeing is the jQuery object. It contains indexed elements and a length — the number of matched elements — along with some internal jQuery properties (prevObject) that are beyond the scope of this article. If we expand it, we can see a vast array of methods and properties now accessible to us. This behavior of returning the jQuery object enables us to write the same code whether our selector matches one element or many — jQuery handles the iteration.

Vanilla JavaScript requires a manual loop:

var paragraphs = document.querySelectorAll('p');
for (var i = 0; i < paragraphs.length; i++) {
  paragraphs[i].style.color = 'red';
}

Whereas jQuery silently iterates:

$('p').css('color', 'red');

Much simpler in form, easy to follow, and easy to chain.

Why Chaining Works

When we call a jQuery function, what we get back is the jQuery object, rather than the raw node that we're operating on. This is by design. What's special about this behavior is that the jQuery object — that container that wraps our raw data — comes equipped with many of jQuery's built-in methods and properties. It gives us something to operate on. This is what makes chaining jQuery methods so simple and effective.

Why would we want to chain methods? What makes this so useful? Take a look at this example:

$('#button').css('background-color', 'red')
            .slideUp(500)
            .slideDown(500);

Here, we've performed three different operations on our #button element without having to re-select it three times. It's simple, logical, and sleek.

Event Handling

Event handlers wait for a specific event and invoke a callback function when that event occurs. jQuery makes this operation concise and readable. With jQuery, .on() is the universal event handler. Though not the only way to implement event handling, it is preferred for flexibility and consistency. It looks like this:

$('#button').on('click', function() {
  // do something
});

jQuery also provides shorthand methods for specific event types — here are a few common ones.

Let's say we have some card elements on our page and we want to blur the background when we hover on a card. This requires a couple of functions. In jQuery, we can do this like so:

$('#card').hover(
  function() {
    $(this).addClass('expanded');
    $('body').addClass('blurred');
  },
  function() {
    $(this).removeClass('expanded');
    $('body').removeClass('blurred');
  }
);

Our $ is a function, into which we pass the #card element selector. Since jQuery returns its container object, we can then chain .hover() to the object and pass the functions that will perform our desired action. Those functions can also call the jQuery object to do so.

Here's an example of showing/hiding options based on checkbox state:

$('#checkbox').change(function() {
  $('#options-list').toggle();
});

We start with calling $ and pass into it the #checkbox selector. We implement the .change() jQuery method on the returned object, letting us pass a callback function which passes another $ call with our next element selector as its argument, returning the jQuery object onto which we can apply the .toggle() method. Clean and concise.

And here's one more example showing how we might use jQuery to implement an event listener that starts music playback on spacebar press:

$(document).keydown(function(e) {
  if (e.key === ' ') {
    music.play();
  }
});

This again shows how simple and readable our code can be when implementing operations that often prove tedious and difficult to follow otherwise.

Conclusion

I hope this has helped in showing some of jQuery's capabilities and usefulness, as well as given some insight into what's going on under the hood. A deeper understanding of how jQuery interacts with our code makes bugs easier to avoid — and when they do occur, easier to debug. It also deepens our understanding of JavaScript as a whole.

Another benefit to understanding a library like this is that it can serve as a template for understanding ANY library. While syntax, structure, and individual details will vary, the broader concepts often overlap. This can make expanding our range of knowledge and broadening our toolsets a much less daunting and more rewarding experience.