Two Lessons I learned after a finished project

05 Feb 2024 #career

Today I want to take a moment and reflect on a finished project. Last year, I worked as an independent contractor and engaged in short projects with a client. This project was a six-month effort to support group events, like weddings, conferences, and retreats, in a property management system.

This small project taught me more about leadership and communication than programming in general. These are the two lessons I learned from this project.

Lesson 1: Have uncomfortable conversations earlier

Inside our team, we all started to notice “certain” behavior in a team member.

He delayed Pull Requests for minor things, interrupted meetings with off-topic questions, and asked for 100% detailed and distilled assignments.

Even once, he made last-minute changes, blocking other team members before a deadline. It wasn’t a massive unrequested refactoring, but it frustrated some people.

From the outside, it might have appeared he was acting to jeopardize the team’s progress.

It was time to virtually sit and talk to him. But nobody did it. And things started to get uncomfortable, eventually escalating the situation to upper management, leading to a team reorganization. There was “no chemistry with the team.”

An empathetic conversation could have clarified this situation. Maybe the “problematic” team member had good intentions, but the team misinterpreted them. Who knows?

This whole situation taught me to have uncomfortable conversations earlier.

Lesson 2: Once you touch it, you own it

At some point, we needed to extend an existing feature. We needed to import an Excel file with a list of guests into a group event.

“You only have to add your changes on top of this existing component. It’s already working.” I bet you have heard that, too. That was what our Product Owner told us.

The next thing we knew was that the already-working component had issues. The original team was laid off, and we couldn’t get our questions answered or count on them to fix those issues.

What was a simple coding task turned out to be a longer one.

Before starting to work on top of an “already-working” feature, I learned to test it and give a list of existing issues. Otherwise, those existing issues will appear as bugs in our changes. And people will start asking questions: “Why are you taking so much time on this? It’s a simple task.”

Lesson learned! Once you touch it, you own it!

Voilà! These are the lessons I learned from this project: have uncomfortable conversations and test already-working features. Also, this project made me think it’s better to hire a decent developer who can be mentored and coached than a “rock star” who can’t get along with the team.

For more career lessons, check five lessons from my first five years as a software engineer, three lessons I learned after a “failed” project and things I wished I knew before working as a software engineer.