The two terms are often used interchangeably but are actually very different in an extremely important way: one is about resources, but the other is about speed. As a tech lead or manager, knowing this distinction can really help make the right decision for your projects in certain situations.
Read More“If you need a machine and don’t buy it, then you will ultimately find that you have paid for it and don’t have it.”
If you are an engineer or product manager or a manager of any kind and have not read Henry Ford's autobiography, My Life and Work, then I strongly suggest that you do. It is a wealth of insights and a glimpse into the mind of a man whose genius wasn't merely "invention, assembly lines, and operations" as is commonly taught in schools. The truth is, Ford had an eye for simplicity.
Ford understood that to succeed in democratizing the automobile, he had to simplify the car, which was a grossly wasteful machine in his day. His aim was to achieve fewer moving parts, lighter materials, and fewer irrelevant options, which led to a lean, mean, and (most importantly) cheap machine. His strategy, you should note, did NOT include financial gimmickry or ways to squeeze workers' wages; in fact, he did the opposite, seeking opportunities to improve their effectiveness and then pay them more.
He took it a step further, however, than just simplifying the product: he also relentlessly simplified the machine that made the machine: the Ford Company itself and its factories. This was a very deliberate effort on his part. To do it, he empowered all of his employees, ranging from executives down to factory technicians, to take that mission into their own hands.
The results are astonishing. In 1908, a Model T cost $850. The average worker earned about $500 per year at this time. By 1925, he had gotten it down to under $300.
TLDR: read this book. Think like Ford. If you think you need a new bit of infrastructure or component, just buy it or build it. If someone on your team groans about a chore, push them to solve it once and for all. You'll go faster, not slower. You'll deliver cheaper, sooner, and better. Otherwise, you'll find that you've paid for it and don't have it.
At some point in your life, you probably realize: everything in the world is broken and sucks.
There are two ways you can react to this truth:
1. Go into a deep depression, adopt complete cynicism, and protect yourself.
2. Put a smile on your face and relish in the opportunity to improve it, give, and bring joy to others.
These days a lot of people talk about the magical wonderfulness of “minimalism” and living “simply” and take cute pictures of themselves meditating with a cup of matcha in their spartan apartments and post them on Pinterest or Instasnap or whatever. So pretty and aesthetic.
Screw that. This post isn’t about that. I care a lot more about what things COST. Real time, real dollars, real opportunities missed.
After you read this post today, I want you to just remember this one simple thing the next time you think about introducing anything new into your life or software:
It seems small and trivial today, but in the long run, it is massively expensive to add something.
Here are some examples:
It seems so innocent. Let’s JUST add it, right? How bad could it be! It’s so little and it’ll solve everything!
Hold up. Consider all the implications for the days or years to come:
It's only a hundred bucks. No problem, right? You fall in love with it. Impulsively buying it is quick, easy, and feels awesome. It looks SO spiffy in the corner next to your shelf of smart books. But then:
You now need to dust it once in awhile.
If you care for your wooden furniture and want to ensure they’re long-lasting, you must also continually purchase proper wood cleaning / polish products.
If you pay a person to clean your home, it will take up some of their precious time. Given enough items like this taking up 1% of their time, we’re talking a serious amount of effort every week of every year.
Next time you move apartments, you need to pack it or wrap it and pay movers to ship it. Or you can move it in a rented truck, which must now be a bit bigger to accommodate and reserve for even more time.
When you buy renters insurance, you must account for this side table in your possessions and pay a slightly bigger premium. Given enough items like this, you’ll be paying significantly more and at the end of the day basically insured a stupid side table you gave only 10 minutes of thought to buying.
Just the mere PRESENCE of a new surface invites you to add more shit on top or inside it with ALL THE ABOVE PROBLEMS.
If you’d rather avoid all of the above bullshit and would prefer to actually live your life and/or solve real problems for your customers, just cut the crap. Make the burden of proof for adding things really, really high. Create a culture of restraint. You’ll thank yourself later.
A lesson I learned long ago, from a wise teacher of martial arts, still resonates with me today. He said to me:
On Form:
"Don't worry about hitting fast yet. First focus on your form. If you don't have good form, you'll never be able to strike swiftly. You'll have too much wasted movement."
On Speed:
"Don't worry about hitting hard. After you have perfect form, focus on speed. Hit your targets quickly and efficiently. Power comes from two things: velocity and mass behind it. If you're not fast, you'll never be powerful."
On Power:
"Finally, deliver with force. Use your entire body. When you've mastered all else, you can hit harder than someone twice your size."
Don't try to jump ahead, or you'll never achieve your goal. Always train yourself in the proper order: first form, then speed, and finally power.
Optimistic Concurrency Control = stop signs.
Pessimistic Concurrency control = traffic lights.
Stop signs assume low contention over a resource (the intersection) and tend to yield higher throughput if that is true. Average latency does tend to suffer a bit from the overhead, however, as every single car needs to slow down a bit to check that it's not about to slam into an oncoming car or pedestrian.
Traffic lights are very explicit locks over a resource (the intersection). Traffic lights assume that there is going to be high contention. Worst-case latency can be very good since you fly through a green light at top speed, but you now have a strict lower bound on the minimum latency (the time for the green light to switch on for your direction).
When there is low contention over an intersection (e.g. very late at night) you should really convert the signal into an optimistic lock.
I've observed that a large class of meetings are about bringing verifiers to bear upon solutions.
Typically, one individual has done the NP-Hard work of finding several solutions to a problem and asks for several others to bring their verifiers to bear on the solutions and identify the best one, or offer suggestions on how to tweak the solutions to move closer to an optimal solution.
Meetings cannot, however, find truly novel solutions. That's left up to the individual.
A few weeks ago I wrote up a review of Fred Brooks' great book, The Design of Design and felt inspired to create this poster to summarize my favorite chapter on "Technical Aesthetics". Take a look! If you're interested in a printed copy, shoot me a message.
For my ally is the Internet, and a powerful ally it is.
Bandwidth creates it, makes it grow. Its energy surrounds us and binds us. Luminous beings are we, not this crude matter. You must feel the Internet around you; here, between you, me, the desk, the router, everywhere, yes...
Even between the browser and the server.
Unless your system is explicitly designed to perform well at unbounded scale, impose a limit. Do not allow the system to simply degrade in performance at "unlikely" scales.
Users can and will abuse the amount of things they can cram into any opening you provide.
“This is is my compiler. There are many like it, but this one is mine.
My compiler is my best friend. It is my life. I must master it as I must master my life.
My compiler, without me, is useless. Without my compiler, I am useless. I must execute my compiler true. I must code straighter than my bugs who are trying to stop me. I must debug them before they drive me insane. I will...
My compiler and I know that what counts in development is not the code we deploy, the noise of our release, nor the launch parties we throw. We know that it is the shipped features that count. We will ship…
My compiler is human, even as I, because it is my life. Thus, I will learn it as a brother. I will learn its weaknesses, its strength, its parts, its accessories, its specification and its output. I will keep my compiler optimized and ready, even as I am optimized and ready. We will become part of each other. We will...
Before God, I swear this creed. My compiler and I are the defenders of my product. We are the masters of our competition. We are the saviors of my life.
So be it, until victory is ours and there is no competition, but monopoly!”
Inspiration: The Rifleman's Creed
Found this remarkable little quip on Quora:
“To accumulate dollars at the 10^9 level all you have to do is come up with a 10^10 idea that will make your investors and perhaps a few key others wealthy at the 10^8 level, make a few score of your early talent wealthy at the 10^7 level, make hundreds wealthy at the 10^6 level, pay a lot of people at the 10^5 level, pay a lot more people at the 10^4 level all with a product that will offer millions a 10^2 advantage or tens of millions a 10^1 advantage. Then, get at the end of the line, keep your fingers crossed and wait your turn.”
