Dear new developer,
I was out for a run the other day. People walk dogs along my running route and I had noticed a few days before a bag of dog poop. I had run on by, assuming someone was planning to grab it on the way back from their walk.
But then I saw it again on my way out for a run.
I had a couple of choices:
- I could leave it there and let it slowly break down
- I could pick it up and throw it away myself
I chose the latter. Yes, the photo above is the actual bag.
When you see something that is off at your job, a metaphorical bag of poop, you also have the choice to ignore it or fix it.
Please choose to fix it. Here’s how.
Make sure it is poop
First, you want to make sure it needs to be taken care of, and by you. In order to stop talking so much about dog poop, let’s take the example of a flaky test. Sometimes it works, sometimes it fails. It annoys folks and causes folks to trust automated tests less. Seems like something that should be fixed. Other examples include: busted CI action off the mainline, complicated untested business logic, undocumented subsystem, or old dependencies.
Ask around. Are other people as annoyed by it? Is it on someone else’s plate to fix soon? Is it a “known issue” that other people have tried to fix and just realized it can’t be done?
If you determine that it is problematic and worth fixing, then proceed to the next step.
Tell people you are going to pick it up
Here’s the thing about picking up poop. It’s not fun. When I ran home with that bag of poop, I wasn’t smiling, even though I was doing the right thing.
Similarly, make sure you get credit and acknowledgement for this. Share your ideas on how to pick it up, err I mean fix the flaky test, with the team. This may get you further feedback about how folks have tried to fix these in the past. Others might volunteer their plan to fix it.
No need to shout it from the rooftops, but post that public slack message or send that email to interested parties.
If no one else is going to fix the flaky test, however, the next step is to plan.
Plan how to pick it up
Build a plan to fix the issue. Depending on the size and scope of the issue, this may be as simple as a few paragraphs and a ballpark timeline. If it is a deep rooted issue that crosses team boundaries, there may be meetings, gantt charts and other artifacts of software planning. (As a newer developer, it’ll probably be more of the former, but you never know.)
Hard to give specific advice on planning, but please don’t forget to do it.
Share this plan with the team and especially with your manager. Incorporate any feedback. You may need to delay the execution until a certain time, to make sure you’re working in concert with the larger team goals.
But, eventually, it’ll be time.
Pick it up
Execute the plan. Of course, things will take longer than you think and as you peel back the issue of the flaky test, you may discover other issues. Try to avoid scope creep; make notes of related issues to tackle later.
Communicate how things are going. Take small steps. Celebrate your progress.
When you are done with the work, pat yourself on the back. You just did a Good Thing. But there’s one more thing you need to do.
Tell everyone you picked it up
This is the flip side of telling everyone you are going to do this unpleasant task. Now that it is done, let folks know. Reply to the slack thread or the email message.
One final note, make sure you don’t pick up poop too often.
By doing so, you helped the team and the organization, but what you really want to build is a culture of poop pickup. You want everyone motivated to do the work, not create or encourage a special ‘pooper scooper’ job. (This is similar to avoiding becoming glue as a new developer.)
Sincerely,
Dan
Letters To A New Developer 