Jr. Developers #5: How to Improve Code Without Anyone Hating You
Hello Jr. Devs 🙌,
For this post I want to tell you a bit about your future.
Very soon, there is going to come a day where you find that you’re working in a codebase that makes your skin crawl. Functions are too long, terrible tests… every variable name is an acronym. Whatever the problem is, when working in a team, there are right and wrong ways to go about making the situation better.
If you improve code the right way, you’ll be able to have great relationships with your teammates, while also making your codebase better at the same time.
If you do it the wrong way. Well, change is hard. And it’s very easy to step on toes and hurt your teammates feelings if you’re not careful.
In this post we’ll cover:
- The wrong way to improve code 👎
- Power of empathy
- A simple way to make your communication more effective
- The value of building relationships
- How to get your work done + make improvements at the same time 🌟
Improve Code and Make Everyone Hate You
Or, the story of my friend Milo…
First, let’s start with how not to improve code. As you read along, try to keep track of all the things Milo does wrong when trying to improve Pear, Inc’s code. We’ll review at the end and I’ll share with you what Milo should have done. 😀
Milo was the newest Jr. Developer at 🍐 Pear, Inc. The hottest new social networking startup.
Two weeks into Milo’s new job at Pear, he started to become worried. The code was nothing like he expected. It was terrible, hard to read and missing tests.
Instead of working on his assigned tasks, Milo spent his days rewriting the Pear code the Right Way™. Milo was so busy with his rewriting that he skipped all the team lunches and didn’t make it to a single company happy hour. “I don’t have time to go to those” he’d say. “I have real work to do.”
Milo knew that he had to recruit other Pear developers to help him in improving the code. So he signed up to present at the Pear Engineering lunch and learn. He compiled all his findings into a fancy PowerPoint presentation.
Milo got up in front of his engineering teammates and whipped through over a hundred slides with code examples of everything that they had been doing wrong and how they could fix it.
“Wait, who is this guy?” a senior developer in the back whispered. “Oh, this is Milo, new Jr. dev. You know that one who sits in the corner, never comes to lunch?” another senior developer replied.
The result of the presentation is about what you’d expect. Some of the developers were offended by Milo’s claims. And the others were busy chatting or playing with their phones.
In the following weeks Milo became more and more frustrated. Even after his presentation none of the other developers adopted any of his techniques. He couldn’t understand why they weren’t open to change.
So, what did Milo do wrong?
What you just read is pretty common. If you’ve been a developer for even a short while, you’ve probably seen Milo’s story play out before your own eyes. Everything Milo wanted to do was good and his intentions were in the right place, he just went about it in the wrong way.
- 🚫 He spent more time rewriting code than building new features
- 🚫 Overwhelmed his team with a hundred slide presentation
- 🚫 Didn’t make an effort to build relationships with his new teammates
- 🚫 Worked alone in a silo, didn’t include anyone else
Let’s Learn How Not to be a Milo
How to improve code without anyone hating you…
To avoid Milo’s mistakes, we need to pay a little more attention to the social aspects of introducing change to a codebase.
It takes a little extra effort, but will make you a much more effective developer and a better teammate.
1. Before you act, consider how others will feel. This may seem obvious to many, but I have to mention it. The mistake a lot of developers make is they focus only on the technical merits of the change and completely ignore the social implications. If you give it a little thought, it’s obvious why rewriting your co-workers code might make them upset. But for some reason, we often forget it within our development teams.
Before you do, say or communicate something. Spend a few moments considering how other people will feel. Then adjust your approach accordingly.
Putting in this tiny bit of extra effort will dramatically improve your effectiveness as communicator, developer and teammate.
2. You have to build relationships with your team. If you’ve recently joined a new team. Give it some time before pushing for anything new. I know that as the new developer, there is a strong temptation to “look smart” and impress everyone. But the chances are pretty high that you are missing a lot of context.
Give yourself some time to learn about the existing codebase and build relationships with your new teammates. Go to those team lunches. Go on those coffee breaks. Building relationships with your teammates is part of your job and the stronger your relationships are, the faster & more productive you’ll be. Resist the urge to show off and impress others. Spend more time listening and learning.
3. When communicating problems, please be POSITIVE! Nothing brings the mood of a room down faster than a grumpy developer complaining about everyone else's work. With a slight adjustment in your communication style you can become a much more effective communicator.
How many times have you heard a developer say something like the following?
“Our test coverage is such a disaster! I don’t know how we’ll ever get ourselves out of this mess. We must start fixing this immediately or the whole site will go down and the world might just end. I’m adding a tool that measures the code coverage of every pull request!”
The problem with stating a problem this way is that it immediately puts people on the defensive before you’ve even described the solution.
Developers pour their heart & soul into their work. If you want them onboard with your idea, insulting their work right from the start will get you no where.
Try this out instead.
Hey team, our code coverage is currently at 45%. It’s a pretty good start and saves us from a lot of bugs. We should work on improving it even further. I found a tool that shows us our code coverage in every pull request, should we try it out?
4. Improve code with every pull request. You can’t be spending all your time rewriting existing code. You have to get your real work done as well. Also, you’re highly likely to bruise some egos if you’re rewriting your teammates already working code without adding any new functionality. An easy way of making steady progress on your codebase is by making small improvements along with your normal work. Set an example for your teammates while also pulling your weight on the team.
Code lacks testing? Make sure every feature you build going forward is well tested.
Methods tend to be too long? Each time you have to modify one, break it down into smaller methods. 🌟
It will take you a little extra time, but is well worth the effort. The small improvements add up and your teammates will be much more likely to join in helping your efforts.
Now, Let’s Review
It’s all about the people
It’s easy to forget that building software is a team sport. We occasionally get caught up in the 1’s and 0’s of it all. To be successful in your career, you must also consider the emotional impact of your actions. It’s not “only about the code” or the “technical merits” of a change.
Remember:
- Consider how others will feel. Empathy is your super power
- Make an effort to build relationships
- Discuss changes in a positive light
- Make small improvements in every pull request
Now, go forth and improve some code! 🌟
You: If you have any strategies for improving a codebase, I’d love to hear it. Leave a response on this post & I’ll share out the best ones in my next newsletter. ♥️
This article is part of the Jr. Developers series. To start from the beginning, go here: Jr. Developers #0: Hello WorldIf you found this helpful, you can 💥join my email list here💥. I send out an email each time I publish something newPlease hit recommend to share with your friends 😃.
