Externalizing
If your startup is worth doing, then you probably imagine a world where something is done differently, in a way you consider better.
Creating a product is part of that, but it revolves mostly around bending the real world around your vision and driving it there. Huge part of that is guiding other people to realise that they themselves want to go there.
My mentor once said that the main job of any principal engineer or architect is writing things down.
This is going to be an attempt at that.
There is going to be a short essay or tech writing every Tuesday, and collection of readings every Friday.
Hope you'll enjoy that.
Friday Readings
This is part of Friday Readings series: commented readings I find worth sharing. If you want more, follow me on Pocket.
Technology
EBay shares the traps they encountered when entering node.js ecosystem. Worth reading, especially if you are unsure on how to approach testing.
I am currently heavily looking into various ways to make the whole infrastructure set up declaratively. Terraform is one of the promising pieces and Building your infrastructure with Terraform is a valuable guide.
There is a magpie developer in most of us and its worth repeating their pitfalls.
Let's say that original Paxos paper wasn't quite enjoyable reading for me, so Standford's Paxos lecture made the world more comprehensible for me.
Ever felt bad about bugs in your inital version? Well, check out bug list in a figher jet. That's what you get for writing software with direct real-time consequences.
Leadership and company building
Radical Candor — The Surprising Secret to Being a Good Boss is an interesting point of view on how to segment approaches with leading people. Central point—how do you provide guidance (or feedback) to those around you.
Do fewer things, better has been beaten to death (especially if you followed Leo Baobuta in his beginnings), yet it's still worth repeating, at least for me.
World around us
On assimilation of different cultures; point of view affected by current immigration crisis, but good point nevertheless.
Health
When painfully recovering from not drinking caffeine for few days, I've stumbled upon caffeine sensitivity article, part of very good Caffeine Informer. I knew caffeine have various effect on various people, but I didn't knew we've untangled the genetic background and rough brackets of what is "safe dosage" for them.
Choosing technologies
Every other week, some of my technology problems are magically solved by some new service, language or database. Except when aren't.
While there definitely is a progress in technology, theoretical breakthroughs are more rare than everyone would like to. Instead, we do have a list of constraints and trade-offs that are changing over time, and they enable different set of technologies.
As an example:
- L-cache is the only way to cache data, everything else is too slow! Except it got faster, so use that, but store everything on disk because RAM is super small. But now it got large enough to store useful datasets, so don't even dare to think about touching disk! Oh wait, SSD
- Disk may be slow comparably to RAM, but with reasonably stable I/O latency. Dang, have you seen those spikes on our virtualisation platform? Let's rewrite everything! Oh, containers
- Our database must be always consistent and don't store any duplicate data, 3NF is the king. Oh wait, count performance. Distributed datacenters and availability, OK
- Nodes are cold, stable hardware and we can rely on it. Oh wait, cloud. Elastic scaling, neat
Most of those are environment changes, caused by:
- Uneven hardware improvements (SSD changing speed/size ratio; multi-core changing single process speed vs. parallelism; GPU offering whole new field for some types of computations)
- Price changes (cloud vs. on-premise, on-demand pricing)
- Technology usability causing mass adoption(jail and LXC vs. Docker)
However, those technologies rely on the new changed environment, which usually presents some change in available trade-offs.
The same is true for growing your technology and company. When describing technologies or processes, most people still fail to talk about the scale they are talking at (I still surprise a lot of people with how small 37signals/Basecamp is; a lot of people assume enterprise with hundreds of people, and ReWork being battle-tested at that scale).
This is a major failure, because (current and expected) scale is one of the most defining characteristics. Premature scaling can kill you as much as scaling too late:
- Initially, you prefer moving fast over externalising things. Later, you need to externalise in order to move forward
- At the beginning, everything-as-a-service is definitely cheaper; over time, you hit breaking points
- Structure of your traffic is crucial for your infrastructure, and changes over time. Read or Write heavy? Cache hit ratio? Both matter
Only thing you can rely on is speed of light. Latency is not going to be any better in the future: beware of being chatty on critical path.
When choosing technologies, always be aware of the shift you are making. If you are unaware of any, downside will hit you hard.