You want me to approve what?!

You are improving as a Software Engineer. If that is true, then you're at your pinnacle of knowledge right at this moment. Everything you've done in your career and life have led up to this exact second. All that experience, all the mistakes you have learned from, all the successful applications you stood up! And they're still in production to this day, gosh darn it!

So why in the world would anyone want to do a thing like go into your code base and submit a Pull Request for a new feature in a completely different way than you would have ever done? No newline characters at the end of source code files, its filled with pineapples, using tabs instead of spaces?!

I mean, it's obviously wrong. Right?

Those poor bears

The story of Goldilocks and the three bears.
If you are not familiar, I suppose it is a rather entertaining read. A young, innocent, blond-haired lass strolls into the empty cottage belonging to a family of three bears. Said bears are out on a stroll of their own; You see, they have made porridge for themselves, and want to give it time to cool off.
Well Goldilocks, rather selfishly, takes it upon herself to contaminate food she dislikes, devour that which she does like, ruin furniture, and pass TF out in one of the beds of these three, wonderful bears.
They return home to the mess, discover the unintending thief, and frighten her into fleeing for her life.

The moral of this children's tale is the need to respect the privacy and property of others and how your actions hurt others.

That's exactly what's happening to me!

You, the diligent, experienced programmer have been asked to "take a stroll in the woods". That is, your skills have been requested on another project in the company.
The code you have written is a lean, mean, revenue generating machine; But like most code, it will need maintenance, perhaps even additional features. And who better to do that than another developer with practically no experience in the domain space or practice in the design patterns you have so elegantly employed in said project.

The dreaded, yet well-meaning, Goldilocks has been granted authorship to your code.

And now, there is a pull request. Of course you have alerting set up for such a thing. So you see it immediately. Unlike the three bears, you are not going to simply walk away from your shelter without a home security system only to allow silly children to ruin what you have worked tirelessly to build.

But perhaps you also don't want to be seen as an angry, ferocious bear either… After all, this is an adorable, innocent child. You are upset, but can't destroy the pull request author, but you also need to show them who's boss over this code!

So you start with small comments about what's wrong. Perhaps this turns into a heated debate over PR comments and you start duking it out. Or perhaps the other party "didn't know better!" and immediately crumples to your demands, changing every bit of code you despise for "not being best practice". Maybe even merging that branch you created off of their branch that "corrects" the terrible practice and nonsense they almost introduced into your code.

If the developer puts up a fight though, the code may never get merged because it needs your blessing and approval. And now that person is dealing with questions from their leader of "why is this work taking so long?". Now the finger is pointed at you!

But you were only protecting your house! Look at the mess Goldilocks almost made!

You decide your talents are best appreciated elsewhere, and say goodbye. After all, you're a senior engineer. Recruiters be slidin' into your LinkedIn DMs constantly!

✌️

Goldilocks Syndrome

If you have been blindly agreeing with everything I've said so far, you had better not be a senior engineer at your company.
And this is for you:

🚩

This is setting the stage for a pretty toxic work environment; That of the ferocious over-bearing developer controlling every move being made on his/her codebase.

This is Goldilocks Syndrome. And it occurs in very specific scenarios in an engineer's career. Avoiding this syndrome though, is a hallmark of a great engineer, and should eventually become an expected trait of any engineer; Especially a senior engineer.
To be presented with this predicament in the first place is an indicator that you are probably, objectively a good developer. Now at this stage, you can prove that you are also a good teammate.

What you do next in this situation, will either be remembered as a beautiful milestone in your career, or an awful trauma for the other party combined with a stab to your own personal brand.

When the opportunity arises that an "external" is requesting her own changes be merged into your codebase, what should you really do?

Going from "the bear", to "the balanced mentor"

OK, the metaphor does not work perfectly here. Goldilocks was genuinely in the wrong in that story, and needed to learn a lesson. In her case, I can only imagine it was traumatic, but she messed up their house and ate their dinner!

However, the lesson you have the opportunity to facilitate here, does not need to be so painful.

Also, don't assume you got it perfect in the first place! We all have room to improve and teach others along the way.

In this case, it's more likely you will end up teaching someone that's dealing with "imposter syndrome", not someone who is actively seeking to dramatically deviate from the codebase standards.

Real-life example

Scenario: New PR submitted to your code base by a developer that has taken ownership of it, as you have moved on to another project. Not much needs to change, just the occasional new feature, new button, new endpoint, you name it. The new dev simply needs to maintain it! You did a great job (hopefully), but you're needed elsewhere.
The dev needs to make a change, and wants your input knowing you as the domain expert, or at least needs your approval in order to merge the code.

We have already outlined a poor response to this situation.
Yet, another terrible response to this is to simply approve the request!
You might be tempted to do such a thing though, and with all the best intention, if you don't want to hold up their work. And you also have your own work to do, so you can't spend forever on this one measly pull request.
How can you give this developer just enough to set them on the right path?

The Goal: The new feature makes it in with as little, to no new tech debt as possible.

Much easier said than done, so let me leave you with a few tips that I have learned, that can help set up you and the other team for success.

Tips for finding that balance

• 🟢 Be curious, not accusatory

Asking "why would you do it this way when we do it this way over in this other function?" is aggressive. It will never have the outcome you want. It will lead to the other person feeling the need to be defensive, or worse, will crush their spirit into doing it exactly the way you tell them.

This developer will not grow in that environment. And believe it or not, you actually should want them to. If they do grow, and even better, if you get to see that growth occur, you develop trust with them. Maybe even getting them to a point, that they shouldn't even need your input anymore! They can be trusted by all to simply - own the code.

Exchange "why" with "what"

Instead, you could say, "This is an interesting approach. What made you do it this way?". This is far less abrasive to the other party. You are engaging in a dialogue now, not an accusation. Internally, you know you would not have coded it that way. And your questions demonstrate your open-mindedness to the new technique instead of shutting it down. You are curious, and interested in learning about their approach.

More often than not, what I find these types of questions tend to do is bring up more conversation around the heart of what is trying to be accomplished.

Which brings us to the next tip.

• 🟢 Ask what they are trying to do

This one might seem obvious, but it is far from human instinct in my experience. What is trying to be done may also be really well-defined if the changes are rather straightforward, or the developer is really good at documenting. Still, attempt to simply reiterate what is trying to be done in your own words to the developer, and allow her to respond. What you're looking for here is: "That's right".

This grows the mutual "pool of understanding". One of the worst things you could do is delve deeply into a rabbit hole of conversation about a specific line of code, but you have yet to be on the same page as to what the overall goal that the whole pull request hopes to accomplish.

If you do not get the "That's right" response. This next tip will help.

• 🟢 Listen

Stop waiting for other people to be finished talking, so that you can say what you want. I am super guilty of this, and I still need to stop.

Really listen to the other person. She will probably explain what she is trying to do; Or what she was hoping to accomplish through some specific piece of code that was written.

Only after you listen well, and not simply have "the answer" ready in your cannon, can you start to balance what you allow in to the codebase, and what you wish to keep out at all costs.

• 🟢 Choose your battles wisely (Look for the reddest of red flags 🚩)

A quote by C. JoyBell C. (according to the internet). But it couldn't be more important advice.

Especially after you have cultivated a decent level of trust with the other developer, you can and should enter into healthy conflict over something in the pull request where you deem it necessary.

Look for those spots of code that really violate best practices, or violate the standards of the specific language in which the project is coded. And believe me, if you're as good as you should be for having been an owner of this codebase in the first place, you will know it when you see it.

Then, kindly explain something you are seeing, and again, ask what made them code it this way. After listening, if you still think it's a bad call, suggest the alternative.

• Examples:
  • 8 nested for-loops
  • Side Effects in functions
  • one letter variables
  • stuff that is intrusively and selfishly inconsistent with how the codebase is already doing it: introducing spaces when tabs are what are used for whitespace. When in Rome, code as the Romans (This one is the equivalent of "wiping your feet" before entering a stranger's home who has invited you in)
  • deserializing JSON in a unit test to set up an object instead of calling new to construct the thing 😊

 

• 🟢 Choose to let in the code that will "work" but isn't perfect (by your definition)

This is a tough one. It is the last, and most important tip.

When you say, "Yes" to a piece of code, that (A) you don't agree with but (B) you know will work, you have made a big step towards becoming a better human being, let alone a better engineer.

This, less-severe, piece of tech debt, that may even fall off of your secret, internal list of things you have to fix someday, and that's OK, is setting up for a great win in the future.

1. The code works, and you didn't need to correct anything. Congrats! You just shipped code and improved your product which is great for your users! And it all happened that much faster because we didn't need to spend time talking about this one thing.

2. By doing this, you allow the learning to take place down the road for that developer. Let them realize it was a mistake, if it was a mistake. Then, they only get valuable experience in refactoring practices and you don't get all the credit for finding it sooner, only making your fat head even bigger than it already is 😉.

   A good teacher is like a candle – it consumes itself to light the way for others

3. At last, the most interesting side effect to this act, a piece of what was shipped, may actually have been a really great freaking idea! A new design pattern maybe. One that you never even would have thought of… Woah!
   Correct me if I'm wrong, but I'm pretty sure companies enjoy bragging about all the "innovation" they be doing. Congrats. You now just allowed it to happen.

Finally, its over

I hope this was helpful to someone. This list may not be perfect, or complete, but these practices continue to help me in my career, and even other areas of my life!

I don't do any of this perfectly yet, maybe I never will. But day by day, these traits have started to come more naturally to me, and frankly, they feel much better to operate in. It's surprising almost the amount of anxiety and frustration these tips have the power to alleviate.

A growth mindset and flexible thinking is about trying and learning from feedback. Know your values and don't compromise them. At the same time, be accommodating to different ways that meet those values and get it done.

If you end up working with me someday, and find I am treating you like Goldilocks, please call animal control.

I would rather care about my teammates, more than "my" codebases (Which are, in most cases, not even my codebases to begin with. The company you work for owns everything you produce while on-the-clock. 😆).

If you made it this far, thanks for reading all this.

Here's a cheers to becoming better 🍻