I’m the project lead on a hard project. It’s legacy code. Also, much of the important code – things like payments processing and subscription renewals – is not well tested. It’s the type of project where you worry that doing an upgrade might break the customer’s abilities to receive payments. (If you were wondering how bad that is, it’s VERY BAD).

I’m also a perfectionist. What do you get if you combine a hard, legacy project with a perfectionist temperament? The inability to work on it at all, for fear of failure.

That’s why I’m stoked to share what I’ve learned at Radial about how to work on hard projects.

Radial takes a team-based approach to all project work. Prior to understanding this, my tendency would have been to take on all the hard work on the project myself. Then, my perfectionism would take over and I’d work on that one task forever. I’d want my work to be “perfect”.

‘Realistic Good’ Can Be Good Enough

Working with my teammates has helped me realize my work can be something else. I call it “realistic good.” What does that mean? It means there are time constraints and budget constraints. And sanity constraints, if I’m honest.

When I was working alone, I imagined my senior-level colleagues writing better, more perfect code than me. My anxiety kicked in, and I felt like the project could never be successful. It was at that low point that my team stepped up. They pushed me to pull them in to do the work. They told me I was not alone. They even told me to take a break from the project and let them get it done.

At first, I was skeptical. The project was my “baby”, and I understood it best. But then, when I started pair programming with them, I observed my colleagues focusing on the task at hand, putting aside terrible code that doesn’t need to be fixed right now, and testing the feature that needed to be tested. Nothing more.

A Team Approach Supports Focus

“Realistic good” means I don’t have to fix all the problems when I am working on upgrading payment processing. I just have to upgrade payment processing so that it works the same way it always did, and is well tested. Maybe I’ll clean up a test or method name along the way. But also maybe not, if there’s not enough time. And I’ll do all this with a pair, to help me stay focused.

I might even assign the work to another set of developers, to give myself a mental break. That’s because we are a team and I’m learning that I don’t have to do the work myself to do it well.

“Realistic good” means I don’t expect to finish a feature in an afternoon, or a day. This is a legacy project and work on it is slow. But with a pair and support of a team, we’ll get it done.

best practices workplace happiness performance Radial