Timisms

“Never let someone else decide your happiness.”

— Mr. Bartlett, High School band director

Since marching band is a judged activity, the band could get really down if the scores didn't match what we felt like we should have gotten. So Mr. Bartlett would always remind us that our happiness should be based on our feelings of our own performance. Seems like a good lesson for events off the field, as well.

“Never come off the field saying I should've, would've, could've.”

— Mr. Bartlett, High School band director

You only ever have one shot at any individual moment. Make sure you give it your all.

“Always be three mistakes above the ground.”

— My father, who told me it was an old stunt pilot saying. He was an insurance agent and never flew a plane, so who knows if it's a real saying or not.

Mistakes will happen. Make sure you have enough room between where you are and disaster for those mistakes to happen.

“One crazy thing at a time.”

— Me

Humans are terrible at multitasking. There are plenty of sayings like this, such as 'Focus on the job in front of you.' Focus on the thing in front of you, get it done, then move on to the next one. Otherwise you'll get overwhelmed and balls will get dropped.

“There are no heroes in software development.”

— This was the thesis of an article I read back in 2012/2013. If I ever find the article again, I'll link it here.

In general, developers like to solve problems and want to help out, especially on a high-trust team. So when things take longer than expected (which always happens), devs have a tendency to want to put in extra hours to get things over the line. They generally think this is an exception. However, what tends to happen is that precedent has been set and management views this as the expectation rather than the exception. Trying to be the 'hero' winds up reinforcing unrealistic expectations and leads to burnout. It comes with the job that sometimes you will have to put in extra hours, but always be sure that they're actually worth it.

“I don't care how things have been done, I care about how things should be done.”

— Me

There's always a reason as to why certain processes and patterns exist. A certain process may exist in an organization due to hard-learned lessons. Other times it's just a matter of some type of process needed to exist, and so that's the one that was developed. When coming into a new organization, it's important to understand the why. 'That's the way we've always done it' isn't a complete answer, but that also doesn't mean that particular process needs to be thrown out. It's important to truly understand how things need to behave going forward, and then shore up or adjust processes accordingly.

“You don't deploy features, you deploy builds.”

— My own wording on common software development wisdom

This may or may not depend on the tech stack, but since I primarily have worked in .NET, this regularly applies. Users don't use features individually, they interact with an entire build. As developers and product teams, we tend to focus on individual features and getting them out the door. However, a single build could introduce regressions or a CI/CD hiccup could introduce some unexpected issues. Make sure you focus on the actual bits that will be delivered instead of just the abstract concept of what features are going out.

“Code as if the person maintaining your code is a homicidal psychopath who knows where you live.”

— Usually credited to John Woods, though it has been passed around under a few different names for decades

Clever code is a liability. The next person to open that file has none of the context you have right now, and more often than not that person is you in six months. Write it so it can be read, name things honestly, and leave the comments that explain why instead of what. You are not writing for the compiler, you are writing for whoever comes next.

“One Band. One Sound.”

— Drumline (2002 movie)

Another marching band favorite. Applied to a software development team, the idea is that we're all in this together, and we all have our own separate jobs to deliver the same value at the end of the day. One team, one product.

“Ask more questions, make less assumptions.”

— Me, though it's a variation on a theme

Plenty of variations on this one, and you've probably heard some before. But people generally don't have all the answers, so to actually understand a situation, you should ask more questions and make less assumptions.

“If you think you're overcommunicating, you're probably not communicating enough.”

— Probably me

This is something I say on my teams a lot. Software development is very much a team sport, and a high-performing team thrives on open and frequent communication. Too many things get lost in side conversations, DMs, emails, etc. So make sure you're bringing along the entire team for the whole ride.

“If there's one word to describe why humanity hasn't reached its full potential, that word would be: meetings.”

— I stole this from some Twitter user back in the early 2010s, but don't remember who it was

You might be thinking that this contradicts the communication Timism, but meetings =/= communication. We've all had meetings that should have been an email. Sometimes it's important to get people in a room and figure things out. But there are plenty of times when a meeting is really just the illusion of good communication. Time is a finite resource, so make sure you use it wisely.

“In systems under pressure, something always gives.”

— Me... I think

Systems could be software systems, or they could be teams or even individuals. Stress and pressure are a fact of life, but every 'system' can only handle so much. It's important for leaders to remember that if they don't open the release valve to let off some stress, eventually that stress will be released some other way.

“Trust your people, or they shouldn't be your people.”

— Me

This applies equally to managers and individual contributors. As a manager, the best teams are ones that you trust to get the job done. If there are people on your team that you don't trust, it would be better for everyone if they weren't on your team. As an individual contributor, if your manager doesn't trust you, it would be in your best interest to find one who does.

“The people doing the work are the best people to decide how to do the work.”

— Me, though it's a core Lean and Agile idea

The people in the trenches are the ones doing the actual work and delivering the actual value. As a leader, your role should be to make sure people are going in the right direction and have what they need to get there. Since you're not the one doing the work, you don't know what it really takes to deliver said value, even if you originally were in the trenches. Trust your people to know how to do their jobs, and you'll get the most value out of them.