Table of Contents
- Competing Against Luck: The Story of Innovation and Customer Choice
- Don't Worry, There's a Method to the Meeting
- Creativity Is a Search Problem - Teng Bao
- Design Patterns for Progressive Complexity - Teng Bao
- Maker vs Multiplier - patkua.com
- John Cutler on Twitter: "Some of the best roadmaps... " / Twitter
- Team Objectives Archives - Silicon Valley Product Group
- The only truthful answer to any question about management — Quartz at Work
- Layout-isolated components
- Sebastian Markbage: Minimal API Surface Area - JSConf EU 2014 - YouTube
- Complexity Has to Live Somewhere
- Should I Test Private Methods?
- Burnout with Aneika and Anjuan Simmons by Storytime With Managers • A podcast on Anchor
- 中文互联网中“讨论”的消亡 - 机核 GCORES
- Non-Top
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.
Design Patterns for Progressive Complexity - Teng Bao
The differences between Graceful Degradation and Progressive Enhancement reminded me of two ways of writing code:
- Abstract first, degrade later
- 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.
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.
Layout-isolated components
My biggest question with writing HTML/CSS components is how to split responsibilities between divs.
This post answers this question.
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.