Software development is collaborative by nature. If you’re working for a company, regardless of size, you’re obviously working with others.

If you’re working in the world of open source, then you’re working on things that may consist of the largest team of people you’ve ever worked with (and may ever work with).

Team

We’re a little less sweaty and a lot more caffeinated than this team, right?

In either situation, this doesn’t mean that the team dynamic is great, but that’s not the point of this point. For purposes of this post, I’m assuming that you are working with others and it is going well.

At least as well as one could expect, right?

Being Part of a Software Development Team

When it comes to working as part of a team, there are always dynamics at play. This doesn’t matter if it’s a one person team or something much larger.

Further, I don’t think this is particularly insightful. Study after study exists that study this exact topic, right?

I’m sure we all have our own stories. Some make for fantastic stories. Others are better suited for a Dilbert comic. I’m not so interested in the latter at the moment.

Instead, here are two things I’ve found when working in the context of a team in software development.

We Don’t Know It All

First, there’s something about being the new guy or new girl on the team. It’s as if we think that whatever we’re bringing to the team is the best stuff.

I don’t know if this is something that comes with just coming out of school or coming out of another job. For whatever reason, we opt to think our way is the best way and everyone else’s is subpar.

In short, if we join a team and their processes don’t align with ours, then they must be doing something wrong.

We couldn’t have a poor perspective on this. We’re educated in this material. We’ve had previous jobs. We’ve done well for ourselves!

But wait.

What if their way is better? Or what if it’s just as effective, it’s just different? Aren’t those possibilities, too?

Whatever the case, don’t be so quick to dismiss others processes because they aren’t how you would do it.

Programmers, by nature, are process-oriented people. Most of us, anyway. And to create a process, there has to be rationale for why each thing is in place, right?

So instead of dismissing their way of doing something, ask why it’s done that way. We’ll likely learn something and become that much more experienced.

Welcome Feedback

The more open you are to feedback in the form of code reviews, performance reviews, and so on, the better of a person you can become.

Rather than going on the defensive for why your code is wrong, or why the choices you made in doing whatever were a lapse in judgement, listen to what they are saying.

Case in point: I’ve talked about code reviews many times on this blog. I’m a big fan of them, though I didn’t like them early in my career.

At this point, I welcome them. I dig hearing what other people have to say and I love having others critique what I’ve written. It helps expose me to better development practices and APIs I didn’t know existed.

Those little things can pay off dividends in future work. Besides, no one is saying the code sucks. They are saying “This works, but here’s room for improvement.”

Why would we not welcome that? We get a couple of sentences on how to improve one line of code that we can carry with us in future projects.

Talk about a serious return on investment, right?

It’s Not a Definitive List

These are just a few quick thoughts on writing code as part of a team. If nothing else, it’s one of those things that I wish I had known when entering this field.

I’d like to think that I’d be mature enough to handle it, but who knows. Would maturity interfere with wisdom? I don’t know. Probably.

And, to be clear, I know that not all teams are great and that there are problematic areas in other teams. This assumes that you’re not working as part of one of those teams.

This, if anything, is a gut check to make sure we’re on the receiving end of criticism in the best way possible. It’s meant to help us become better developers, teammates, and reviewers of our peers.

Regardless, this is one of those things I think transcends when you get into a field. Instead, it comes with how long you’ve been in a field.

So these are a couple of stray observations that I’ve noticed and that I’ve had on my mind for the past couple of weeks. As usual, I’m interested to hear your perspective, as well.