The Software Ark: Issue 14
Quote of the week
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.
- Eisenhower
Articles
A lot of people talk about a low meeting environment, and about having the freedom to "get things done". But they don't usually talk about what you should use the time to do. Often you need to pick the work that you want to do, and in turn where you want to invest your time. Moreso as you get more and more senior. My rule-of-thumb: you have to like it; it has to be something that no-one else seems to be paying attention to; and if someone doesn't look at it, it's going to blow up. Any 2 out of 3 isn't bad.
One thing that someone told me when it came to code-reviews always stuck with me. Typically more than one person reviews the code. Someone will catch the little annoying things. A typo, or a bug in an if-else clause will be caught soon enough. But things like package structuring, documentation, exposed interfaces, naming - those will live on and won't be changed. That's what you really need to focus on. If you catch a bug - that's great! If you manage to help restructure the code so it's easier to understand, not only will it make it easier to catch a bug, but future devs will thank you.
Distributed computing manifesto
Coming to Meta, the mono-repo, everyone can access the database, tangled-ball-of-code approach really took me by surprise. Especially because it seemed like a problem that the industry had seen before:
The applications that run the business access the database directly and have knowledge of the data model embedded in them. This means that there is a very tight coupling between the applications and the data model, and data model changes have to be accompanied by application changes even if functionality remains the same. This approach does not scale well and makes distributing and segregating processing based on where data is located difficult since the applications are sensitive to the interdependent relationships between data elements.
It parallels some of the issues I've noticed at Meta. One team makes changes to another's data-model, or assumes something based on another team's data model, and BAM we've got an outage. In my head, this comes part and parcel of how we think about system boundaries. In WWW those boundaries just don't seem to exist.
That's not to say it's without benefits. The rate of change, and the speed of pushing out new features is highly accelerated. The degree to which you need to coordinate with another team is vastly reduced. It's a lot easier to unblock yourself. But it makes monitoring and tracking a lot more complex, since the entire universe of actors is a lot less predictable. Moreover, enforcing quality standards becomes tough as well.
Butterfly rules for new code being pushed, VC based throttling limits, public entry points for callers, etc. can all provide similar benefits atop WWW. It's one of the things I'd like to look into - the middle ground. How do we get some of the benefits of SOA, without loosing the speed that a monorepo affords.
Also a good read: https://12factor.net/
Links
- Estimated review time can improve PRs and reduces cycle time
- Precision time protocol at Meta - a 100x perf improvement atop a probabilistic TrueTime API. Since consumers aren't an RTOS - I wonder what happens if the system hangs.
- Twitter is not a digital town square; it's a digital cage match with PPV tickets
- Product development: balancing conflicting goals, also a good read is the MBA pathology.
- Functional JS is cool - don't you love monads!. Poorly written, but the article has a lot of useful information if you're new to functional programming.
