Working Well With Others
The idea creating with code from nothing more than structured bits and bytes is tantalizing to me. However you cannot create in a vacuum. At Turing School of Design, I learned group work was both a boon as you could create more features but also a liability. You must work well together to achieve a mutually shared mission and deliver features on time. Below are my thoughts on the attributes of a successful dev team.
Attributes of a successful team …
Goal oriented and metric driven
The most successful teams seems to be concerned with defining what they would like to accomplish and in what timeframe.
Define how they work … early on
Teams that define how they would like to work early on develop better workflows, quicker. Intuitively, this makes sense. If you can define what you consider a good collaboration process, and start on that process, you’re not derailed when there are missed expectations and hurt feelings. A good example of this was during our group project. We decided that we would require mandatory reviews of all merged code. This forced code reviews of everything entering our “production” code base. Defining norms and preferences enables the team to relax into it’s possibility.
Checks in … Regularly
Teams that check in regularly seem to hold together longer and write better code when they are apart. This was embodied when our team meet at the end of our first group “sprint” to review what went well and what needed refactoring. When we failed to have this type of a scheduled meeting during our second sprint, our work and performance as a team suffered.
Makes Compromises
… when appropriate,
… and with moderation
Sometimes the work is just that, the work. There is no getting around that fact that good program logic and design takes time and energy. However, we don’t all have to work the same way to get to the end result. In our group, some team member’s preferred to “spike” up solutions and then write the corresponding tests after an proximate solution was developed. While this is not classically Test Driven Development, a compromise was implemented requiring all code to be fully tested before hitting the master branch. While our group did not rid ourselves of TDD completely, we did show flexibility in our communal work flow.
Makes Pairs … when needed
Sometimes two heads are better than one. Groups that encourage members to make subgroups to solve particularly challenging problem spaces do better. There is a time for individual contribution, especially when the work is about reinforcement and perfunctory code to make the whirly-gig whirl. But when you need someone to bounce ideas off, there is nothing like another human being. Unless, you have a dog…I hear they are also particularly helpful code copilots
Plan for the unexpected
Groups that allow time and avoid procrastination are in a better spot to succeed. Waiting to the last day to implement the last major feature might not be best path for deep learning. However, planning to complete that feature three days prior – much better.
Closing thoughts
See the big picture
Allow yourself to see the forest. Yes, you are stuck in the trees…
When you are in the middle of a project with others it’s easy to feel discouraged and wonder if you will complete all deliverables in a timely fashion.
The work is keeping your frustration in place and allow your group to learn the difficult concepts in time to implement the feature. In our project, despite being behind and frustrated, we continued learning until we implemented the difficult to understand concept of a joins table in our relational database. This allowed us to set up a needed many to many relationship and complete our deliverable.
Working well with others is the cornerstone of professional software development. I am learning what I bring to the table and what is needed to push well written and structured code.