Guiding principles

This one’s pretty simple: If I do something one way in one place, I try to do it the same way everywhere else. I pick a style and stick with it. Now, there are definitely exceptions (you’ll see some as we go), but consistency is usually a good default.

I think code should feel like it belongs in the project and community where it lives. When I join a new team or contribute to an open source project, I spend time learning the “house rules” and try to match the existing style. If something feels off about those rules, I might suggest changes, but I’m also okay with the team deciding to stick with their current approach. And when the rules are unclear? That’s a great opportunity to lead by example.

I’m always thinking about who’s going to read my code later. Sometimes that’s future me (who might have forgotten all the context), but it could also be a teammate, a new contributor, or someone who’s still learning the language or domain.

When I’m faced with a “clever” solution versus a straightforward one, I usually go with straightforward. The clever approach might be shorter or feel more elegant, but if I can’t clearly explain why it’s worth the extra mental overhead, I stick with the obvious approach.

Maybe it’s just me, but I think the quality of comments and documentation says a lot about the overall attention to detail in a codebase. Well-written language is kind of like good UI design — it makes everything feel more polished and trustworthy.

Whether it’s a function, a struct, a module, or an entire crate, I’m always looking for ways to make things smaller. I’d rather have a bunch of small, focused pieces than a few large, complex ones. Smaller things are just easier to understand, test, and change.

This goes hand-in-hand with keeping things small: I try to avoid mixing different purposes in the same function, struct, module, whatever. If I catch myself describing something with the word “and” (like “this function parses the input and also validates it and formats the output”), that’s usually a sign I should split it up.