Rules for Software Developers on a Healthy Team (Part 2: Flexibility Required)

Culture is everything. You want to be part of a team that goes fast...produces outstanding products...and makes an impact? Build and bring the right culture.

This is part 2 of the series.

The set of rules presented here is focused on the required flexibility of individual developers for team performance.

See Part 1: Respect Others for an overview of this series, and the first set of rules. Part 3 focuses on the attitudes required for the developers.

To be clear, I'm not suggesting that you shouldn't have opinions, even stiff opinions on these matters. In Part 1, I mentioned that creative tension and passionate developers are some of the main ingredients in getting to the best possible product. If you have strong opinions in the areas below, by all means make your case with your team.

But at the end of the day, if decisions don't go in your favor...don't be a baby.

This list is unordered.

Don't Be Married to Your Favorite Development Methodology

Successful product development is about understanding the product to be developed, customer requirements, and understanding the team that will develop it. Success can likely be arrived at through one of a myriad of methodologies. 

Certainly some methodologies are more suited to certain types of products or teams. Methodology is definitely worth arguing about at the beginning of a project.

There are many great academic methodologies that have been developed over the years. But I have yet to find an instance where the "pure" form of any particular methodology made sense in the real world, with real people, developing on a real team, with real customers and products.  

The point is, not all projects and teams are created equal, and therefore, you must fit your methodology to the problems being solved. 

Don't Be Married to Your Favorite Language

I suspect this one isn't much of an issue on today's development teams. One of the qualities of the modern software developer that I admire most is adaptability to different languages for different problem sets.

When looking to hire for a team, I am rarely looking for expert in a particular language (but isn't that the first question out of a recruiters mouth?). I'm looking for someone who can solve the kinds of the problems we are solving.

If one of our projects is using Python, its because we felt we could solve the problem best in Python. Another may be using Java, and yet another may be using C. The point is, flexibility is required.

Learn several, and better yet, figure out the best problems to solve with each. I especially recommend the brainf*ck language...nobody NEEDS to know that one, but it sure is fun to figure out ;)

Developing a good product is about knowing how to solve the problem...the rest is syntax.

Don't Be Married to Your Favorite Coding Standard

Ah...coding standards, the very essence of software religious debates.

Where do you stand on tabs vs spaces? Are you a white-spacer? Do you comment liberally or should code be self-evident? What about Camel Case? Underscores or dashes?

Developers all throughout industry and the open source communities have secret alliances on these issues. There are little style tests that the prophets leak out like secret handshakes and code words. Will you pass? Will you be deemed worthy to contribute?

Here is a great article on this issue with which I 100% agree. If you don't want to read it, here's a summary: Holy shit, it just doesn't matter.

What does matter is that if you have a coding standard, just follow it.

Honestly, I've wasted more time in groups arguing over the picture at the top of this article. Smart, talented, and productive people with red faces and spittle showering the conference room table. Over what? Nothing...

I do like a certain editor and certain settings in that editor. I think that certain styles are inherently more readable than others. I do actually have an opinion on tabs vs spaces...but I've learned that what matters is not what I want, but what we collectively produce.

Having a coding standard is not about you. It's about producing source code that is cohesive, consistent, readable, and understandable. And THAT is something that makes a team more productive.

Don't be a baby.

Sometimes You Got It Wrong...Just Fix It

If it's not right, be professional enough to just rewrite it and move on with your life. It's really OK.

It's not helpful at all to go to your grave insisting that your architecture/design/interface is the right one, and everyone else should be able to see that.

Some developers are very good at writing code the first time that is awfully close to production ready. Some others have to flesh out ideas, prototype, and ultimately iterate more on the finished product.

Either can arrive at the right answer...or the wrong answer...Sometimes you just have to throw it out and start again.

You may not have had all of the requirements, or maybe the requirements changed, or maybe...yes, maybe...your solution isn't actually that good for the problem being solved.

The bottom line is that sometimes you just have to start again. It's not a reflection on your abilities, or your design, or your worth, or your colleagues. And its likely not a reflection on the "dumbasses that didn't know what they wanted to begin with."

Sometimes it just is.

(Remember, your colleagues will get it wrong sometimes also...afford them the same.)

Summary

Healthy teamwork doesn't guarantee a successful product, but it does get you closer and it makes the creative process more enjoyable for everyone. Having a healthy team requires some behavioral rules of engagement.

This is the second part of a series on rules for software developers on a healthy team. Part 1 focused the need to respect others.

This article focuses on the various ways that flexibility on your part will be necessary :

• Don't be married to your favorite development methodology
• Don't be married to your favorite language
• Don't be married to your favorite coding standard
• Sometimes you got it wrong...just fix it