Principles

What I've learned - and try to stick to - from a few years of building products with others:

The products that we build are a reflection of the organisations, the people, and the tools that have built them. Treat every interaction with kindness, thoroughness, and clarity, and the organisation you build, the products you create, and the environment you foster will all naturally follow.

Code is writing. Your job is to tell the reader a concise, beautiful story in as little time as possible; to concisely describe efficient procedures to others. The executability of code is a the most valuable consequence of good writing; code that works but is not easily understood is too often worse than no code at all.

Pull requests, code reviews, design feedback, user studies, presentations, like code, are tools for telling stories. Carefully understand your audience, the context, and the message you want to convey, and do so authentically. Omission of information helps focus; a firehose of information helps nobody.

What part of the code should you look at? What truths about a user's experience do you want to uncover? What aspects of your work are you most proud of? Every interaction with someone else at work is an opportunity to present your work; cherish the time of others and make these interactions enjoyable.

Always clean up after yourself. If you don't, ask yourself - will you be comfortable seeing this mess in a day? A month? A year? The life of code is quite long but the half-life is brief; the worst code often atrophies the fastest and steals the most time from future you.

The way you sleep governs how you eat. The way you eat governs how you exercise. The way you exercise governs how you feel about yourself. The way you feel about yourself governs how you interact with others.

The tools you use - the medium for your work - matter, but are far less important than your taste and conviction. First understand what it means for a solution to your problem to be beautiful -- then apply that taste to the way you solve this problem for someone else and provide value to them.

Every application on MacOS has three traffic-light dots at the top left. Almost any application you're running with MacOS has "faked" them - reimplemented them from scratch -- but they all somehow feel equally well-designed and satisfying to use. Macs feel so cohesive not because of the tools - they're written in all sorts of stuff - but because of thetaste that Apple - through customer expectations - demands of software built for their platform.

Especially at a company that employs software developers, there is a tendency to transform every problem into a software platform. Often the best solution doesn't have anything to do with software; Using your words, making more plans, sending more emails, and preparing more spreadsheets - in that order - are usually more effective until you're truly limited by these mediums.

Customers often expect you to be able to automate their world, but to commit to automating their world is to speak their language, and the languages that most businesses speak are words, then emails, then spreadsheets, in that order.

Use libraries, not frameworks.

A library is a tool to express a complex concept in a terse, abstract manner. It's a code package, a specific set of phrases, or the way you greet your coworkers in the morning; a summarized aspect of one tool you use.

A framework is an all-encompassing way of working in a particular domain. Ruby on Rails requires you to express code with a very particular structure. Lean Six Sigma requires you to follow a precise set of business processes.

Healthy frameworks, then, are descriptive; they're created out of observations that this set of tools worked for the last n problems we've solved, so they'll probably generalize to the next n problems.

Every company is different -- people are non-fungible, problems are different, and tastes are unique. Develop - or adopt - libraries as you work. Let the frameworks that best fit you emerge organically.

Respond instantly. The best way to get things done fast is to flow at the same pace as the people you work with (and you should always work with other people). Move faster than their pace if you can.

Separate planning from execution, even if it feels overprescriptive. Developing good software takes a negligible amount of time. The planning takes all the work.

Language models have made executing on ideas - particularly with code - extremely cheap. Write the code two, three, five times; toss it out, rewrite it, bring it back better.

Writing code is about expressing an idea, but it's also a design problem. When programming, the tools others give you to use, your process of making tools for others, and the tools you make for others all exist in the same medium. How beautiful!

Only set up structures - frameworks - when you can feel that the lack of a process is a significant limiting factor; not before. Never before.

You probably need fewer boundaries with friends. Letting people into your life early and often is one of the most appreciated gifts you can give; letting someone go, though, is one of the most valuable.

Any sort of information you're consuming from your phone or computer - without regard for what's happening out your window - is reaching you without context; you're receiving work that's been fit through a curation and a framing and a photo-op and a re-selection, each step constraining the context and nuance of the original. Sharing "inspiration" images without context is no different from playing telephone with political quips or eating mass-produced food; the stuff is extracting you from your local environment and placing it with this smeared mess of diluted, context-less global information.

Connecting with your local community - to feel as if you belong where you live - is the most important human need. Don't pretend that absorbing content can replace it.

Always have a plan - for the next day, the next week, the next month. Wake up with purpose. Waking up without a plan is no different from throwing the day away.