Clippings of 2020 May

Competing Against Luck: The Story of Innovation and Customer Choice

After reading this book, I can see Jobs everywhere:

  • We hire a taxi to go from location A to location B.
  • We hire a light to help us see things in the dark.
  • We hire a mobile phone to contact with our families and friends.

Seeing Jobs in our lives is just the beginning. Jobs are highly contextual.

  • Some people hire an iPhone to take photos with a small device.
  • Some people hire an iPhone to bring musics with them all day.
  • Some people hire an iPhone to play games during commute.
  • Some people hire an iPhone to just make phone calls.

Understanding these pain points where our users struggle to make progress in their lives is the key for innovators like us to learn the problem we need to solve. Only by understanding the problem to solve, can we improve the existing product (like iPhone) in these various contexts, or create a new product to solve a specific Job under a specific context better.

Jobs to be done theory helps us realize the context around a Job, understand the real struggle hidden behind an existing solution, so we can identify innovations and compete against pure luck.

Solving the problems is just the beginning. In this competitive market, customers can always find more than one solutions for the same problem they are struggling with. What distinguishes us from other competitors is not only our product, but the experience we are providing. By providing an unique experience for our customers, we can get the unique competitive advantages that cannot be copied anywhere else.

Don't Worry, There's a Method to the Meeting

It's interesting to think of meetings as functions in programming. Think about the output you want to get from your next meeting.

P.S. I also wrote a similar blog post before: Similarities between TDD and Management

Creativity Is a Search Problem - Teng Bao

Maybe god wanted to solve a problem, but god didn't know how to solve it. So god created human race to search the answer for him/her.

Design Patterns for Progressive Complexity - Teng Bao

The differences between Graceful Degradation and Progressive Enhancement reminded me of two ways of writing code:

  1. Abstract first, degrade later
  2. Duplicate first, abstract later

If we want to write code that's better designed and more readable, maybe we prefer Progressive Enhancement over Graceful Degradation, too.

Maker vs Multiplier - patkua.com

A great leader needs to create an environment to boost team member's productivity. So it's more like a multiplier, less like a maker.

John Cutler on Twitter: "Some of the best roadmaps... " / Twitter

Similar to what the best OKRs look like.

Team Objectives Archives - Silicon Valley Product Group

After several months of using OKRs in my company, I can feel the similar pain points mentioned in this post. You cannot force people to define individual OKRs. It would only back-fire if you do so. What you can do is to define team objectives together, so these objectives bond us together as a team.

The only truthful answer to any question about management — Quartz at Work

Of course it's "It depends."

Just like the only truthful answer to any question about development: "it depends."

(The next question you should ask is "Depends on what?")

Layout-isolated components

My biggest question with writing HTML/CSS components is how to split responsibilities between divs. This post answers this question.

Sebastian Markbage: Minimal API Surface Area - JSConf EU 2014 - YouTube

Again, no abstraction is better than wrong abstraction

Complexity Has to Live Somewhere

So the only way to reduce complexity is to remove it completely. That's why we need to keep things simple and minimal. If we don't do so, complexity would creep into our system.

Burnout with Aneika and Anjuan Simmons by Storytime With Managers • A podcast on Anchor

  • get familiar with your team, know their normal behavior so you can detect burnouts (get familiar with real Money to detect fake money)
  • encourage relationship building
  • having a track record of getting things done (shopping workable software)
  • healthy team makes healthy code

When I evaluate a team, I used to ask "what tools are you using", "how's the code quality", etc.. But these are just the results of a healthy team, it's more important to evaluate the team as a whole. In a healthy team, everything would follow.

中文互联网中“讨论”的消亡 - 机核 GCORES

解决的方式只有对话；惟有理性的对话才能消解矛盾。没有地方讨论，只会有更多的两极化，更多的简化和污名化，更多无意义的争端。

Non-Top