- A MasterClass by David Mamet on screenwriting. Get to the point, characters have a mission, they do it, and they're done. Code is like that. A function does s

- A MasterClass by David Mamet on screenwriting. Get to the point, characters have a mission, they do it, and they're done. Code is like that. A function does something and it's done. A module does something and it's done. - Reading a new codebase's tests: it gets you familiar with it really fast. Often, it's even better than the documentation because test functions have these long, descriptive names about what they're testing, and show you strange ways to use the code that often are not even mentioned in the docs. Tests also point to where the party's at. People tend to test the important parts. - For libraries, I write the library's documentation before writing the code, then write stubs that return the same values for the parameters in the docs, then give it to non developers and ask them to follow the documentation. I don't help them. I just give them an environment ready to use, the documentation, and I shut up and observe their every move. Every eye twitch, every facial expression, every keystroke. I don't correct their "mistakes", I simply take notes of their "mistakes" and put them on "bad developer experience", i.e: my bad. I won't risk polluting raw, pure, data with hints or help because it's not a realistic situation: I won't be with whoever will use it in real life. Doing this shines a bright light on all the things I thought were "obvious" or "normal", all the bad design decisions. If they could follow the documentation and run the code, I know that developers can. I show it to developers and ask them and see how quickly they're going through it: if someone just takes a glance at the docs and starts writing code without looking again at the docs except for values/parameters, I have impedance matching and the interface/API "makes sense", and they're not being slowed down by weird implementation details that make them go back to the documentation. It made sense enough that they've got it loaded in their head with a glance and they're off using it to do whatever else they set out to do. It won't become something they think about. This is also valid for applications and UX. I put them facing the application, keep my lips clasped, and observe. Down the line, I think about the millions of hours, and millions of dollars on "Customer Success" or "Customer Support" that will be saved. I think about all we can deliver per person if we're not busy helping people figure out things they shouldn't have needed help for in the first place. - Commenting intent and rationale behind the implementation to make the XY problem obvious: someone reading might detect that my logic is flawed, or an assumption that is, or has become, false. References to other related issues and information about why it was written that way. - Logging. Logging. Beautiful loggers. - Error tracking and performance monitoring. Sort by severity and frequency, then solving that. - Abstracting but stopping at N=3 or 4. For example, say you're on AWS and writing code that dynamically creates Kubernetes clusters on EKS... You can start with N=1, very concrete, writing code for a Kubernetes cluster on EKS, but your code would look eerily similar to create_eks_cluster. Maybe not you, but there will be a bias towards that, and that bias will carry on and will not only be hard to change, but will also dictacte future code because of inertia. In for a variable, in for a module. However, if you say, let's support doing that on the three or four major cloud providers, you'll find that even if you don't end up supporting them, your variable names, your functions, your classes, your modules, will not be tied to one cloud provider, and your code will be better. I say a spectrum, because the pitfall is that some people will want to go higher on the abstraction, and they end up spending way too much time trying to write the most generic code that ends up making coffee. Hence limiting to 3 or 4: even if you don't end up supporting them, the code will be better. - Documentation. I'm shot in the head. "Future me" thanks "past me" often enough to know that, for another person, documentation will be even more useful than it was for me. - Tests. Writing them, reading them as stated above. And much more,