The man can tell a story.
I’ve been playing with Sketch.systems a bit already. This post looking into adding verification on top of it.
Dark is a holistic programming language, structured editor, and infrastructure, for building backend web services. It’s aimed at frontend, backend, and mobile engineers.
Soup to nuts.
Australia is a place with more land than people, more geography than architecture. But it is not and never has been empty. Few landscapes have been so deeply known.
A post that builds up from simple princples. It looks into React, its programming model, its goals, and the trade offs it takes in solving its design challenges.
Startup strategy is like Kung Fu. There are many styles that work. But in a bar fight, you’re going to get punched in the face regardless.
I can only teach you my style. Others can only teach you theirs.
Lots to chew on.
the research is clear: Telling people what we think of their performance doesn’t help them thrive and excel, and telling people how we think they should improve actually hinders learning.
The only realm in which humans are an unimpeachable source of truth is that of their own feelings and experiences.
Speaking of lifting others up, your core group of friends can make or break your life. And your participation can make or break theirs as well.
Instead of working with a thing you love, think about how to work in a way you love.
This is totally my bag.
Still trying to learn how to think better.
Cindy Sridharan quoting Joe Armstrong:
We should identify the error kernel. The error kernel of a system is that part which must be correct. That’s what the error kernel is. All the other code can be incorrect, it doesn’t matter. The error kernel is the part of the system that must be correct. If it’s incorrect, then all bets are off. The error kernel must be correct.
John D. Cook:
The rule of three gives a quick and dirty way to estimate these kinds of probabilities. It says that if you’ve tested N cases and haven’t found what you’re looking for, a reasonable estimate is that the probability is less than 3/N. So in our proofreading example, if you haven’t found any typos in 20 pages, you could estimate that the probability of a page having a typo is less than 15%.
Hashing syntax trees and storing them directly in a database is very interesting. I’ve long wondered what will come after the grab bag of text files approach we’ve been using to date.
Embrace the power of compounding.
Now you can learn them too.
I ❤️ every time Sam goes on The Watch.
Alex Blumberg interviews Ira Glass.
Come for the Feynman anecdote, stay for the exploration of technology and culture.
A look behind the curtain with Nick Cave.
An improvisational approach.
Ryan Singer on the Product Love podcast talking about strategy, design, and outcomes.
A nice summary of the various parts in a typical web application.
Having all the answers is not the goal. Motivating the team to find the answers is the goal.
To evaluate the strength of a manager, look at the strength of their team.
The first time any of the above happens on your watch, it’s always new and hard, no matter how many books you’ve read on the topic. But the fifth or tenth time or 20th time it happens, you’re no longer freaked out. You realize that you’ll be fine.
Lots more interesting points in this and part 2.
A look at conflict in online communities and a suggestion on how to handle it.
So what are the management skills that are needed to achieve [Engineering productivity]? At the first level of management, they look like:
- Breaking down the scope of projects to help your team ship frequently. An eye for the MVP, for sequencing work and for predicting likely risks and bottlenecks for project completion are the skills here. This is why I think project management is such an important part of engineering leadership development, and why I hate to hand it off to professional project managers for work that doesn’t cross teams or organizations.
In product development, the closer to the customer a piece of software is, the more often it changes.
In short: stdout is for output, stderr is for messaging.
Some good tips sprinkled throughout.
Nice coverage of different approaches for testing in Production.
Nephew James Stein of Los Angeles claimed his uncle was an A&R consultant for Bad Boy records and ran a chain of legal recreational marijuana dispensaries in Colorado called Casablunta.
Now, let’s try a much better, O(1) control plane. DUMB AS ROCKS. Imagine if instead that the customer API pretty much edits a document directly, like a file on S3 or whatever. And imagine the servers just pull that file every few seconds, WHETHER IT CHANGED OR NOT.
This system is O(1). The whole config can change, or none of it, and the servers don’t even care. They are dumb. They just carry on. This is MUCH MUCH more robust. It never lags, it self-heals very quickly, and it’s always ready for a set of events like everyone changing everything at once. The SYSTEM DOES NOT CARE.
This contains many things I don’t understand.
Applying evolutionary theory to the origins and functions of religion.
Learning something new all the time, and staying healthy. Getting paid. Interacting with smart people. Having the chance to pass something along to others.
If you think about it this way, you might recognize that in many software teams, our limitation is not how much we can do, but how much we can know. To change a sufficiently complex system, we need more knowledge than one or two people can hold. Otherwise we are very slow, or we mess it up and the unintended effects of our change create a ton more work.
An explicit approach to delegation.
So the next time you find yourself tempted to volunteer to take over responsibility for something from someone who reports to you, pause. Instead of taking it over, ask them what they think the next steps should be. Give your feedback, and let them bring the follow-ups to you in the next appropriate touch base. You owe it to them to stop taking over their work in the name of helpfulness.
There are three types of product features, a seasoned head of product told me recently. MMRs, neutralizers, and differentiators. MMRs are minimum market requirements; basic features that every customer expects and demands. Neutralizers mitigate competitive threat. Differentiators are your startup’s competitive advantage.
As the product team talks to customers, they are likely to hear feedback encouraging more investment in MMRs and neutralizers. “Your product is missing this feature. We need this capability that exists in another piece of software in yours.”
customers rarely push vendors to further their differentiation. By definition, the unique selling proposition doesn’t exist elsewhere in the market. So advances or improvements to the differentiator may not be obvious to customers.
A simple application to get your macOS menu bar under control.
it’s important to build up a solid instinct for separating the technologies and products worth spending time on from the ones that will fade into obscurity after their 15 minutes of fame is over
I especially like the idea of recording yourself working to help guide improvement.
A look at the costs of implementing single page applications.
Looks like a useful visualisation for projects.
Some good tips and resources for remote workers and companies.
The Tesla’s big battery in South Australia has already taken a 55 per cent share in the state’s frequency and ancillary services market, and lowered prices in that market by 90 per cent, new data has shown.
And the 100MW battery has achieved over 55 per cent of the FCAS revenues in South Australia. So it’s 2 per cent of the capacity in South Australia achieving 55 per cent of the revenues in South Australia.
Various estimates have put the cost savings to consumers from the FCAS market alone at around $35 million, just in the first four months of its operation.
That’s a pretty good bang for the buck for the estimated $50 million investment by the South Australia government. South Australia is the only state that has experienced a decline in FCAS prices over the past few months.
This comes up every couple of years and each time I read it I laugh.
Things unfold in unexpected ways.
A pretty good list.
There’s hope yet that I can draw me some comics one day.
Covers the challenges of employing people around the world.
Goes into the (dearth) of applications as well as how it works.
Reminds me of The Newtonian Casino.
An app to help you use less apps.
What follows is my personal, opinionated, idiosyncratic approach to React/Redux development, forged in half a dozen attempts to pursue test-driven development at a good pace.
Some interesting approaches in here. I like the use of more classic terms for some of the Redux concepts. Commands instead of Action Creators. Events instead of actions. Read models instead of reducers or selectors.
A podcast about Watergate.
Tips to visualise and limit context switching.
A useful service for improving the security of your users’ accounts.
A useful overview.
From a couple years ago. The section dispelling dogma that’s arisen around the approach was particularly interesting (from 22:40).
If you are (or were) a highly opinionated engineer, practicing making space for information rather than quickly jumping in and sharing your conclusions is a must for leadership growth.
I don’t know what the original idea of Twitter was, but it succeeded because of natural selection. In a world where the tech industry was cranking out millions of dumb little social applications, this one happens to limit messages to 140 characters and that happens to create, unintentionally, a subtlety-free indignation machine, which is addictive as heck, so this is the one that survives and thrives and becomes a huge new engine of polarization and anger.
Creativity, progress, and impact does not yield easily or commonly to brute force.
The Case for Learned Index Structures:
Indexes are models: a B-Tree-Index can be seen as a model to map a key to the position of a record within a sorted array, a Hash-Index as a model to map a key to a position of a record within an unsorted array, and a BitMap-Index as a model to indicate if a data record exists or not. In this exploratory research paper, we start from this premise and posit that all existing index structures can be replaced with other types of models, including deep-learning models, which we term learned indexes.
Our initial results show, that by using neural nets we are able to outperform cache-optimized B-Trees by up to 70% in speed while saving an order-of-magnitude in memory over several real-world data sets.
Not the weather, but the climate.
He didn’t know whether to fix it or sell tickets.
A deep dive into the feature progression of Google Maps and how far ahead of the pack they are.
I used to find it odd that these hypothetical AIs were supposed to be smart enough to solve problems that no human could, yet they were incapable of doing something most every adult has done: taking a step back and asking whether their current course of action is really a good idea. Then I realized that we are already surrounded by machines that demonstrate a complete lack of insight, we just call them corporations.
Feel the pain.
I’ve been waiting eagerly for this episode to air — it’s my favorite of the season. As I looked through my notes, I was surprised to find that Kor and I first started working on scenes for “eps3.4_runtime-err0r.r00” as far back as January. The attacks against E Corp’s Hardware Security Modules (HSMs) are among the most complex hacks we’ve depicted on the show
Rich Hickey explained the design choices behind Clojure and made many statements about static typing along the way. I share an interesting perspective and some stories from my time as a Haskell programmer. I conclude with a design challenge for the statically typed world.
People often talk about a Person class representing a person. But it doesn’t. It represents information about a person. A Person type, with certain fields of given types, is a concrete choice about what information you want to keep out of all of the possible choices of what information to track about a person. An abstraction would ignore the particulars and let you store any information about a person. And while you’re at it, it might as well let you store information about anything. There’s something deeper there, which is about having a higher-order notion of data.
It was emotional.
Having a formal system means we can better support the growth of our engineers. We’re able to have more honest, open conversations about progress, promotions, and opportunity. While the framework is still relatively new, it is showing early promise at incentivising the kinds of behaviours we want to see in the team, and recognising the different kinds of value that people add.
We already have ideas on how to improve the framework further, and plan to continue iterating on it over time. We are releasing it publicly now, in the hope that it can help other companies that are thinking about how to grow and support their employees.
Medium’s growth framework looks well thought out and nicely structured.
A series of posts on options for creating a unified UI over disparate services.
The L16 replaces one big lens with 16 small ones and combines the images via software.
The old clustering of commodity hardware with software approach keeps on popping up in different contexts.
Some handy tips in here.
The real story in this mess is not the threat that algorithms pose to Amazon shoppers, but the threat that algorithms pose to journalism. By forcing reporters to optimize every story for clicks, not giving them time to check or contextualize their reporting, and requiring them to race to publish follow-on articles on every topic, the clickbait economics of online media encourage carelessness and drama. This is particularly true for technical topics outside the reporter’s area of expertise.
However there are general five general areas of interest that are always worth examining because they reveal mistakes with such surprising regularity. Specifically it’s worthwhile to find out how any system handles inputs, math, text, time and system resources.
Plenty of good testing advice.
I have long felt there is a shadow org chart, much like a shadow economy, where employees trade ideas, give direction, offer help, and spread culture. This shadow org chart is built bottom up by employees and is very different from the top down hierarchical org chart set by me.
I wanted to map this shadow org chart and find employees who have disproportionate levels of influence relative to their hierarchical position. I also wanted to see the influence centers and decision makers, and the directional current between them and the rest of the company.
Some fascinating analysis and data visualisation of a graph of influence.