In the early days of our journey at Software Engineering, I was a compact unit of developer operating on my own sort of like lone wolves. This approach worked well for me in the beginning, my tasks were straightforward, my codebase was small, and I didn’t need any collaboration or let say it was minimal. But as I grew in experiences and taking more complex coding course in my uni, I realized that it was time to transition from individual coding to collaborative team projects. This wasn’t just about and increasing manpower (and, of course, for the sake of finishing mandatory group assignment 🗿) but also about adopting new tools and practices to improve our team’s efficiency to finish the project.
Let’s start by contrasting the experience of coding alone versus working as a team on a project.
Solo Coding vs Team Projects 🎭
When you’re coding on your own, you have total control over your project. You make all the decisions, write all the code, and handle all the debugging. The speed at which you progress depends entirely on you. This can be both liberating and daunting, especially as the complexity of the project grows.
On the other hand, working on a team project introduces a new set of dynamics. You are no longer the sole decision-maker or coder. The likelihood for seeing a trash code being committed on your repo is quite high. Or let say if you are the problem, the chance that you would be hated is very likely high because it’s not only your trash project alone 😌 it’s no longer a solo endeavor; it’s a team project that everyone cares deeply about (because we don’t want to mess up our GPA in this semester).
You have to communicate effectively, make collective decisions, distribute tasks, and work together to debug and optimize your code. This might sound challenging, but it also allows for faster development, more robust solutions, and the ability to tackle more complex projects.
To help us transition to this collaborative model and improve our efficiency, we started adopting several tools and practices such as merge requests, scrum boards, and commit messages. Let’s dive into each one of them.
The Heart of Collaboration 🧩
Introducing Github Pull Requests into our workflow was indeed a game-changer. It acted as a catalyst for code review and collaboration, creating an environment conducive to maintaining high-quality code and simultaneously facilitating knowledge sharing among our team members.
Before, handling code contributions from different team members was like juggling multiple balls at once. But with pull requests, this process has become more streamlined and efficient. Each feature, enhancement, or bug fix is developed on a separate branch, distinct from the main codebase. This allows team members to work independently on their respective tasks without disturbing the main codebase.
When a team member believes their work is ready to be merged into the main codebase, they create a pull request. This pull request acts as a platform for reviewing, discussing, and refining the proposed changes. It’s like a conversation thread tied to the specific code changes, making it easier to track and understand the rationale behind each modification.
Pull requests have fundamentally changed the way we approach code review. Now, every line of code is scrutinized and constructively critiqued before it’s merged. This rigorous process ensures that the final code is robust, efficient, and adheres to our coding standards. It prevents bugs and errors from creeping into the main codebase and helps us keep technical debt in check. Look how cute we collaborate using pull requests and peacefully giving each other suggestion without hatred 😊
Visualizing Work 📋
Next in our toolbox, we adopted the scrum board using Github Project, a powerful visual tool, for tracking the progress of our projects. This invaluable asset allowed us to effectively organize our tasks into the 5 categories:
- Backlog: This is where all the tasks or user stories for the project initially reside. The backlog represents work that needs to be done but hasn’t been started yet. It includes all the features, enhancements, and bug fixes that have been identified for the project, but not yet prioritized or scheduled for a particular sprint.
- In Progress: Once a task or user story is moved from the backlog and the work has started, it goes into the ‘In Progress’ column. It signifies that a team member is currently working on this particular task.
- Ready: This column is typically used for tasks that have been completed by the team member and are ready for review or testing. It indicates that the task is no longer being actively worked on and is waiting for someone from the team to review or test the new changes
- In Review: this signifies that it is currently being reviewed for quality, accuracy, and completion. This could be a code review by another team developer that is assigned to review the backlog
- Done: Once a task has been reviewed and approved, it is moved to the ‘Done’ column. This indicates that the task has been completed to satisfaction and requires no further work. It represents a closed task, a completed user story, or a finished feature or bug fix.
This kind of board mapping providing us with a crystal-clear view of the team’s workflow. Github Project served as a visual representation of our project’s timeline, depicting the flow of work from inception to completion. It transformed the way we worked, making our workflows more transparent, and the status of tasks and responsibilities more apparent to everyone in the team.
Moreover, the scrum board played a crucial role in helping us prioritize our tasks. It offered a bird’s-eye view of the entire project, allowing us to easily spot high-priority tasks that needed immediate attention. It also made bottlenecks visible, highlighting areas in our process where work was getting stuck or slowed down.
During stand-ups, team members could easily refer to the board to discuss what they had completed, what they were working on, and any issues they were facing. For sprint planning, the board was a great tool for visually organizing and assigning tasks for the upcoming sprint.
Commit and Comment Messages = Clear Communication 📝
Finally, we started paying more attention to another commit messages. When you’re coding alone, it’s easy to overlook the importance of commit messages. But in a team project, clear and descriptive commit messages are crucial.
Each commit message serves as a log for the changes made, explaining what was done and why. This makes it easier to understand the project’s history and to track down when and why a particular change was made. It’s a small detail that greatly increases the maintainability and understandability of our codebase.
In conclusion, the journey from a solitary coder to a team player is not only a necessary transition but also a rewarding one in the field of software engineering. As we navigate through more complex projects, the need for collaboration and efficient teamwork becomes vital. Embracing tools and practices such as Github Pull Requests, Scrum Boards, and clear commit messages not only enhances our team’s efficiency but also promotes a culture of quality, transparency, and continuous learning.
Through this process, we learn to appreciate the synergy of a team, where collective efforts lead to outcomes greater than the sum of individual contributions. We learn to constructively critique, accept feedback, and constantly evolve our code to meet the highest standards of quality. We also learn to communicate effectively, helping everyone in the team to understand our code and the rationale behind our decisions.
In essence, this journey is about transforming our engineering mindset. It’s about moving from “my code” to “our code”, recognizing that our success lies not in individual brilliance but in our ability to work together, learn from each other, and deliver robust, efficient solutions as a team. This shift not only makes us better engineers but also prepares us for the collaborative nature of the modern tech industry. So, here’s to teamwork, collaboration, and the endless journey of learning and growth in software engineering.
