Listening to win vs. listening to fix vs. listening to learn. The default position for engineers and executives is listening to fix. You’re employed to move things forward and solve problems. Sales’ default position is listening to win - to convert the sale, listening to sell. But good product work requires listening to learn. You can fix it later, iteratively, but first you need to soak it in with no idea on how to fix it. (While listening to Jennifer Garvey Berger.)
Code performance, reliability, security, cleanliness. These things are not achieved through big sweeps and special efforts. They are only really possible by baking the practices into every day and each decision. You can’t focus on fixing them for a week. You need to invest in them slowly, constantly, over the life of the project. (Thoughts after reading about why NetNewsWire is fast, listening to a code audit webinar, and thinking about how we’ve done so much with 2 engineers at OfficeLuv.)
If you release software, you’ll need to communicate new features and bug-fixes to your users. Eleni has written about how OfficeLuv practices writing our customer-facing blog posts announcing features before we build, but we don’t announce every feature in our customer-facing changelog. We do, however, put out an internal product release email every week. It has remained a constant pulse over our 4 years, but we’ve improved the structure and content over time.
Identifying too many aspects of ongoing product work as tech debt has caused engineering teams to over-invest too early. They fear the tech debt in the future if they don’t make the decision now that’s perfect for that orders-of-magnitude-bigger future. They think tech debt can be avoided with more tech investment, but I don’t think it works that way. You want to invest slowly and constantly, just like the stock market.
So many people think they can time the stock market right and buy the dip - engineers think the same way and try to predict where they should invest heavily up front. Instead, invest where you know you need it and then expand that investment as you expand the product.
The actual nerdy economics joke there is in the second paragraph, which takes the form: Two economists are walking down the street. One of them sees a $20 bill on the ground. As she bends to pick it up, her colleague says “don’t bother, if that was a real $20 bill someone would have picked it up by now.” She replies, “no see this was left here by a consumer tech startup trying to maximize user growth; their Monthly Active Picker-Upper numbers are doubling every two months.” She picks up the $20 bill and the startup raises money at a $2 billion valuation.
via Matt Levine, my favorite journalist of the last decade, by far.
At OfficeLuv, we track our individual tasks into epics, like most other product teams. Also like most others, we’ve had one ongoing group called ‘Tech Debt’ since day 2. Recently, I went grooming through a bunch of the stories in there and decided to break that topic into two separate ideas, one for Tech Debt and one for Tech Investment.
In product research, people sometimes make the mistake of ‘validating’ their product idea by interviewing customers and describing the most generic version of their product. The customer already has a problem, so a product generic enough to solve all their problems sounds wonderful and they want that. But once you get down to building specifics and you haven’t solved all the problems right away, they won’t switch away from the incumbent solution because it doesn’t solve one of their problems better.
Software engineers are a similar way, in that they consider new technology often in generic terms and use cases. Oh that new tech idea? It’s better than everything you’ve been doing. Let’s adopt it everywhere. It’s the new best pattern. Then you get down to specifics of usage and the engineers have built terrible patterns of specifics off a promised generic that doesn’t exist.
I’m reading Edward Tufte’s Visual Explanations and the depth makes it a slow read. It’s like a museum. It takes ten minutes to read a page. I’m exhausted after only a few pages (rooms) and can come back for multiple days to a single topic.
The right data structure precipitates elegance and performance. “Re-think the data structure, gain better insights in the distinction between how the data is produced and how the data is consumed.”
Recently, we had an opportunity to trivially parallelize some ActiveRecord queries in our Ruby server. In a common response structure, we needed to both query for the actual data requested along with some meta-information about pagination, etc.
This morning, Eleni and I were reflecting on how our queueing system has evolved at OfficeLuv over the past year.
I read this book as my partner’s father fell away from us at the hospital and it will forever stick in my mind for that reason. The way it portrays memory and experience resonates so much with me - enough to overlook the more movie-esque aspects of the author’s style and characters.
After interviewing all Summer and Fall, we’ve found the next member of our OfficeLuv Product Team, a talented and thoughtful software engineer.
After interviewing all Summer and Fall, we’ve found the next member of our OfficeLuv Product Team, a talented and thoughtful software engineer.
In lieu of writing recently, I spoke quite a bit elsewhere.
In the past, I’ve talked with my good friend Vaibhav Krishna about how important it is to recognize your mental reserves and drives as an exhaustible resource. Writing and dissecting software, you will often feel the tug of an idea. Just as often, you will be set upon a problem and find no interest grow as you dig fingers into the solution.
I’m hiring a new full-stack engineer for the OfficeLuv team, and there’s nothing quite like a new hire to kick your team into shape. I’ve written about how new hires are a valuable resource in the past, and each time I focus on drawing more and more value. This current cycle I’ve already noticed a change in my behavior in these past few weeks: I’m cleaning up in anticipation of guests.