build_

Start here

Implementation gets cheaper; judgment does not. You can have more code generated than you can carefully judge, so the work shifts from writing to deciding: what users need, when to stop, and whether you can sign off a change as correct, tested, and intended. Start with where coding ends and the job begins, then with the design questions no rule of thumb answers for you:

• Master Software Crafters Let the Workpiece Be

  Good crafters can polish code forever. Masters ask what users need, and sometimes step away from the keyboard.

• Do Not Apply Code Heuristics When You Need a Broader Perspective

  Whether an abstraction is good is a question about the problem, not the code.

• Being Afraid to Change a Working App

  What counts as broken depends on how people use the app, so tests can only protect what you thought of.

Paths

• Getting started with Mac app development

  Architecture, AppKit, and the tooling around it, from your first window to a sandboxed release.

• All about TextKit

  Apple's text system, from NSTextView down to the typesetter.

• Software design wiki

  Coupling, cohesion, MVVM, DDD: one page per concept you'll keep coming back to.

• Sell your Mac app with FastSpring

  Your own store next to the App Store, with a guide and free code to get it running.

• MTP tools

  Talk to MTP devices like the Supernote from Swift, the command line, and Emacs: a library, a CLI, and a Tramp backend.

• Emacs

  A large REPL to try ideas in: Elisp packages, experiments, and the configuration around them.

Tools

Work with me

• Consulting and contract development

  Architecture reviews, mentoring your team, and the critical feature nobody else wants to touch.

• Workshops for development teams

  Swift, architecture, testing, and clean code, live with your team.