Cognitive neuroscience likes to assign functions to parts of the brain. This bit does planning. This part does short term memory. This piece perceives faces. Does that bit really do planning? If you cut it out and held it, would it plan for you? No. And that other bit doesn’t perceive faces without messages from … Read moreThe service you build doesn’t do a thing. It participates in a thing.
This was the closing keynote at the Last Conference, CodeBEAM in SF, March 7-8 2020. Avdi and I did it together (our first joint talk), and the audience laughed and also found insights. Abstract:The journey of a software developer is a climb through abstraction: algorithms, patterns, architecture….How do we keep expanding scope, without losing focus … Read moreKeynote: Designing Change
Lately I’ve been working in Node, and that means I have access to all the open-source modules on npm. It is easy to add a dependency on any of them. But is it a good idea? Not every library is production-grade. Not every library (or service) is something that I want my production code to depend … Read moreWhat makes a dependency dependable?
How do we get from here to where we want to be? Hint: don’t draw a roadmap. The road we’ll travel in six months doesn’t exist yet. Landing zones Landing zone: “an improvement that would feel like an accomplishment, as well as a pause point to catch breath, reassess, and plan how to achieve the … Read moreLanding Zones, Long-term Desires, and Impossible Dreams
When you have a common piece of functionality to share between two apps, do you make a library for them to share, or break out a service? The biggest difference between publishing a library or operating a service is: who controls the pace of change. If you publish a library for people to use, you … Read moreLibrary vs service: who controls change?
Some people work in a system, and some people work on a system. Like, you can be the person who washes the dishes, or the person who installs and maintains the dishwasher. You can be the person who assembles the reports every week, or the person who automates that report assembly. (Jacob Stoebel told this … Read moreDevelopers are system changers
To scale up the system you’re changing, scale down the changes. The bigger and more complex the system you’re working on, the more people involved, the more affect a change can have — the smaller each change needs to be. When change is expensive, when it’s scary, don’t make fewer changes. Work to make changes … Read moreTo scale it up, smooth it out
There are two huge sources of inertia in software: data, and interfaces. When two systems connect to the same database, you combine both. Ow. When some other system is doing reporting on my database, I can’t change my table structure. That severely limits any internal reorganizations I might do. Especially when I don’t know how … Read moreWhen the db is the interface
What makes software hard to change? As a developer, it’s easy to focus on the internal properties of the software system. The code needs refactored, the framework is old, we need more tests, or else fewer tests. If your software is in production, these are not the biggest obstacle to change. The important changes are … Read moreInertia in the interface