(Inspiration and quotes.)
Perfect is the enemy of good. Shipping something something imperfect is usually better than shipping nothing at all. (There are exceptions, but they aren’t common.)
Most sufficiently advanced systems have to evolve to become good. Evolution requires exposure and experience in the real world, battle-tested behavior, and importantly, failures. The only path to this kind of evolution is to actually put something out there, even if it isn’t perfect. Especially if it isn’t perfect.
The elbow in the curve of time spent improving design and analysis comes earlier than you think. You should be spending less time designing, and more time learning from your failures, missteps, and the complex realities of your system in the wild. Your designs are wrong anyway. Natural selection is going to be a far more efficient process for showing you why and how your design is wrong than anything else.
Of note, an old essay by Richard P. Gabriel.
When you become stuck on a problem, you must try for another ~15 minutes, and then you must ask. Document what you try. It becomes a guide that may lead you to the answer, and if not, it will certainly lead to a better question.
The temptation to immediately ask an expert is tantalizing — but resist! If you first try, then ask, you gain things: Trust, Knowledge, and Skill.
Trust, because the experts see that you’ve tried, and you have documents showing what you’ve tried. You’ll also earn trust from questions unasked — others will discover what you’ve solved without help.
Knowledge, because some of the time in that ~15 minute buffer, you will find the answer yourself. Knowledge gained by trial can often be stronger than knowledge from tutelage. Sometimes, you will even learn something that no one else knows. This is one of the greatest feelings. And frequently incredibly fruitful.
Skill, because you will learn how to better learn. You will learn other things that you weren’t trying to. The 15 minute buffer might get smaller and smaller until it’s only a matter of a few minutes.
After all, an expert earns their place by trying a lot. Any sufficiently advanced form of expertise should look similar to trying a lot — and failing a lot. The best experts become intimate with this feeling. They may even revel in it. Accept the discomfort, learn to embrace it, and good things follow.
You must try, and then you must ask. (inspiration)
Sometimes it can feel like reading the code should be the last resort. That feeling is wrong. It is a dangerous feeling, bred from discomfort.
Reading the code isn’t always comfortable. It can feel like an arduous chore, especially if it isn’t a core habit of yours.
The code is truth. The only complete truth. If physicists had all the source code for the universe, how many experiments do you think they would run? My guess is zero.
Read the code and all else will follow. Do you wonder how something works? Read the code. Are you stuck on understanding an internal service? Read their code. Are you debugging how a coworkers’ library works? Read the code.
Always read the code.
I long searched for the perfect playlist to listen to as I worked. I never found it. So I tried to create it.
Flow is my playlist for concentration, coding, problem solving, etc. As of Mar 2019, it has over 57 hours of music.
Its aim is to optimize for the mental state of Flow. Using nearly exclusively non-vocal tracks, the genres are primarily spacemusic and ambient.
Thought is useful when it motivates for action and a hindrance when it substitutes for action.
The great benefit of computer sequencers is that they remove the issue of skill, and replace it with the issue of judgement.
— Brian Eno
Collapse the distance between imagination and implementation by building tools.
— Gordon Brander
Less rote practice; more imaginative delivery.
I have never written a runbook. And I refuse to ever do so.
Writing a runbook is a deliberate declaration of failure. It is the explicit process that recites a refusal to correct an error. An error doesn’t become a mistake until you refuse to correct it.
If your organization has runbooks, consider them as backlog tasks: automation, redesign, and architecture improvements. Do not add to their numbers. Failure begets runbooks; runbooks beget runbooks; and runbooks beget failure.
A good, simple writeup on the fallacies of distributed computing.
PDF Essay: Fallacies of Distributed Computing
A good index resource on consistency models, their guarentees, proofs, origins, etc.
An incredible read on how to build a company from the ground up.
Founder to CEO
Everything has been said before, but since nobody listens we have to keep going back and beginning all over again.
“It is an attitide that can be encapsulated in a simple but demanding rule: always think big picture and fine detail.”
Will Gompertz, Think Like an Artist
I’m convinced that the best kind of learning is interdisciplinary. Fields of study have much to learn from each other. The most interesting learnings are those that transcend fields of study. The rest is just details.
Everyone belongs to a tribe. Everyone underestimates the influence those tribes have on their thinking.
Acknowledge your tribes. Try to separate your thinking from your identity.
Keep Your Identity Small (2009) is an essay by Paul Graham which describes something I’ve intuitively practiced since my early twenties. But I’d never formalized the thought.
My set of justified true beliefs come not as an expression or extension of my identity, but from reasoned logic combined with a set of morals, ideal outcomes, and other justified true beliefs. I’ve internalized the idea that I shouldn’t let these beliefs constitute my identity.
A related idea is that of “Strong Opinons, Weakly Held”, a framework for thinking espoused by Palo Alto’s Institute for the Future. The idea is that opinions should be “weakly held” — be unattached to the idea, so that you do not irrationaly reject its refutation. The other side of this coin is that you must not let this lack of attachment dampen your rigor, passion, or strength in forming, understanding, and justifying your beliefs.
This talk by Brendan Gregg is a fantastic introduction to the tools available in linux for performance instrumentation, monitoring, and debugging.
More to come on which of these tools I use and documenting how I like to use them.
We are what they grow beyond. That is the true burden of all masters.
It is not enough to create your own success; you must create a shared success. A talented engineer will build a taller boat to see further along the horizon. A great engineer will create a rising tide that lifts all boats.
A shared success is not limited in scope to your team — it transcends teams. Find ways to drive shared successes across your org and company. Find the common good in a solution — the positive incentivization scheme that drives collaboration towards a shared goal. Express that common good persuasively and collaborate to achieve a shared success.
Shape the understanding and thinking of those around you to a shared context. Tailor the message to the audience. Engineers, managers, product managers, directors: To each of these people, the message must be presented in a different light. For some, only some of the message is relevant. For others, it is a matter of making the message comprehensible. Without a shared context, you will inspire very few — and even fewer will create a shared success with you.
This essay corroborates a lot of my own views about how I would choose to raise my children. Whenever interacting with children, I prefer to treat them exactly as I do adults, respecting their ability to reason, learn, and comprehend.
As a kid, I resented being treated like a child. I didn’t like it if an adult would dumb down a concept or hand wave something away because it was assumed I wouldn’t be able to understand. I think if we treated kids more like adults, the adults of tomorrow would be smarter and stronger.
A deadlock is kind of like when you’re at a resturaunt waiting to get the check, and your waiter is wating for you to ask for it. And you’re both wondering why it is taking so long.
You’re both waiters now.
First you learn the value of abstraction, then you learn the cost of abstraction, then you’re ready to engineer.
Always design your programs as a member of a whole family of programs, including those that are likely to succeed it.
—Edsger W. Dijkstra
Computer science is no more about computers than astronomy is about telescopes.
Functionality is an asset; code is a liability.
—Kirk Pepperdine, @kcpeppe
Perfecting oneself is as much unlearning as it is learning.
— Edsger W. Dijkstra
The lurking suspicion that something could be simplified is the world’s richest source of rewarding challenges.
— Edsger W. Dijkstra
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
See also: Refactoring: Improving the Design of Existing Code
A delicate matter, requiring taste and judgement. I tend to err on the side of eliminating comments, for several reasons. First, if the code is clear, and uses good type names and variable names, it should explain itself. Second, comments aren’t checked by the compiler, so there is no guarantee they’re right, especially after the code is modified. A misleading comment can be very confusing. Third, the issue of typography: comments clutter code.
— Rob Pike, Notes on Programming in C
Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose.
The i3 window manager is the best thing to happen to my desktop in a long time. Much like modal editing, it is a paradigm shift in how to interface with your computer. No floating windows. Everything is snapped. If you’re a vim/emacs user, you’ll like i3.
A few days ago, our team launched a new component. A week after launch, while dealing with some ops tickets, we discovered that the detailed, extensive wiki document for that component was already out-of-date.
This is a familiar story to any dev. Documentation is hard to keep accurate. The knee-jerk reaction is to assess that the miss here was that we allowed the documentation to become inaccurate. The knee-jerk reaction is wrong. It is not feasible to maintain documentation if that documentation is too specific.
The solution is to change the philosophical approach to documentation. For software systems of any reasonable complexity, the code is the only source of truth for its behavior and its descriptive reality. Documentation ought to answer the following questions, in basic non-technical english prose:
Again, documentation should never map 1:1 to anything more specific than a class. Anything more specific than that, and it effectively has to change whenever the code changes. If you’re changing the function of tons of classes and files, it is reasonable to expect that the documentation would necessarily have to change in kind.
Writing documentation at a high-level helps to minimize the potential that your documentation will become out-of-date and inaccurate. It is easier to understand, too. Which is kind of the point. If someone wants to know the objective truth exactly as it exists, the documentation is absolutely the wrong place for that. That’s what the code is for.
A home is something personal, a space that can shape your habits, emotions, and thoughts. I do not see it as overly materialistic to dream of an ideal place to call home.
I recently attended an Ada Talk at work. (Here at AWS, Ada is a group whose motivation is to create a community to empower, grow, and develop our women engineers.) One of the panelists, Clare Liguori, spoke about
Big L, Little l leadership.
Big L Leadership is official. It’s the managers, directors and executives of the world.
Little l leadership is leading by example. It’s camaraderie, teamwork, and excellence of character. Engineers have a lot of opportunity for
little l leadership. Take advantage of that. Be a
While I worked at an early stage startup, I fought tooth and nail in design meetings to apply solid engineering principles to everything we did: scalability, extensibility, modularity, generalization, etc.
I was wrong.
I was attacking the problem from a different perspective, a perspective that would fare well in a large company with massive distributed systems — a company inherently optimizing for the long run. Startups, however, are not optimizing for the long run. They can afford to worry about that later. They need to solve for tomorrow.
This doesn’t mean you should throw your engineering principles away. They’re not inherently wrong; they are simply the wrong tool for the job, if you’re at a startup. You must realize that everything is a matter of compromise, and at a startup, you will be compromising more often than not.
Murali Krishnan, my manager at the time, got this right. I was often on the other side of the table, arguing for engineering excellence. I wasn’t yet wise enough to understand his side of the story. It was only later that I understood that startups are optimizing for a different variable.
As a budding engineer that wants to hone these areas of excellence, it can be a very hard pill to swallow, to intentionally set aside engineering best practices. Do your best to understand that you’re not optimizing for the long run. Not yet.
Don’t just take my word for it, though. An essay of Paul Graham’s inspired this post. An entirely worthwhile read.
Every time you ask an engineer to postpone what he/she was working on and immediately work on some new task, you’ve done the equivalent of grabbing at least $500 from your company’s piggy bank and flushing it down the toilet. You’d better make sure that new task is worth it.
Any progress the engineer has made on the previous task, you can now kiss goodbye. You should consider that previous task as completely unbegun.
Context switching is incredibly expensive for engineers. It can take upwards of an hour for an engineer to build state on a problem. Building this state is a fixed cost of entry for the engineer to enter a state of flow that enables productivity. Breaking that flow and wasting all that state is expensive.
Yonatan’s response to the recently leaked conservative manifesto that was circulated in Google much mirrors my own thoughts on the matter. Google ought to come down hard on this guy.
Tolerance is not a moral precept. There comes a point where tolerance turns from convenience to complicity. Do the right thing.
This paper by Jurgen Schmidhuber is incredible. I’ll take some notes on it here in the future.
If you like imaginative/challenging math/logic/CS problems, take a gander at FiveThirtyEight’s The Riddler.
FiveThirtyEight is Nate Silver’s website that does precise, academic, and statistical commentary on a variety of issues. Their
The Riddler column features hard and interesting problems on a weekly cadence.
In the past, I have solved several, with at least one of my solutions being featured with a shout-out. My solution with code is on GitHub. This particular problem was a fun little geometry problem which I opted to solve via simulation and numerical geometry, though others found an elegant analytical solution.
This is pretty sweet. If you can geek out about this kind of stuff, ping me. We’d get along just fine.
Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.
If you think good architecture is expensive, try bad architecture.
—Brian Foote & Joseph Yoder
This video is pretty cool. It gives a visual and auditory insight into sorting algorithms. I believe this offers a unique angle that bolsters our intuitive understanding of how different methods of sorting work.
I strongly prefer and seek out deeper, more intuitive understandings as opposed to shallow, rote ones. Take a look.
A clever person solves a problem.
A wise person avoids it.
omne trium perfectum
— Latin for “everything that comes in threes is perfect.”
Kudos to a previous manager of mine, Murali Krishnan, whom I met while working at Transform for demonstrating true mastery over the rule of three and opening my eyes to its power.
rule of three (of which there is so much written that it needs a disambiguation page) is an incredibly potent tool to communicate ideas, persuade others, and to tell stories.
The Rule of Three, by Kevlin Henney
“An error doesn’t become a mistake until you refuse to correct it.”
—Orlando Aloysius Battista
Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
—Antoine de Saint-Exupery
You will often hear someone say, X is almost Y. Almost in this context should be read as not.
Almost is a graceful way to say that something desirable is not yet true.
If something is worth doing once, it’s worth building a tool to do it.