The Engineering Enablement podcast has been good to listen to—if a bit anodyne. The recent episode I listened to with Jeremiah Lee about Spotify’s massively popular but failed org structure was really fun and useful.
“This may surprise you, but continuous deployment is far and away the easiest way to write, ship, and run code in production. This is the counterintuitive truth about software: making lots of little changes swiftly is infinitely easier than making a few bulky changes slowly.”
A really enjoyable three part essay series by Hillel Wayne comparing software engineering with traditional engineering disciplines to see whether we are really engineers, whether we are special and what we can learn from each other.
Machine learning looks like a very challenging field to keep up with let alone to study it. This guide by Vicki Boykis gives a bunch of pointers around reading, mapping and learning that can be applied to any large field you want to get into.
The Yard Sale model is a very basic thought experiment that explains why the rich get richer and why a free market like the one we have is not fair (or free).
Looking at conversations from an improv perspective opens a lot of doors for interesting outcomes. It requires active thinking and leaning into the awkwardness both of which are good skills to practice.
A manifesto for 2023 by Robin Sloan to take nothing for granted and try out all kinds of new things. Everything old is new again and everything new is exciting.
People will talk about the wage-price spiral (which has been demonstrated to be false), but they won’t talk so much about the herd behaviour at the higher echelons of our industry.
I’m thinking back about this past year and this has definitely not been a great year. On the other hand it’s also the first time in a while where I have mental capacity to spare to even think about something like a year in review.
Even a cursory dip into the subreddits and other social media posts, whitepapers, and other documentation and community discussions surrounding generative AI, makes it hard to miss the spite and negativity directed at human creativity. They are almost necessary preconditions to be part of the development community. Ironically, of course, the developers celebrate their own creativity in building these software tools, despite the fact that they implicitly rebuke the work and lives of everyone who creates or thinks meaning is confined to living things.
Looks like we can bootstrap a web app using pretty much only Postgres for the data layer and kick out the redis cluster, the celery process and the ElasticSearch server.
Lots of great ways to manage change in organizations. It’s a bunch of work to do this, but if you skip these steps, the results can and will backfire. I particularly like the guiding policy strategy where even if I don’t know something I can usually spitball the values and invariants of the situation that will fit the result.
The autofocus way of handling todos has a charm in that it treats your work as an endless stream and tries to take the negativity and failure out of it. I now am doing something quite similar by using Things as the river and dragging tasks into my calendar which has a natural limit to it.
Reading about China’s message board theorists is amazing and makes me wish I could have stuck with Chinese. But then again I would have not learned it well enough probably ever to be able to follow what’s happening on the Chinese internet, so this will have to do.
These days, “no one is taking any creative risk,”said Laura Mayer, a veteran podcast executive and producer who’s worked at several large publishers. “We’re seeing plenty of efforts to reverse-engineer what were successes in podcasting, and as a result, we get a lot of watered-down karaoke attempts at what worked out in the past.”
Seeing that Gitlab had published their TeamOps framework, I stayed up late to get my certification. I especially liked the recorded meetings with Sid Sijbrand and other Gitlab senior staff that they have published on YouTube.
Running multiple strategic tracks will set you up to dominate at a large scale, but many organizations can’t run one let alone run multiple at the same time. The visualization and plays as described here by Itamar Gilad look a lot like Wardley mapping.
Product sense (and taste) are so important but so hard to pinpoint and teach to others. Lenny here unpacks what goes into it but even then there are very few shortcuts to getting it.
A short guide of how a team can turn around the work they need to do on a legacy system and come out the better for it. I’ve seen lots of teams struggle with this but as described here a lot of it is in the approach and the praxis of doing it and working together.
Nice to read a project we worked on a long time ago (web application concept and initial set of user stories to hand off to development) is still going strong. This project and others like it support my thinking that it’s possible to solve problems definitely in a product agency context.
A relevant and nuanced complication of agile by Dorian Taylor seeing it as a trauma based response where the core practice has gotten stuck and is preventing the industry from solving more fundamental issues.
People see this kind of talk about self-governance and think there is no process or management in such a setup while usually there is more (and higher quality) than in a traditional organization. It’s also some of the best work you will ever do.
A lot of very uncomfortable questions in this list of staff engineering program dysfunctions. It seems this is quite widespread and we’re collectively figuring out how to shape this path.
Some ways to improve the quarterly prioritization tussle between engineering and business that focus on facilitating the conversation and reducing the number of things under immediate consideration.
Having seen lots of teams stuck in the two week agile rat race, a framework like Shape Up seems like it could offer a lot of benefits. But also just changing things up can’t hurt at that point. What is agility if not also being able to iterate on the way you work?
Good programmers will naturally start to abstract and develop a model that can do more work. But when this happens only in a technical setting, without collaboration with domain experts, the concepts are naive. That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert’s way of thinking.
