Translator: Ten years on the trail
The original link
Developers tend to stick to what they know and like, and do what makes them comfortable and feel good. This can be a problem in a team environment. Looking back on my career, I made some mistakes in that regard.
Now think about your preferred framework: will it be enough to add it to your project?
Think about your favorite design patterns: Does it help to stack them on legacy code?
How about the component that’s too bad to read? Does it help to avoid it or layer it on top of it?
With that in mind, I’d like to give you three tips for working more effectively as a team. This is advice for Web developers working in a team. I will draw on past experience and lessons learned in the process.
Attitude matters
Your preference for a tool shows that you value the work of your team. What’s really on your mind will come out when you’re dealing with code problems.
In previous roles, I’ve allowed myself to write code alone for long periods of time without working with someone else. This attitude prevents you from succeeding as a team.
I’m going to start by exploring one of my favorite characters from the Star Wars universe — because I believe he can offer us a bit of wisdom in this regard.
Kenobi
Obi-wan is my favorite character in the Star Wars universe. A general during the Clone Wars, he was a member of the Jedi Order and was considered a threat by the Sith. Obi-wan is a paragon of light for several reasons:
- He hated flying, but that didn’t stop him from being one of the best pilots in the Republic fleet.
- He hated blasting, but that didn’t stop him from being a crack shot.
- He hated the Sith, but he still became Darth Vader’s best teacher.
I think this relationship between hate and control is also evident in our careers as Web engineers. Teamwork is hard to find when you think you’re good at it and feel good about yourself. Getting out of your comfort zone is how you embrace challenges and grow.
Where do ideas come from
So, the first thing I want to start with is a question: have you ever experienced a gut reaction to code solutions? Your first instinct is that the code sucks, but you can’t tell why? That feeling that there’s something wrong but you can’t put your finger on what it is?
In a team environment, your ideas are not always the best. It’s important to recognize whether your gut reaction is based on your brain’s judgment or your ego.
Just because someone else thinks it doesn’t mean it’s bad. One suggestion is to do a quick review and figure out where your gut reaction is coming from. This may open up new ways of solving the problem. You can also learn something new by being open and asking the right questions. This is really standing on the shoulders of giants and solving the problem more thoroughly.
Of course, this is the case where the team is still alive. Chances are you’re dealing with someone who either doesn’t have the time or doesn’t want to hear about their code. If this is the case, it may be better to move on to a different team sooner rather than later — especially if that person is an influential person in the organization, such as a supervisor or manager. Either way, the team hires the wrong people, and it has problems growing and retaining talent. As the industry has matured, I’ve found that such unreliable teams have become rare.
In a new project, there are infinite ways to solve a problem. The beauty of building a Web solution is that you can do it yourself. The open Web is a platform on which any radical idea can survive — as long as you send standard hypertext messages from the Server. So building web solutions lends itself to achieving goals in a team environment.
A team’s tools and discussions often add value to the team. The key is to embrace other people’s perspectives and take them to a new level.
A job that everyone hates
When I first started building websites, I had little idea what CSS was. As a result, my first job interview as a Web developer was a complete failure. Going deeper into CSS, I hate weird style rules. Because of my background as a programmer, I have a bias against CSS. CSS is like a foreign language to me, with global rules, no variables, and no encapsulation.
At that point, however, I decided to take CSS seriously. Since then I’ve been on a path to CSS mastery. _ Mastery begins with taking time to learn patiently and persistently. This is how your skills will reach new heights.
In a team environment, getting out of your comfort zone is essential. For example, is there a problem with the data layer? All right! Maybe it’s time to roll up our sleeves and get to work. Database problems that fail to design can spread throughout a team. If you settle comfortably on the front end, you miss a great opportunity to pick up the back end.
Or is there a merge problem on the branch where the code is published? Yes — maybe it’s time to light up your code management skill points and get your hands dirty. If a team doesn’t have software available online, users won’t pay for it. It may not be the warmest and coziest job, but it’s exactly what the team needs.
Or, how about making code review the first priority? Evaluating and providing feedback on code solutions can be grueling. However, it is extremely beneficial to know how your fellow engineers approach problems. The work that everyone hates to do is often the work that is most valuable to the team.
Can you think of a tool or skill that you hate but that you master? It’s a star Wars-like relationship of hate and control. In the end, Obi-Wan killed General Grievous in a blaster. So, don’t aim just to get the job done, aim consistently to get better.
Selfless Programmer
Let me make one final point. Have you ever wondered who are the best teammates you’ve ever worked with? Do you think they’re good for what they do for themselves or for what they do for you? Let’s say there’s a bad stored procedure that everyone hates, and someone takes the time to remove it from the database and add the appropriate unit tests. Despite having to deal with dirty code, these people rushed to take on more than their responsibilities and made things better. With the same attitude as these people, you can find opportunities to grow and create value. Producing usable software requires expertise, yet a good engineer tries to do the best for the team.
I’ve seen a team trying to get everyone to work well together. But it was a very self-conscious team, and the only thing they could hope for was to work hard and ask few questions. One by one, those who have mastered their comfort zone are king. In such a team, you can only do one screw, and the technology involved is very narrow. At that time, I used to struggle to find my footing because I focused on what I thought I was good at and felt good about. In the end, the team failed because the company set unrealistic expectations and cut budgets. This leads me to believe that this environment is bad for our career development. In this kind of team, at the end of the day, no one wins.
I’ve found that the best teams are those where everyone cares about everyone else. Each member can have a voice and be treated equally. When any member has different opinions, they can try to communicate and reach an agreement. In such a team environment, there are opportunities for growth. To put it more radically, in such a team, everyone is the leader. In short, a leader is a member who knows the difficulties well and is willing to help others. You don’t need a title or a black hat to be a leader on that team.
Leadership begins with mastering a job that everyone hates to do.
Leadership is when someone comes along and says, “I’m so glad you got that done. I can’t handle it.”
Leadership is about embracing the ideas and discussions of team members and pushing them forward.
Leadership is about genuinely caring about your team members. Use your passionate influence to perfect the team.
When I think of selfless programmers, I really think of them as leaders, people who put their comfort zone on the back burner.
conclusion
So understand these three simple ways to work more effectively on a Web team and give yourself the opportunity to grow as a team.
Of course, an open mind is a necessary quality for everyone to grow — and sometimes, allow yourself to do things you’ve never done before. As I did when I first started learning CSS, you might end up enjoying something you hate now.
The best attitude is, “Kid, I don’t know how to do this thing everyone hates to do, but let me fix it.” This is a perfect example of leadership — stepping up to the challenge when no one on the team knows how to get there.
How about you? Have you had similar experiences in a team? Do you have any insights you’d like to add? Have you ever left your comfort zone on a team to take on a new challenge?