Clippings of 2019 May
How hard you work is less important than how smart you work.
- 我的职业生涯的成长， 最根本的不是你有多努力，有多勤奋，而是你能搞定很多人搞不定的事！
- 同样是一个简单的 for-loop 语句，有人写的就值 1 万元一行，而你写的则一文不值。关键不在于谁写的代码多，关键在于我们解决了什么样的问题。
I'm trying to use OKRs in my current company recently. But I didn't know exactly how to do it after reading Measure What Matters. This article helped a lot by providing a real world example at Swipely.
There is no silver bullet. Not in the development world, not in the management world.
- Just because a system’s worked like gangbusters before, doesn’t mean one size fits all. You have to figure out how to put OKRs to work for you.
The purpose of implement OKRs is to talk about the purpose.
- The right way to look at OKRs is a way to communicate so there's
clarity of purpose
- At Swipely, (personal) OKRs are made up of
- a high level objective
- a more detailed description of why that objective is important
- a summary of how the objective aligns with the broader goals of
both the person's team and the company
- When personal objectives are directly and clearly connected to the broader goals of the company, they're suddenly more inspiring, less myopic
- the three to five key results that will help them achieve that goal
- Having public goals forces different types of thinking around how
people ask for help from others
- everyone can see what's on their co-workers' plates and employees no longer feel like they're toiling in a vacuum, or for their manager's approval
- That way, OKRs become a built-in way for people to
- ask for resources,
- easily spot where they can come to their colleagues' aid
- At Swipely, (personal) OKRs are made up of
- The right way to look at OKRs is a way to communicate so there's clarity of purpose
Paul, a member of Swipely’s engineering team
Objective: Ship [X] feature to increase engagement. Description: Our [X] will allow merchants to access Swipely anywhere, increasing engagement, value and differentiation which will reduce churn and differentiate our offering with an exciting new value proposition. Alignment: A company-wide objective is to “Become a ‘must-have’ tool merchants love to use,” which has a key result, “Ship [X] product to increase engagement and drive excitement in sale.” The individual objective to ship [X] is aligned with this company-wide objective. Key Results: Deliver alpha version to targeted devices for alpha testing feedback from 10 early customers by [date: mm/dd/yyyy]. Provide screenshots/screencast to support marketing launch of the app by [date: mm/dd/yyyy]. Release beta version by [date: mm/dd/yyyy]. Achieve engagement DAU / MAU metric of [X] with beta audience.
Cindy, a sales account executive who wants to turn more dials into demos.
Objective: Develop better prospecting skills. Description: By improving prospecting skills, I will get into more initial presentations and win more business! Alignment: A company-wide objective is to “accelerate revenue growth,” which has a key result, “grow booked ARR by $XX to $YY mm, thanks to new AEs, channel, and fully ramped AEs.” The individual objective to improve prospecting skills is aligned with this company-wide objective because it will help Cindy attain her quota targets. It also aligns with a company-wide objective to strengthen the team. Key Results: Review training materials from our online coaching resource. Do 2 60-minute game tape reviews with the sales manager, reviewing 20+ prospecting calls for coaching on what’s working, what’s not working. Do a role-playing session with Allie, who has our team’s top connect-to-meeting rate. Test 5 new “compelling reason” pitches on prospecting calls to introduce humor, rapport and other techniques. Increase my weekly connect-to-meeting rate from X% to Y%.
After reading this article, Carta became a company that's very appealing to me.
- Who don't want to work at a place to create leverage, not efficiency?
- Who don't want to work a place to learn and execute what's learned?
P.S. The talk We are Software People mentioned in this article is also great! Highly recommended!
- We are Software People
- Every day we deliver “an amazing customer experience at scale” and “suck more of the world into our software.”
- You don’t have to be an engineer to do this.
- You just have to believe that your job is to translate real-world problems into software problems.
- Nobody at Carta does the same thing everyday.
- Everyone is working to put themselves out of a job.
- This is our “creative destruction” that drives us to evolve, grow, and adapt.
- Create Leverage, Not Efficiency
- They are different.
- fixing a desired output and minimizing the effort to achieve it
- maximizing the impact for a fixed amount of effort
- Efficiency is what lazy people aspire to. Leverage is what we do.
- Learn vs Execute
- There are two types of work that you will do on a daily basis.
- In any role there will always be an initial learning phase before you get brought up to speed
- At a certain point your learning will plateau -> executing
- Applying that knowledge to get the job done and create leverage
- Eventually, you will create enough leverage to automate the job or grow out of it -> learning
This article resonated with my experience of fighting procrastination so well. The only way to fight procrastination is to start doing things poorly.
And I think it can also relate to the idea of MVP: a MVP is how a product is doing poorly. So MVP can help you validate your idea. If your product is worth doing, then the MVP would be worth doing, and you can see that by the feedback from its user.
- When it comes to implementing an idea, things that are worth doing are worth doing poorly.
- Why many things don't get done at all because the concern for perfection trumps the practice of "just do it?"
- Five Reasons Why Anything Worth Doing Is Worth Doing Poorly
- Clarity comes from action, not thinking
- Creativity flows when you don't block it
- Energy is created from action
- Growth comes from progress, not perfection
- Momentum becomes self-generating when you stay focused on the immediate next step
I'm glad that I'm already doing some of the things mentioned in this article. For example: this Clipping section is exactly how I make my curations.
And I learned that I need to share my ideas more often. For now, I only keep a list of ideas in my local and never share them with others before I finish a blog post. From now on, I'll share these ideas with my friends and also on Twitter.
- A way to "bootstrap" your way to an audience: curation
- The Thought Leader Strategy
- curate a summary of your favorite thought leader's best work.
- The Idea Strategy
- pick an idea you're interested in and curate a list of the best resources on the topic.
- Listen to feedback
- Test your ideas out on intelligent friends, and don’t be afraid to state the obvious.
- If an idea consistently surprises somebody, it’s probably good,
- but if people look bored or confused when you’re sharing an idea, you should either drop it or communicate the idea differently.
- Many writers wait until they publish a blog post to share an idea with somebody. I do the opposite. I share my ideas as much as I can and run them through numerous filters.
- blog posts
- With it, we had instant access to more wisdom, experience, perspective, and diversity, in one minute than we could have gained in a hundred lifetimes.
(There are many more great ideas in this article. Please do check it out if you also want to write online!)
Another accurate summary from Kent Beck.
Great reminder yesterday of how much of project management boils down to: deliver half the stuff in half the time. If you're always thinking about how to do that then the details will sort themselves out.— Kent Beck (@KentBeck) May 30, 2019
And there is an idea that's exactly the same in DevTernity 2018: J.B. Rainsberger - The Economics of Software Design #devternity – Watch Video @ Dev.Tube.
- Almost every problem boils down to long feedback cycles (two people don't like to talk to each other)
- Cut it in half
- It's already hard enough to change the way you work
- It's challenging enough that make you energized enough to work on it
- Repeat when half the length feels long again
- Million Dollar Consulting: Alan Weiss: 9780071622103: Amazon.com: Books
Joe's reply to The OOP Concept according to Erlang - Erlang & BEAM Forum / Questions / Help - Elixir Forum
I want to say I'm so sad that Joe Armstrong passed away on Saturday April 20th, 2019. I learned so much from Joe's work and writings. It's such a pity that we've lost a great mind and a great soul.
- To me
- an OOPL has the following properties
- Isolated objects (= Erlang processes)
- if one process can in any way damage another object then you cannot write decent code
this makes life easy for the programmeryou could send a “print_yourself” message to any process and it would know how to deal with it
- Late binding
- You can send a message to a process, and send code to a process, provided the code gets their first, everything is fine
- Dynamic (possible to evolve in a biological sense)
- keeping the entire world strongly consistent (in the sense of a strict type system) is impossible - even types change with time - in live systems the code must be able to evolve.
- All this stuff about classes and methods is “just” a way of defining and grouping abstract data types.
- Inheritance is just a hack - in Erlang/Elixir you can just send a message down a chain of processes until somebody recognises it.
- In my opinion
- Erlang/Elixir/Pony etc are the only languages which can be called OO.
- Java/C++/Smalltalk do not protect objects - send a “message” (or evoke a method) that leads to an infinite loop and you screw up the system.
- Erlang/Elixir are rather nice send a message to a process that sends the process into an infinite loop and you won’t even notice it.
- I had always (and still) viewed this reuse stuff as total nonsense
- functional re-use is possible
- but the non-functional properties of a program cannot be re-used.
A funny show but full of useful thinking around code reviews. If you care about how to do code reviews in your team, it is a must watch.
- Your team’s code review practices cause ripple effects far into the future. In this play, see several ways a single code review can go, then fast-forward and rewind to see the effects – on codebase and culture – of different code review approaches.
At first, I'm thankful and happy to have the opportunity to spend more time on the management side when I'm just two years into this industry. But sometimes I still wonder if this is too early. After reading this post, I'll no longer be so confused and will be more thankful for this chance.
Tech is the easy part, herding humans is the harder part.
The Lisp code auto-generation demoed in this talk is amazing. And the process that was driven by test cases reminded me of how TDD works. If you are interested in Artificial Intelligence, TDD, or how to write programs in general, you will not regret spend some time watching this talk.