Developers gravitate towards what they know and like, what’s comfortable and feels good. This can be problematic in a team environment. Looking back at my career, I’ve made more than a few mistakes in this regard.
Consider that framework you enjoy now: is adding that extra dependency enabling anybody?
That design pattern you like: does it help to pile that on top of legacy code?
How about that wretched component you can’t bear to read: does it help to avoid it and cake hacks on top?
With questions like this in mind, I’d like to suggest three ways to be more effective in a team. This is for web developers working in a team. I’ll draw from past experience and lessons learned along the way.
The Importance of Attitude
More from this author
Your disposition towards certain tools says how you value the team’s work. This manifests itself in the way you approach code problems.
In previous roles, I’ve caught myself doing lone coding while undermining another’s work. It’s this kind of attitude that wrecks your success within a team.
To begin this article, I’ll explore one of my favorite characters from the Star Wars universe — as I believe he has tidbits of wisdom to offer in this regard.
The Person of Kenobi
Obi-Wan is my favorite character in the Star Wars universe. As a general during the Clone Wars, he’s a member of the Jedi Council and a threat to the Sith. Obi-Wan is a paragon of the light for several reasons:
- he hates flying, yet is one of the best pilots in the Republic fleet
- he hates blasters, yet is a sharpshooter
- he hates the Sith, yet becomes Darth Vader’s best teacher.
I feel this hate vs mastery relationship is telling in our careers as web engineers. Teamwork is seldom found in what you think you are good at and feel good about. Stepping outside your comfort zone is the attitude that will challenge you and enable you to grow.
Where Ideas Come From
So, the first point I’d like to make starts with a question: Have you ever experienced a visceral reaction to a code solution? That pit in the stomach that says it sucks, but you don’t know why? The kind that says something is wrong with this, but you can’t quite put a finger on it?
In a team environment, you don’t always have the best idea. It’s important to discern whether i’s your brain talking or your ego.
Just because it wasn’t your idea, it doesn’t mean it’s inferior. One suggestion is to run a quick examination and figure out where that gut reaction comes from. It may lead to opening up new ways of solving a problem. By being open and asking the right questions, you may yet learn something new. It’s a real privilege to stand on the shoulders of giants and take solutions even further.
Granted, it may still be the case that there’s a better way. You could be dealing with someone that doesn’t have the time or doesn’t care. If that’s the case, it might be a good time to look for another team — especially if that someone is influential within the organization, such as a lead or manager. These organizations attract the wrong crowd anyway, and have issues growing and retaining talent. As this industry matures, I find that these cases are few and far between.
In an empty canvas, there are infinite ways to solve a problem. The beauty of building web solutions is that you get a real shot at this. The open web is a platform where any kind of radical idea can live — as long as you’re sending standard hypertext messages from a server. So it’s fitting to approach this within a team setting.
The tooling and decisions the team makes often add value to the team. The key is to embrace those ideas and contribute by taking them to the next level.
The Job Everyone Hates
When I first began my career in building for the web, I hardly knew what CSS was. As a result, my fist job interview as a web developer was a total failure. Looking into CSS, I hated the plucky styling rules. Up to this point, I had come from a strong programming background, so I had this bias. It seemed foreign to have global rules, no variables, and no encapsulation.
But then, at some point, I decided to take CSS seriously. It wasn’t until then that a path towards mastering CSS began. Craftsmanship begins by taking the time to study with patience and perseverance. It’s the path towards taking your skills to the next level.
In a team setting, there’s a need to step outside your comfort zone. For example, is the data layer broken? Gasp! It may be time to roll up your sleeves and figure this out. A busted database can wreak havoc on the team. If you’re comfortable with the front end, it will be a good opportunity to pick up the back end.
Or are there merge issues with the release branch? That’s right — it might be time to brush up on those source control skills and get your hands dirty. If the team doesn’t ship working software then clients will not get a bill. It may not be the most warm and cozy type of work, but it’s what the team needs.
Or how about making code reviews your top priority? Reviewing and providing feedback on code solutions is grueling. But it’s super rewarding to know how fellow engineers approach problems. Often, the job everyone hates is what adds the most value.
Can you think of a tool or skill you both hate but yet have mastered? This is the kind of hate vs mastery relationship illustrated in the Star Wars analogy. After all, Obi-Wan kills General Grievous in a single blaster shot. Then follows up with a few more right on target just to finish the job.
The Selfless Programmer
On to my final point. Ever wondered who are some of the best team mates you’ve ever worked with? Was it because of what they did for themselves, or what they did for you? Say there’s this wretched stored procedure everyone hates, and this person takes the time to move it out of the database and add proper unit tests. In spite of working with nasty code, they go above and beyond the call of duty by leaving it better than they found it. With this attitude, you can find little opportunities to grow and add value. It takes skill to produce working software, but a craftsman does what’s best for the team.
I once saw a team that struggled to work well together. It was a place where egos ran high, and the only expectation was to do the job with few questions. Each person had a certain silo. The one who mastered their comfort zone became a lead of sorts. To the team, you were just a utility with a narrow skill. Looking back, I struggled to find any footing, because I focused on what I thought I was good at and felt good about. The team fizzled because the company set unrealistic expectations and budgets got cut. It convinced me that this type of environment is detrimental for your career. In the end, everyone loses.
I’ve found that the best teams are the kinds of places where people care about each other. Each individual gets a voice and gets treated as an equal. When one person disagrees, there’s an attempt to reconcile and find common ground. In this team environment, there’s an opportunity to grow. What’s so radical is that everyone gets to be a leader. In short, a leader is someone who does something hard, in order to help others. You don’t need a fancy hat or a title to be one.
Leadership begins by doing the kind of job everyone hates and mastering it.
Leadership is when someone comes up and says “Glad you did that. I couldn’t find it in myself to do this.”
It’s embracing the ideas and decisions the team makes and pushing them further.
It’s having a real concern for others. Passionate leaders effect change to perfect their teams.
When I think of the selfless programmer, I really think of a leader. The one who puts their comfort zone second.
So there you have it — three simple ways be more effective in a web team, given the opportunity to grow within the team.
Of course, an open mind is necessary for anyone to grow — at times, finding yourself doing something you’ve never done before. Just as when I first began learning CSS, you may end up enjoying that thing you hate for now.
The best attitude says, “Boy, I have no idea how to do this thing everyone hates, but let me figure it out.” This is a perfect example of leadership — stepping up to a challenge when no one on a team knows how to achieve the goal.
What about you? Have you had similar experiences on a team? Do you have any insights to add? Have you ever stepped outside your comfort zone within a team to tackle something new?