More than in most other professions, partnership and group work are integral to successful software engineering. While the myth of the lone genius hacker prevails, the reality of working in the tech industry is very different. A vast majority of companies of all sizes use a team-based approach to development.
As a student at Flatiron School, I've been able to experience both partner and team based projects. In my experience, the two main ways a project is coded is either through pair programming, or by having each collaborator be responsible for a feature.
Pair Programming
The Agile Alliance's definition:
Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so.
My first partnered project at Flatiron was built completely using pair programming. My partner and I planned out each feature together, and coded each one together as well. As beginner programmers, the ability to talk through the code while building meant that our minds were constantly engaged and the code was being proofread as we went. Because we had two brains working on the same problem, we were able to compliment each other, sharing knowledge and skill as we went. For me, the instant feedback of having another person right there was the most valuable part. Sometimes, the methodology involved in pair programming was akin to white-boarding as we went.
Dividing Work by Feature
In my second paired project, we started out using pair programming but once the basics had been set up, we divided the features between us and worked on them separately. We came together every few hours, comparing notes, going over code, and working on styling.
This method involved practicing different skills from pair programming. The independence meant that while my partner was there for backup, I was responsible for that feature, and therefore its integration into the project itself. The responsibility added pressure, a feeling of a lack of safety net, but at the same time, it spurred me to want to research and find the best ways to complete the task. Of course, my partner was available for brainstorming and help whenever I needed her, but when the feature came together and worked, there was a definite feeling of victory. It also made me feel like a contributor, creating a part that was integral to the whole.
Useful Tools
No matter what method is being used for the build, planning is integral to the execution. We were using the agile method as much as possible, planning and building in thin vertical slices, coming together for review, testing, deployment and further planning whenever a feature was complete.
Trello is an indispensable tool in a developer's arsenal. It provides the ability to plan features down to the most minute detail, create task boards that assist with visualization, and track progress.
Conclusion
Both pair programming and individual feature work have their pros and cons. Pair programming bends the power of two brains onto one problem, allowing for instant communication and inline proofreading. However, having two developers work on a feature together means that the project may take longer than if the partners were working individually. Individual feature work offers independence and speed, but also a greater allowance for mistakes and requires time to be taken for separate review.
Regardless of the method used, my main takeaway from both projects was the necessity of "buy-in". Each of the partners has to believe in what they're doing, and the method being used. Agile especially requires that everyone on a team is on the same page, and is working fluidly together.
Top comments (0)