Are You a Team Player?
Are You a Team Player?
After working on one of the most complicated projects of his career, a Zone Leader talks about the things he looks when placing members on his team.
Join the DZone community and get the full member experience.Join For Free
If I were to guess, I have probably worked on approximately 100 projects since I started my career in Information Technology in 1992. Without a doubt, my current project is certainly the most complicated and challenging project of that I've ever had. It has been so complex, that I feel like I need to provide a strong background when interviewing new team members for the project.
The Matrix Metaphor
During those interviews, I often recall the scene in the original Matrix movie —where Neo meets with Morpheus for the very first time. If you need a recap, I've attached the scene below:
After explaining the complexities and expectations to be a member of the project team, I would reference the red pill and the blue pill from the Matrix. I would tell the team members that they can take the blue pill and basically walk away from the project with no hard feelings. Conversely, they could take the red pill and dive in to see just where this project takes us... or see how deep the rabbit hole goes.
Believe it or not, I have had a few candidates opt to take the blue pill and walk away.
You may also like: The Programmer’s Guide to Working on a Team.
Finding The *Right* Team Members
Before I reached the point where I would discuss the details of the project, I needed to meet with candidates to determine if they were a good fit for our team. In essence, this was similar to a job interview — except these team members were already employed by CleanSlate Technology Group or one of our business partners.
Where things differ when placing team members on a project, is that you can get into the details with the potential team member, asking hard questions that require quick analysis to resolve. What I was able to conclude from these discussions is a collection of things I look for and things I definitely wanted to avoid.
Consider these examples.
Example #1 - Not My Problem (I Don't Need To Understand)
While a lot of projects seek full-stack developers, on this project we decided to keep team members focused on certain aspects of the application. So, front-end developers would remain focused on the latest Angular client and RxJS framework implementation and not have to write RESTful API methods.
However, ideal team members will always be willing to review the source code of the RESTful API when they cannot determine the correct answer when reviewing the API documentation. What is not ever acceptable for someone on my team is to throw one's hands up in the air and announce, "that's not my problem" or even worse, state "I don't really need to understand that because it's on the server-side."
In one example, after working with an adjacent team member, I took time to show just how easy it is to review the source code and find the answer that was lacking. In this case, the issue was more to do with the individual not taking time to understand the specifications, which caused incorrect assumptions to be made.
Ideal team members are always eager to dive into another repository to obtain an answer.
Example #2 - Someone Else's Mistake
During a pull-request (PR), I was looking over code from another team of API developers. In view of the code that had changed, I noticed an issue with code that was in very close proximity, but was not code that had changed.
The fix was minor and was going to be validated with unit tests that already existed. As a result, I suggested that the developer make a correction to the code — going as far as detailing the fix in the comment within the PR.
To my surprise, the individual replied to indicate "this is not code that our team has written, so we do not feel comfortable making this change." Keep in mind, the other team was from the same corporation who had submitted a PR for me to review.
In the end, our team fixed the issue with our next release because we wanted to make sure our customer received the best product we could deliver.
Ideal team members are always looking to improve the application, regardless if they wrote the code that needs to be updated.
Example #3 - Avoid Laziness
As developers, it is easy to let the temptation creep in to work fast or program in a lazy fashion. When this mode consumes the developer, expected documentation is unpolished or missing, standards around naming conventions are not honored, or unit test coverage becomes non-existent.
In all of these cases, I will likely find them during the PR stage and ask for them to be corrected. While some of these are likely minor in nature, I fully believe that developers should do their best to provide a solution that is easy to read and clear to support. Laziness or working fast always tends to lead to sub-par code.
Ideal team members remain focused and adhere to standards and expectations.
Example #4 - Be a Boy Scout
In 1910 the Boy Scouts of America was founded. Just two years after, Baden-Powell published "Scouting for Boys," which stated the universally known "Be Prepared" motto.
This motto can and should be applied to every feature developer on every feature team participating on some development effort. Some examples include:
- Plan your next day at the end of the prior day.
- Be ready for things to change. Accept the change and work towards a new goal or target.
- Make sure you are always in a productive state, focused and prepared to deliver results.
Being prepared is a trait that is evident to others, but is also one that can become infectious to others ... in a very good way. That is how some teams just seem to always produce positive results.
Ideal team members are always prepared.
My goal for this article is to hopefully spawn some thought cycles that could be considered when interviewing for a future position — either as a consultant or a full-time employee.
Projects like the one I have been staffing are certainly the exception more than the norm — at least that is my conclusion after twenty-seven years as a developer. If it is your goal to be a part of an amazing project, you have to leave a positive impression on the person making the determination to give you an offer (or not).
Using the examples above:
- You are always ready to dive into the source code, even when it isn't under your control.
- Jump in to help others is always the right answer, even when it takes more of your time.
- Always fight the temptation to be lazy, sacrificing detail, or delivering sub-par code.
- Be prepared — every minute of every day, focused on delivering the best that you can be.
Having been part of this project has been the most rewarding and refreshing experience of my career. Each week has proven to introduce new challenges and problems to solve - always leading to new experiences and personal fulfillment.
I hope you get to experience a project like this at least once in your career!
Have a really great day!
Opinions expressed by DZone contributors are their own.