Clippings of 2020 Feb
Table of Contents
- Top 6
- 他们有秘密武器，就是思想实验（Gedanken experimente）。
- Leading & Lagging Indicators
- Influence future performance
- We have direct control
- Fast feedback
- Analyze past performance
- Outputs (outcomes)
- no direct control
- Don't treat leading indicators as goals
- Do pair leading indicators to lagging indicators
- Don't measure just one lagging indicator
- Do understand how lagging indicators affect each other
- Don't measure things without a dilemma that drives them
- Do decide what is your reason for using metrics, and what you are trying to change
When defining OKRs, I find it hard to choose which key results to measure. This talk shed some lights for me by teaching me the differences between leading and lagging indicators.
- Lagging indicators are great candidates for Key Results, since they are out of our direct control but still can be influenced by our hard work.
- Leading indicators are not very suited for Key Results, since they are controlled by us directly and thus can be cheated easily.
That being said, leading indicators are still useful. We can use them to guide our actions. The message here is don't treat them as our goals.
If you want to learn more about metrics, I'd highly recommend this talk.
- Principles From Beyond Space And Time
- Keep the work parallel, the groups small, and the resources local.
- Prioritize the development of force multipliers.
- If possible, factor work products into independent modules; if not, grow slowly and optimize.
- Scale organizational efforts across a portfolio of synergistic products.
- Keep responsibility assignment matrices small, sparse, and local.
- Prioritize asynchronous information distribution over synchronous.
- What happens inside the boundaries is important.
- Companies are groups of people being compensated for having to spend some of their finite lifetimes not being with their partners, children, pets, or super weird hobbies.
- They deserve to be members of organizations which honor that time by ensuring that their work has value and meaning.
IMHO, most management problems come from scaling (a.k.a managing more people). When your team has only 10 people, everything's fine and moving fast. When you grow to 50, that's another problem. When 100, another completely different problem. This post explains why scaling is the root cause of these problems (from a mathematical perspective) and more importantly, some principles to guide us fight these problems.
If I want to help other persons to write all sorts of programs, should I design a small programming language or a large one?
In this interesting talk, the speaker demonstrates the power of a small language with the talk itself.
- A good programmer does not write program
- a good programmer builds a working vocabulary
- a good programmer does language design
This quote resonates with me the most.
- “What does DigitalOcean’s tech debt look like?”
- Software engineers asking about a company’s tech debt is the equivalent of asking about a credit score.
- It’s their way of gauging a company’s questionable past and what baggage they’re carrying.
- simply because something is “legacy” does not mean it is dysfunctional and should be replaced.
- a three-pronged plan for rectifying the situation:
- Decrease the number of direct connections on the database
- Refactor Scheduler’s ranking algorithm to improve availability
- Absolve the database of its message queue responsibilities
- MySQL -> RabbitMQ
A great post to learn how engineers at DigitalOcean deal with tech debts.
Should I make an estimate?
- Is time estimation the right tool for your team?
- One consequence of time estimates is that they create a de-facto deadline
- "lurking deadlines"
- not explicit
- often arbitraty
- there are no real consequences for taking an extra week to get it right, and many stakeholders are happy wait a week for a stronger product.
- The problem arises when estimating becomes a default part of the process for every new feature, regardless of what (if any) value it adds.
Two takeaways from this post:
Below are what I've read/watched in 2020 Feb. You may find some of them interesting to you. :)
- Tailwind UI Preview on Vimeo
- The Nintendo Switch was a masterstroke in a decade of ups and downs - TechRadar
- Only 15% of the Basecamp operations budget is spent on Ruby - Signal v. Noise
- 拾 - 大破进击
- Jesse‘s best of 2019 - 大破进击
- Becoming Functional - O'Reilly Media
- The Shape of Design · Home
- The Unicorn Project - by Gene Kim (author of The Phoenix Project)
- Mastering Emacs
- My book has been released in beta - The Engineering Manager
- Solving the wrong problem - <h1>Joe Armstrong - Erlang and other stuff</h1>
- The Erlangelist - Periodic jobs
- Piping Phoenix Contexts - iacobson - Medium
- LiveView Design Patterns - LiveComponent and the Single Responsibility Principle · Elixir School
- Building Hex Diff
- Toby 'qubit' Cubitt - Lost or corrupted undo-tree history
- Learning to Love Emacs - The Chronicle
- How we built Picture-in-Picture in Firefox Desktop with more control over video - Mozilla Hacks - the Web developer blog
- Give it five minutes – Signal v. Noise
- Vjeux » Reflections on Excalidraw
- Tobi Lutke 🌳🌲🛒🕹 on Twitter: "I realize everyone's twitter feed looks different. But I'll go ahead and subtweet two conversations that I see going by right now: Thread/" / Twitter
- 10 questions I wish I’d asked more to turbocharge my career
- An Engineering Team where Everyone is a Leader
- NixOS: The distribution I got to love - Thomas Kobber Panum
- Ryan Singer on Twitter: "An affordance is a piece of supply that, when integrated by the one with demand, gives them a new ability." / Twitter
- Chris Herd on Twitter: "The 2020s will be known as the Remote Work decade A few predictions of what is likely to emerge [ a thread ] 💻🏠🌍" / Twitter
- The Agile Manager: But Is It Really a Tech Firm?
- Bryan Cantrill on Twitter: "So, my thoughts on engineering performance management have always been a bit idiosyncratic, but Matt's tweets today have me reflecting, so... storytime. 1/ https://t.co/Jr9Kf23WZZ" / Twitter
- Work Is Work - codahale.com (The math of organization scaling)
- The Next Experiment? Starting My Own Venture - patkua@work
- Lower Is Faster Than ilike - Today I Learned
- The Year in Glitches
- From 15,000 database connections to under 100: DigitalOcean's tale of tech debt
- How to Improve on Naming Contexts in Domain-Driven Design - Adam C. Conrad
- How to Estimate Feature Development Time: Maybe Don't
- Goodbye, Clean Code — Overreacted
- 2019 in Review (Next.js & Zeit)
- Good times create weak men @ tonsky.me
- 《Sex Education》：性的迷思和爱的教育 - 大破进击