Managing through aphorisms

They’re clichés, sure, but are for a reason. And in a sound-byte driven world, having a punchy phrase to summarize what is often full of nuance is useful. I find myself returning to these as mantras, rallying cries and whatnot repeatedly as I lead a team, pull in collaborators and stakeholders, and generally try to make better software in better ways.

Default To Open

In what is probably the most surprising 180 from my early career, I lean deeply on this idea, across several ways:

• open source your code. This has a few effects: write all your code like someone else is going to read it, that you don’t know. Make sure your code is functional. More basically, thinking in an open-source mind changes some approaches.
• Talk about your work openly. Learn in the open. Share your learning, your success, your failures. Write about it. talking about. Let anyone who wants to follow along follow along. This helps remove some barriers to being vulnerable in my experience, and can help sharpen thinking by actively, consistently reflecting on work in progress.
• Give access to your work. Open your backlog for others to see. Keep tickets available to submitters so there’s no back-channel. Talk in open channels not private messages. All of this can help drive a practice of asking questions, being respectful of others’ learning, a safe space for vulnerability, and being kind to clients/stakeholders.

Aim for Less Wrong

At all times, assume you’re wrong. Your goal is to get to be less wrong. You can only validate how wrong you are by talking/sharing with others, and being humble about that. And understand that everyone is wrong at the start, and constantly working to get to less wrong. I’ve found that by repeating this over and over, it can help lead to some changes:

• asking more questions
• being kinder in response to “dumb” questions
• putting something into existence to work on/against, vs being paralyzed by choice to start. It’s easier to talk about something in particular vs a general idea “let’s do X” rather than “we should do something” gives an opportunity to change X.
• It removes the stigma and potential shame about being wrong – you’re already wrong. Know this, accept this, and aim to be less wrong.

Writing software is a team sport

This is sort of the corollary of go alone to go fast, go together to go further. You need others to be successful, because everyone is full of biases, and other people help you get around them. And people with different skills are required for a good team. I’ve found this is a helpful gentle nudge away from individuals who constantly want to be a hero and take everything on by themselves too.

Write less software

Perhaps ironic for a software team, but the best software is the software you don’t write. Much like how a car loses half its value as you drive it off the lot, All production software is legacy someone needs to deal with in the future. So write less of it. If you can use someone else’s software? if your default position is “I don’t need to write this”, it can really give focus to the decision that, indeed, you do need to write it. Can you justify why you haven’t just used someone else’s software? it is worth the effort, the cost of maintenance?

Write boring software

This goes along with the above. We all want to write super-brilliant, complex software that’s on the cutting edge of everything because we’re that awesome. But guess what. Chances are that you’re only going to be responsible for 10% of that software’s life. OTHER people – OTHER systems will have to be able to work with in in the future. So if you follow common patterns, you lower the cognitive overhead to learn it. and maintain it. Resumé-driven Development should be avoided in almost all instances, because software needs to live in teams, not individual’s heads. It also means to, more often than not, move cautiously. Don’t adopt that rad new framework just because it is there. The larger the organization, the more important this is. Human ability to share immense code-bases because of predictable patterns is major advantage.

Progress is more important than excellence

Everyone wants to be the best. Strive for that. But perfectionism is the enemy of good (is that another aphorism to live by?). What’s important is consistent progress towards better on all plans. experiment, iterate, improve. Fail one time? that’s fine. learn and do it better next time. If you’re the best, if everything is excellent, you’re in the wrong job – because you’re not being challenged. Similarly, if you can no longer progress, you’re in the wrong job – because you either don’t care or you’re in the wrong role for your skills.

There’s of course and endless list of these. These few keep cropping in conversations over the past year or so. Other things I’m trying to find good wording for is around the concept of how good software is living, or like a plant, or something – that you have to maintain it, update it, let it adapt to the world around it, etc.