Clippings of 2020 May
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
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.
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
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.
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.
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.
Some of the best roadmaps...— John Cutler (@johncutlefish) November 6, 2018
* mention 0 features
* use no shorthand (e.g. "redesign V2.0")
* are not on a timeline (have no dates)
* mention Who and Why
* tell a compelling story
* acknowledge uncertainty
* set qual and quant goals
* embrace incremental delivery#youcandoit!
Similar to what the best OKRs look like.
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.
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?")
My biggest question with writing HTML/CSS components is how to split responsibilities between
This post answers this question.
Again, no abstraction is better than wrong abstraction
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.
Funny yet true.
- 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.
- The State of (Full) Text Search in PostgreSQL 12
- Build versus buy.
- Poking around Contentful.
- You can't reason about big balls of mud.
- Minding our stories.
- Fly-out menus by Steve Schoger on Dribbble
- Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin - The Pragmatic Bookshelf
- Live video streaming from iOS devices made simple with Elixir & Membrane Framework
- ayesql/README.md at master · alexdesousa/ayesql
- Speeding up re-compilation of Elixir projects - Dashbit Blog
- Elixir Quiz that tests your Knowledge in Elixir Programming - Telegram: Contact @QuizBot
- Created a new HTML export back-end that uses Tailwind.css classes - emacs
- Getting in the room. （where important decisions are being made)
- Learn to never be wrong.
- How to Get Your Team to Challenge Your Ideas - The Founder Coach
- The Difference Between Art and Design - Webdesigner Depot
- Daring Fireball: The iPad Magic Keyboard
- Coding for Fun
- Dan Abramov on Twitter: "Junior roles = learn the data flow Senior roles = be the data flow I wish someone explained this to me like five years ago" / Twitter
- Working Together to Prioritize Your Product
- Working Remotely is a Skill
- Picking problems for programming interviews.
- Feature-less Roadmap: The Balance Between Delivering Concrete Features vs. Planning with High-level Themes
- Spotify’s Failed #SquadGoals
- Secrets of a Strong Engineering Culture
- Staying aligned with authority.
- The 3 R's of Habit Change: How To Start New Habits That Actually Stick
- select * from depesz; » Blog Archive » Explaining the unexplainable
- OFFSET is bad for skipping previous rows
- CSS Animation for Beginners
- Designing for incremental adoption
- Ying Zhong on Twitter: "我对写界面这件事的观念经历了三个阶段。https://t.co/Z5L9bQ0DOf" / Twitter
- Heroku vs self-hosted PaaS - Magnus Skog
- Celebrating 15 years of Git: An interview with Git maintainer Junio Hamano - The GitHub Blog
- Feature Flags: The stupid simple way to de-stress production releases - Boring Rails: Skip the bullshit and ship fast
- Jim Weirich on exceptions - Virtuous Code
- Jim Weirich on the differences between procs and lambdas in Ruby
- Choosing Tools for Test Doubles - The Code Whisperer
- Optimizing A Program (And Programming) - Video - GeePawHill.org
- My journey from “Agile” to “product teams” - The Startup - Medium
- Test Double - Our Blog - Our Pair Programming Ethos
- So, how much maintenance is (precisely) enough, huh?
- Choices: Engineering, Organizations, and Constraints · John Obelenus