Breaking non-fiction books down into three kinds with advice on how to read them.

A look at how Etsy tailored their search results to individual customers.

Eugene Yan:

Rule #1: Don’t be afraid to launch a product without machine learning.

Machine learning is cool, but it requires data. Theoretically, you can take data from a different problem and then tweak the model for a new product, but this will likely underperform basic heuristics. If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.

To recharge themselves, individuals need to recognize the costs of energy-depleting behaviors and then take responsibility for changing them, regardless of the circumstances they’re facing.

The article covers four dimensions of energy: body, emotions, mind, and spirit.

George Fairbanks:

There are two parts to software development: creating a design and expressing it as code. The code is tangible but the design is conceptual. Keeping a project healthy means doing both well. Here’s my concern: whenever you mix the conceptual with the tangible, it’s easier to neglect the conceptual. When you miss a tangible target, it’s obvious, but when you miss a conceptual target, you might not recognize it, or might rationalize that, because it’s impossible to measure, you were really quite close.

Blindly applying a factory process to software development will drive improvements to the tangible part (the code) at the expense of the conceptual part (the design). We see plenty of examples of this today, where teams have great feature velocity at first, are puzzled when velocity slows, and eventually the project is abandoned. As Cunningham warned, if we bolt features onto an existing codebase without consolidating those ideas into the code, the design will suffer, and over time “[e]ntire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation.”

Casey Winters:

there’s one big thing that needs to change for wartime CPOs I want to cover today, and that is prioritization and evaluation.

Lara Hogan:

So, when a fraught issue arises, how can we help our organization move forward in a way that actually builds rather than breaks trust? Over time, and after many communication mistakes, I honed a four-part template, covering the following

Ryan Singer:

After I have a lay of the land, the next step is to determine what to work on first, second, third etc. Not every concern in the product provides equal value to the customer. Some parts are core to the problem. Without them the app has no purpose. Others are necessary but have nothing to do with the domain, like user-authentication.

Bungay Stanier explains how advice-giving goes bad; the three personas of your Advice Monster; and the powerful act of staying curious a little longer.

Jonathan Cornelissen:

Relegating all data knowledge to a handful of people within a company is problematic on many levels. Data scientists find it frustrating because it’s hard for them to communicate their findings to colleagues who lack basic data literacy. Business stakeholders are unhappy because data requests take too long to fulfill and often fail to answer the original questions. In some cases, that’s because the questioner failed to explain the question properly to the data scientist.

​…

A data-literate team makes better requests. Even a basic understanding of tools and resources greatly improves the quality of interaction among colleagues. When the “effort level” — the amount of back-and-forth needed to clarify what is wanted — of each request goes down, speed and quality go up.

​…

Shared skills improve workplace culture and results in another way, too: They improve mutual understanding. If you know how hard it will be to get a particular data output, you’ll adjust the way you interact with the people in charge of giving you that output. Such adjustments improve the workplace for everyone.

Liz Keogh:

As the Peter Principle suggests, we tend to rise to the level of our incompetence… but that’s not actually such a bad thing, as long as we can learn fast, safely. The best way to do that is to make sure things are safe-to-fail, which usually means putting appropriate feedback loops in place. In a human system, that usually means feedback.

…

Sometimes it’s the simplest thing in the world, and we forget to do it. Clarifying why you want something allows people to make autonomous decisions about how best to work towards the outcome you want; or (even more important) give you information about the context you were unaware of that will cause difficulty getting that outcome.

Timothy R. Clark:

Low-velocity decision making. In a nice culture, there’s pressure to go along to get along. A low tolerance for candor makes the necessary discussion and analysis for decision making shallow and slow. You either get an echo chamber in which the homogenization of thought gives you a flawed decision, or you conduct what seem to be endless rounds of discussion in pursuit of consensus. Eventually, this can lead to chronic indecisiveness.

Pete enumerates some patterns of teams and code ownership.

You need to take a step back and view data on a macro level, not micro. As the founder, you should care more about the trends not the constant, inexplainable anomalies.

…

One of the really frustrating parts of running a business is that many times we just don’t know the answer to “why?”.

Why did churn go up 10%? Why are trial conversions decreasing? Where did all these new users come from? Why is our growth half of what it was last month?

Many of those questions have no answer and trying to find an answer will cause you to rip your hair out.

A curated collection on the missing aspect of managed time in programming.

A look at how Skyscanner support their people’s transition from individual contributer to managers.

Lovingly craft those commits, friends.

Bezos considers 70% certainty to be the cut-off point where it is appropriate to make a decision. That means acting once we have 70% of the required information, instead of waiting longer. Making a decision at 70% certainty and then course-correcting is a lot more effective than waiting for 90% certainty.

…

Reversible decisions can be made fast and without obsessing over finding complete information. We can be prepared to extract wisdom from the experience with little cost if the decision doesn’t work out. Frequently, it’s not worth the time and energy required to gather more information and look for flawless answers. Although your research might make your decision 5% better, you might miss an opportunity.

Eradication of all latent failures is limited primarily by economic cost but also because it is difficult before the fact to see how such failures might contribute to an accident. The failures change constantly because of changing technology, work organization, and efforts to eradicate failures.

…

Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.

…

Hindsight bias remains the primary obstacle to accident investigation, especially when expert human performance is involved.

So many more nuggets of wisdom in there.

I pretty much highlighted the lot.

The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML.

Loads of fantastic advice.

Being right was something that we were taught was the ultimate pinnacle of knowledge, and there’s a reason, culturally, that so many of us care so deeply about being right. But it’s time to get rid of that. It’s no longer the currency that separates who does the really great work in life from who doesn’t.

Ensemble programming vs pull requests.

Rolling up your sleeves is magic.

Kevin Fishner:

At HashiCorp, we’ve grown from a few hundred to over a thousand people, so the goal is to build scalable systems that enable employees to do their best work and contribute to the outcomes of the company. For us, that’s shaped up into three specific systems: strategic planning, knowledge management, and communications.”

They also run a simluation to give their leaders a chance to practice.

“Using a firm called BTS, we run a business simulation where leaders get to ‘run’ the business for three years. Taking a simplified view of the company, we essentially build a game board based on our five-year financial model and this year’s three executive focus areas,” says Fishner.

Marty Cagan:

Stephen Covey explained that “trust is a function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive and your intent with people. Both are vital.”

…

Great teams are comprised of ordinary people that are empowered and inspired.

…

Truly empowered teams that produce extraordinary results don’t require exceptional hires. They do require people that are competent and not assholes, so they can establish the necessary trust with their teammates and with the rest of the company.

Truly empowered teams also need the business context that comes from the leadership – especially the product vision – and the support of their management, especially ongoing coaching, and then given the opportunity to figure out the best way to solve the problems they have been assigned.

Rands:

The fourth role is by far the most important. It’s the role the vast majority of engineers will follow in their careers, and I’m going to call it “This. Forever.” The role you have right now is the thing you are going to do be doing forever.

…

A depressing thought? Not when you remember you’re on a quest.

Avishai Ish-Shalom:

To sum up: Variance is the enemy of performance and the source of much of the latency we encounter when using software.

To keep latency to a minimum:

• As a rule of thumb, target utilization below 75%,
• Steer slower workloads to paths with lower utilization,
• Limit variance as much as possible when utilization is high,
• Implement backpressure in systems where it is not built-in,
• Use throttling and load shedding to reduce pressure on downstream queues.

Pat has collected a list of resources for learning about product management.

Coda Hale:

Most explanations of organizational success or failure are crap.

…

an organization doing work is just an incredibly complex, dynamic, distributed, parallel process.

…

As with writing highly-concurrent applications, building high-performing organizations requires a careful and continuous search for shared resources, and developing explicit strategies for mitigating their impact on performance.

…

The only scalable strategy for containing coherence costs is to limit the number of people an individual needs to talk to in order to do their job to a constant factor.

There are so many quotable sections in this piece.

Go and have a read if you think about organisations, how they work, and how to improve them.

Marina Hyde:

Anyway, Zuckerberg is in the news along with News Corp boss Rupert Murdoch, in a heartwarming generational fight between billionaires for who gets to say: “Bitch, I’m not IN the news, I OWN the news.”

Ben Brooks:

I don’t need areas or projects to do my work effectively. I don’t need complex chaining rules and sequences. I don’t need start dates or tags. In late November I realized that while Things still worked fine for me, I was using it not for task management any longer — but instead I was using it as a reminder engine.

I think all I need is a Reminder engine, I am pretty good at getting my tasks done once I am reminded of them.

I’ve been thinking about how working as a manager differs from working as an individual contributor. One thing I’ve noticed is that my day to day work as a manager has become more asynchronous.

Projects tend to be composed of a series of pings and responses with the odd timeout when I haven’t heard back from someone.

This post from Ben resonates with me because I feel that my productivity system is more useful when it reminds me to do things rather than helps me break down the steps of a particular task.

James Clear:

Convincing someone to change their mind is really the process of convincing them to change their tribe. If they abandon their beliefs, they run the risk of losing social ties. You can’t expect someone to change their mind if you take away their community too. You have to give them somewhere to go. Nobody wants their worldview torn apart if loneliness is the outcome.

Denise Yu:

In every conversation you’re part of, create clarity and reduce chaos.

With more advice on how to do that in the linked thread.

A series of posts from Hillel Wayne resulting from interviews with people who have worked as both traditional engineers and software engineers.

• Are we really engineers?
• We are not special.
• What engineering can teach (and learn from) us.

I appreciate that this is based upon the views of folks who’ve actually worked on both sides of the fence.

Chris Kiehl:

The word “scalable” has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word.

An inspection of how values affect software through the lens of text editors.

Sahil Lavingia:

Because I was burned out and didn’t want to think about working any more than I needed to, I instituted a no-meeting, no-deadline culture.

For me, it was no longer about growth at all costs, but “freedom at all costs.”

…

At some point, it clicked: Creators make money so they can make stuff, instead of the other way around. Why not adopt this framing at Gumroad, too?

This is what working in the creator economy should feel like.

A look at the unorthodox way Gumroad operates.

No. 26 (Montemerlo’s Law) Don’t do nuthin’ dumb.

Kelly Sutton:

A Campaign is a long-running effort to enact global change safely within a sociotechnical system.

…

Campaigns work well to address:

• Technical changes with large social components.
• Technical changes that require everyone to do a little bit of work.
• High-value or inevitable future worlds

Esther Derby:

Clarity enables patterns of coherent action across the organization. Contextual understanding supports initiative–people don’t have to wait to be told what to do. It speeds decision-making as people closer to the work have the information to make more decisions in a reasonable way. Clarity reduces the need for supervision.

…

Smoothing the flow of work, organizing work and teams to reduce dependencies and handoffs, is management work.

Gregor Hohpe:

Sadly, or perhaps luckily, most experimentation isn’t all that dramatic. It mainly means trying something new and using the results to decide a further course of action. You can experiment with a more efficient route to the office, with a new dinner recipe, or a new vacation destination. The element that distinguishes an experiment from serendipity is that you have a hypothesis that you are looking to verify or falsify based on data that you glean from running the experiment.

Barack Obama:

But the point is, in just a few short weeks on the job, I had already realized that because every tough decision came down to a probability, then certainty was an impossibility — which could leave me encumbered by the sense that I could never get it quite right. So rather than let myself get paralyzed in the quest for a perfect solution, or succumb to the temptation to just go with my gut every time, I created a sound decision-making process — one where I really listened to the experts, followed the facts, considered my goals and weighed all of that against my principles. Then, no matter how things turned out, I would at least know I had done my level best with the information in front of me.

RC has four social rules. They help create a friendly, intellectual environment where you can spend as much of your energy as possible on programming.

The social rules are:

• No well-actually’s
• No feigned surprise
• No backseat driving
• No subtle -isms

One thing that often confuses people about the social rules is that we expect people to break them from time to time. This means they’re different and totally separate from our code of conduct.

McLaren Stanley:

Alright folks, gather round and let me tell you the story of (almost) the biggest engineering disaster I’ve ever had the misfortune of being involved in. It’s a tale of politics, architecture and the sunk cost fallacy

Ian Leslie:

Paul McCartney has been writing and performing music more or less continuously since 1956. That’s sixty-four years.

Lawrence Wright:

There are three moments in the yearlong catastrophe of the COVID-19 pandemic when events might have turned out differently.

Kent C. Dodds:

1. Not everything in your application needs to be in a single state object. Keep things logically separated (user settings does not necessarily have to be in the same context as notifications). You will have multiple providers with this approach.
2. Not all of your context needs to be globally accessible! Keep state as close to where it’s needed as possible.

Vasco Figueira:

TL;DR “Microservices” was a good idea taken too far and applied too bluntly. The fix isn’t just to dial back the granularity knob but instead to 1) focus on the split-join criteria as opposed to size; and 2) differentiate between the project model and the deployment model when applying them.

…

There are build patterns that give us total control over the relative visibility between components and over how they compose into deployables. One build to many deployables, many to one or anything in between is possible. Shifting concerns left helps us build better software. An earlier error is a better error. Constraints liberate.

The tensions and constraints that shape the arrangement of our projects, modules and dependencies are of a different nature than those shaping the arrangement of our deployables. A little build-fu goes a long way in combining development friendliness with mechanical sympathy.

My system for processing email is similar to Xavier’s.

Though, I use the Things Helper app to add links to emails directly to my Things inbox.

Paul Ollinger:

Danish values also provide a three-step prescription to turn the day around: “In Denmark, we have sort of a mental health [checklist]: Do something active. Do something together with other people. Do something meaningful.”

Great scientists tolerate ambiguity very well. They believe the theory enough to go ahead; they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory. If you believe too much you’ll never notice the flaws; if you doubt too much you won’t get started.

Dan Abel:

Feedback is someone is trying to help. Listen. Then ask questions - to gain understanding of their point of view.

I also enjoyed the idea of treating Slack more like Twitter.

Peter Naur’s classic 1985 essay “Programming as Theory Building” argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it’s lossy, so you can’t reconstruct a program from its code.

A copy of the paper.

Ken Kocienda tells stories of how Apple built the iPhone and iPad: a small team (less than twenty people) charged with delivering on direction set by executives.

Part one:

• Viewing product development decisions as economic tradeoffs.
• Shifting from deterministic planning models to a stochastic perspective.
• Managing the Fuzzy Front End: the time from opportunity identification to commitment.

Part two:

• Assessing the reserve buoyancy of a project.
• Using loss of safety margin as a leading indicator of project deterioration.
• Becoming more rigorous about how we think about technical debt.

John O’Shea:

Dashboards are the human-facing views into our systems that provide concise summaries of how the system is behaving by displaying time series metrics, logs, traces, and alarms data.

A look at how Amazon do dashboards.

Jeff Hodges:

Below is a list of some lessons I’ve learned as a distributed systems engineer that are worth being told to a new engineer. Some are subtle, and some are surprising, but none are controversial.

161 suggestions from the staff at Automattic.

Trade offs and spooky stories from Stefan Tilkov.

Game design and unsuccessful monad tutorials.

Malte Ubl:

As software engineers our job is not to produce code per se, but rather to solve problems. Unstructured text, like in the form of a design doc, may be the better tool for solving problems early in a project lifecycle, as it may be more concise and easier to comprehend, and communicates the problems and solutions at a higher level than code.

Jonas Downey:

Since HEY made a big splash on arrival, I thought it’d be fun to share the backstory of how we ended up reinventing email. Because we certainly didn’t start by wanting to reinvent email.

Denise Yu:

Assume that every student you interact with has limited information, but infinite intelligence. That places the onus squarely on the shoulders of the mentor to make sure that their explanations make sense — which, given the inherent imbalance of power between a teacher and a learner, is a fine way to distribute the extra emotional labor.

Rands:

Process is documented culture. How a team gets a familiar thing done should be broadly understood by the team. This is how we fix a bug. This is how we do a code check-in. This is how a feature is designed. This is how executive sign-off occurs.

Process comfortably and efficiently describes the common path. Process does not define what to do when the indescribable occurs. A crisis or a disaster does not neatly fit into the common path; it’s when you need someone to swoop in, break the glass, and put out the fire.

Grant Fritchey:

Finally, to increase communication, especially if the message is vital, use the three-way handshake. Tell your message to someone using whatever medium you’re using. Then, have that person tell you your message back (in their own words of course, no copy and paste). You then repeat that message back to them. Assuming everyone has it right, you’ve just completed a three-way handshake.

Stuart Sierra:

The purpose of a meeting, then, is not to convey information efficiently. It is to force an audience to pay exclusive attention to one thing, to get that creative focus pointed in a particular direction.

Complex systems, cascades (from neurons up to people and then crowds), failures, too much efficiency, not enough slack, and toilet paper.

Dan North on how to break the rules when applying the Theory of Constraints.

A look at negotiation and how to avoid the pitfalls associated with debate.

A nice rundown of implementing Sagas in a distributed system.

Pat Kua:

Makers receive constant praise for solving problems, and take pleasure in being the expert. Leaders in Maker mode go out of their way to show they have the right answer. They need to have the first and last say. They over invest in their own solutions and don’t create space for others to contribute.

…

Multipliers amplify or multiply the intelligence of the people around them. They lead organisations or teams that are able to understand and solve hard problems rapidly, achieve their goals, and adapt and increase their capacity over time.

Tom MacWright:

There is a sweet spot of React: in moderately interactive interfaces. Complex forms that require immediate feedback, UIs that need to move around and react instantly.

I’m still a sucker for server-generated markup.

Michael Deng and Jonathan Chang:

Deploys require a careful balance of speed and reliability. At Slack, we value quick iteration, fast feedback loops, and responsiveness to customer feedback.

An interesting dive into how Slack handles deploys to a large fleet of users.

Cal Newport:

In the war to reclaim your attention, some battles have clearer fronts than others. It has become clear to me that these differences matter.

…

An attention charter is a document that lists the general reasons that you’ll allow for someone or something to lay claim to your time and attention. For each reason, it then describes under what conditions and for what quantities you’ll permit this commitment.

I use LucidChart for collaborative drawing at work but I’m going to give Excalidraw a crack over the next few weeks.

A solid collection of remote working advice. There is some overlap with the strategies I employ.

I wish I’d found this project before I rewrote a Strange kind of Madness by hand using Hugo.

Elisabeth Hendrickson:

What I’ve learned is that if we want things to go fast, a sense of momentum is much more effective than a sense of urgency.