On joining a new team and coding as a group

In the Game of Code

As an iOS lead, I had plenty of responsibilities: writing stories, helping design with iOS guidelines, mentoring other devs. However, I always tried to be very aware of code reviews that were submitted by the more junior members. When you start your first job, code reviews may leave the junior members bruised. Understanding that you are not your code is a very rough lesson, so I try to smooth any rough edges.

During one such code review with a junior dev, we came upon a piece of code that he wrote. Something like this:

if readyToDisplay, status == .done { // Do something }

A more senior reviewer mentioned that the junior should not use a comma and should instead use a good, old && when checking two booleans.

The junior dev was upset because this wasn’t the first time. Over the course of several code reviews, the senior reviewer had constantly brought up tiny details like the aforementioned. “Don’t have new lines in between switches, don’t use guard like that, before returning move this code over here”.

This comment was the one that broke the camel’s back. It seemed like a petty thing to notice, especially because the coding style guide didn’t mention it. They wanted to respond to the feedback, in a cordial way, but to let the reviewer know that they disagreed.

I advised against it.

You don’t need to win or die

When you join a team you’ll promptly come to realize:

  • The code can be better (ok, the code is an “ugly mess”)
  • You don’t have the chips to change it

Think of the trust that the company has in you as a number of chips. When you join the company, it doesn’t really matter how good a developer you are, you have very few chips. Chips are the currency that you use to change the company.

Yes, the company, not the codebase, but the company.

Submitting code without bugs, helping other team members, being active in Slack… every action you do either nets you chips or costs you chips. The better the team thinks you are at your job, the more chips you’ll earn. Notice I did not say “the better you are at your job”. What I said was “the better the team thinks you are at your job”.

Chips are trust, so it doesn’t matter if you’re the best developer on planet Earth. If the team doesn’t consider you a team player, you will not be earning chips.

Would a comment lose me that many chips?

if readyToDisplay, status == .done { // Do something }

I advised against responding to the original comment because the requested change is inconsequential. The junior dev would be going against another team member, which would cost him chips. The cost may be very few chips but why would you even spend them on this comment?

I explained all of this to the junior and then told him to just change it to a double ampersand. Then I asked him what was something that he really, really wanted to change. We got to talking and eventually settled on some other part of the code that he really wanted to change. Then I said, “save your chips and I’ll help you spend them when the time comes.”

In the end, the lesson that I wanted to teach is that coding is an extremely human endeavor. Coding is creative and fulfilling and engaging; in all creative endeavors it’s usually much more important to worry about your impact than to worry about the form.


If you liked this article, please consider subscribing! I write a weekly newsletter with a 15-minute coding exercise, and additional sections like interviews from members of our community.