Sunday Wisdom No. 68
When you take a position the market disagrees with, or build upon an idea that everyone says is ridiculous, it pays off tremendously. Being a contrarian has its benefits. But how do you become one?
Welcome to Issue 68!
👋 Hi, I’m Abhishek. Welcome to Sunday Wisdom—a weekly advice column on decision-making, clear thinking, creativity, and everything else that’s stressing you out in business and life. I appreciate you being here. If you are loving Sunday Wisdom, you can buy me coffee or share this newsletter with a friend.
What I’m Thinking
When Everyone Thinks They Are Contrarians
Peter Thiel, the billionaire investor, has a famous question of his own: What important truth do very few people agree with you on? A good answer takes the following form: most people believe in X, but the truth is the opposite of X. But who are these most people?
It’s a well-known fact that in investing and startups, you get an edge if you can think against the crowd. When you take a position the market disagrees with, or when you build upon an idea that everyone says is ridiculous, it pays off tremendously (if it pays off at all). Being a contrarian has its benefits. The question is, how do you become one?
10 Lessons from Stumbling on Happiness
Stumbling on Happiness by Daniel Gilbert is one of my favourite books. I often recommend this as the first book to read if you are getting started in psychology. This books changes everything we know about human behaviour. We aren’t rational beings who behave emotionally sometimes. Instead, we are emotional beings who behave rationally sometimes.
In this video, I give you the key lessons from this excellent book. This isn’t a summary of the book. My goal is only to make you curious enough to read the whole book.
What I’m Working On
Thanks so so much for all your inputs on the workshop that I’m planning to conduct. I’ve collected a lot of feedback so far. Some of you suggested I call it a course instead of a workshop. I think it makes sense.
Today is the last day to share your inputs about the course—the topic you prefer, the kind of learning experience and interactions you are looking for, etc. I’ll close the submissions after that, and get started on shaping the course. I’ll share more details in the upcoming weeks. Stay tuned!
What I’m Learning
Measuring Developer Productivity
If you are a CTO or a technical manager, you are familiar with how hard it is to measure productivity in your team. My best friends are developers, and I’ve worked with countless developers over the years, so can closely relate to the problem. This piece sheds some light into the problem, and proposes some solutions.
‘Hours worked’ is a false metric to measure job performance. Working hours are seen as non-negotiable in all workplaces, and being “Available” is seen as proof that someone is working. As time goes on, the workplace becomes a place where everyone is working but nothing is getting done. This is counterproductive.
All work isn’t positive work. Developers who work while exhausted, distracted, or sick tend to do ‘negative work’—work so poorly done that it must be undone or compensated for later, thus increasing rather than decreasing the amount of work remaining.
Measuring individual productivity in terms of bugs fixed, tasks completed, or features shipped is equally futile. If the goal is to fix more bugs, developers can write intentionally buggy software and then write a plethora of fixes. If the goal is to ship features, they can write them quickly and naively, resulting in barely functioning software. If the goal is to finish tasks, the each developer would jockey for the easiest tasks, leading to internal politics.
Creativity doesn’t happen all the time. Individual productivity tends to vary greatly over the short term, thereby stifling efforts to track it with any specificity.
But it can be safely assumed that a team that produces useful software on a regular basis is productive. Since teammates tend to be well aware of each other’s contributions (whether measurable or not), any serious failings in individual productivity can be discovered by means of good organisational habits—such as one-on-one interviews.
‘Velocity’ is an aggregate measure of tasks completed by a team over time, usually taking into account developers’ own estimates of the relative complexity of each task. It answers questions like, “How much work can this team do in the next two weeks?”
Understanding the velocity of a team can be foundational as you prioritise feature development, set expectations with clients, and plan the future of your products.
Yet, many organisations thrive without any hard-and-fast measures, where developers are liberated to do their best work, whenever and wherever they’re most productive.
For some, it can be frustrating to manage work that can’t be reduced to a number. But with work as nuanced and abstract as software development, the further we entrench ourselves in details, the more we defeat our own purposes. Useful software is the only goal. As long as this is met, it’s okay if one or two individuals aren’t giving their best. Forcibly measuring anything else would only give us either a false positive or a false negative.
If you want to get better at writing, you know well that it’s a continuous process. There’s always some room for development. But it essentially boils down the following practices.
Trusting your own interests. Work from your own interest; never from what you think you should be writing. Let what you want to write about be tested by time, not by people.
Taking notes regularly. This sharpens both your powers of observation and your ability to express. By taking notes, you observe more; and by observing more, you have more to note down. This starts a positive feedback loop.
Revising notes. Develop the ability to read notes (as if you’ve never read them before) to see how well they communicate. Constant revision—whether or not you’re going to “do” anything with what you’ve written—also teaches you to write better in the first place, when you first write something down.
Like all geeks and nerds, I’m a huge fan of Derek Sivers. He has a unique ability to distil ideas down to the bare essential by stripping down all the non-essential things.
In this short animation, which was part of a podcast, Sivers lays down the idea that we often put too much effort and take unnecessary stress over minutiae. In his case, something as minuscule as improving his cycling speed by mere 2 minutes after putting so much of effort.
The art of living with less stress, on the other hand, is to go out and feel the wind, smell the air, and see the sky while cycling or running—without caring about the output. Every act doesn’t have to be an act of optimisation—be it in business or in life.
👋 That’s All!
One last thing. Reading this post won’t help, unless you swallow, chew, and digest these ideas. I urge you to become a demanding reader—one who questions the author, seeks answers, and doesn’t shy away from sharing opinions and interpretations.