Hey there, hope you have an amazing week!
Articles to Read.
Earnestness sounds like a boring, even Victorian virtue. It seems a bit of an anachronism that people in Silicon Valley would care about it. Why does this matter so much?
When you call someone earnest, you're making a statement about their motives. It means both that they're doing something for the right reasons, and that they're trying as hard as they can. If we imagine motives as vectors, it means both the direction and the magnitude are right. Though these are of course related: when people are doing something for the right reasons, they try harder.
The reason motives matter so much in Silicon Valley is that so many people there have the wrong ones. Starting a successful startup makes you rich and famous. So a lot of the people trying to start them are doing it for those reasons. Instead of what? Instead of interest in the problem for its own sake. That is the root of earnestness.
It's also the hallmark of a nerd. Indeed, when people describe themselves as "x nerds," what they mean is that they're interested in x for its own sake, and not because it's cool to be interested in x, or because of what they can get from it. They're saying they care so much about x that they're willing to sacrifice seeming cool for its sake.
A genuine interest in something is a very powerful motivator — for some people, the most powerful motivator of all. [3] Which is why it's what Jessica and I look for in founders. But as well as being a source of strength, it's also a source of vulnerability. Caring constrains you. The earnest can't easily reply in kind to mocking banter, or put on a cool facade of nihil admirari. They care too much. They are doomed to be the straight man. That's a real disadvantage in your teenage years, when mocking banter and nihil admirari often have the upper hand. But it becomes an advantage later.
—
Who do we spend time with across our lifetime?
Who we spend time with evolves across our lifetimes. In adolescence we spend the most time with our parents, siblings, and friends; as we enter adulthood we spend more time with our co-workers, partners, and children; and in our later years we spend an increasing amount of time alone. But this doesn’t necessarily mean we are lonely; rather, it helps reveal the complex nature of social connections and their impact on our well-being.
—
How Payment Transaction Processing Works
You encounter the key players involved in payment transactions daily, whether it’s your credit card company or bank. Merchants and processors are also involved in transactions, but consumers are often unaware of the extent of their roles.
When a consumer swipes their card, the merchant’s bank will send out a request for authorization via the payment network. The card company then runs payment details through a variety of fraud-protection tools to validate the information.
Once the payment network confirms the authorization message, it sends a request for payment to the issuing bank (the consumer’s bank).
—
It’s basically a sacred project management mantra by now: divide your work into tasks that are as small as possible. Estimate them with your team. Then drop them into the all-knowing product backlog. But no one seems to be looking very critically at how this practice has affected the software engineering profession. Back in the 90’s, when I started programming, this was not how it worked. It was, dare I say, a little more professional.
Back then, your boss had a dozen or more things they were responsible for and when you got hired they breathed a deep sigh of relief.
“Finally, now that Vincent is here, I can make him do A and B; and with Ted doing C, D, and E and Jan doing F, G, and H, I can finally get to I, J, K, L, and M.”
Most importantly, A and B were big things, like whole products or large system libraries. Building and maintaining them consumed all of your time. They were your delegated responsibilities, not mere tasks. It wasn’t that hard to manage people this way either. If you weren’t doing a good job, the boss would let you know.
Then you went back to your private office (I sure miss private offices, but that is a topic for another day) and fixed a few things. Later, in a weekly status meeting you would tell people how it went — yep, that’s right, no daily stand-ups where you look mournfully at your shoes and admit that you didn’t make any notable progress yet.
No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a healthy portion of “give me some space to do my work.”
The way we work now is different. Sadly, it’s less motivating, less efficient, and profoundly less respectful of individual abilities.
—
Complexity in software, whether it’s a programming languages, an API, or a user interface, is generally regarded as a vice. And yet complexity is exceptionally common, even though no one ever sets out to build something complex. For people interested in building easy to use software, understanding the causes of complexity is critical. Fortunately, I believe there is a straightforward explanation.
The most natural implementation of any feature request is additive, attempting to leave all other elements of the design in place and simply inserting one new component: a new button in a UI or a new parameter to a function. As this process is repeated, the simplicity of a system is lost and complexity takes its place. This pattern is often particularly obvious in enterprise software, where it’s clear that each new feature was written for one particularly large customer, adding complexity for all the others.
Escaping this viscious cycle is not easy. One can easily say, “so reject all feature requests”, but a project that does so will eventually find itself unable to serve its users’ needs at all! Our approach must be more measured: we need to spend as much time thinking about how a new feature will burden all of our users, as we spend thinking about how it will benefit some of our users. We should also spend time thinking about how to design new features in a way that maintains what Fred Brooks’ called the “conceptual integrity” of a system, rather than by merely tacking something new on.
—
A common piece of interacting-with-people advice goes: “often when people complain, they don’t want help, they just want you to listen!”
This always used to seem silly to me. If I complain at my partner and she “just listens,” I’ve accomplished nothing except maybe made her empathetically sad. When I complain at people, I want results, not to grouse into the void!‡
I say this with great respect for Nonviolent Communication, but these sound like a 1970s-era chatbot. If I were Person A in either of these dialogues my next line would be “yes, you dingbat—can you turn the nonviolence down a couple notches?” I’d feel alienated knowing that someone is going through their NVC checklist on me.
Recently, I realized why people keep giving this weird-seeming advice. Good listeners do often reflect words back—but not because they read it in a book somewhere. Rather, it’s cargo cult advice: it teaches you to imitate the surface appearance of good listening, but misses what’s actually important, the thing that’s generating that surface appearance.
The generator is curiosity.
┄
More to Check Out:
- We can have democracy or we can have Facebook, but we can't have both
- The Games People Play With Cash Flow
- How to Escape a Sinking Ship (Like, Say, the Titanic)
- Google Alternatives
- If then else had to be invented
My Update:
Happy Chanukah!
In Los Angeles (Santa Monica).
I miss traveling—next year!