[P&R#4] Reflections on my Thoughtworks University (TWU) Experience
Thoughtworks University is a three week long intensive training program for all graduate new hires at Thoughtworks. The curriculum primarily comprises of sessions which are delivered by trainers and Client Engagement sessions where trainees are tasked to deliver a mock client project. I've learnt so much over the course of this three weeks and I'd like to use this opportunity to jot down three topics of reflection.
On Pair Programming
I first heard about this practice when I was in studying in Nanyang Technological University and I've been enthralled by its promises to deliver better quality software over solo programming. From my understanding, this concept was first introduced by Kent Beck in his book Extreme Programming in which he argues for software practices to be taken to "extreme" levels to improve software quality. I've been curious to try pair programming ever since. As its name suggests, pair programming involves two persons - a driver and a navigator - working together to deliver a piece of software. The role of the driver is to write the code and to explain his or her intentions of the code to the navigator. With the implementation details being handled by the driver, the navigator will supposedly be freed up to think about the higher level design of the program and to communicate this to the driver to steer him or her in the right direction.
For my first job out of university, I had proposed this idea of trying out pair programming to my manager. While he had encouraged my to take the initiative to speak with the other developers to see if they might be interested, it eventually didn't happen, and I believe there were several reasons for this outcome. First and foremost, I had no idea how to do pair programming right. Second, I think the system in place was such that tasks were very much owned by the individual, and this made it difficult for me to ask others for a significant amount of their time to work on my task with me. Although this didn't work out the way I had expected, I am still immensely thankful to the folks at that company for working with me. In addition, it was through this experience that I had a better understanding of how it is like to develop software through solo programming.
When I heard that pair programming was a key practice here at Thoughtworks, I couldn't resist picking up Laurie William's book, "Pair Programming, Illuminated". I particularly enjoyed the topics on the social dynamics within pairs and the do's and don'ts of being a good pair programmer. While these ideas made complete sense to me as I was reading the book, I must admit that putting these ideas into practice was not as simple. After the first two weeks of pair programming, one of my partners feedbacked that I was not articulating my intentions well enough as a driver and it was difficult to follow my train of thought (by any chance that that partner is reading this, I'd like to sincerely thank you once again for your courage for letting me know). This feedback was a refreshing wake up call indeed; it was something that I take seriously and which I clearly intend to improve on. The following week, I made it a point to communicate my ideas clearly and to regularly check with my partner to see if he had understood what I said. I'm happy to share that these efforts paid off, as he informed me that I had done a great job pairing that week and he had thoroughly enjoyed the experience.
With that said, what do I think of pair programming? Overall, I do believe that it is a fantastic idea. Working in pairs is a great way to share knowledge and it gives individuals the confidence to communicate when things are not going according to plan. However, there are several issues which merit attention. First, I believe it's extremely important for both programmers to clearly understand their roles and what is expected of them. Second, both programmers must recognize that they are both responsible for whatever they produce. This shared ownership must also mean that there is a greater incentive for both individuals to uphold the quality of their work, rather than letting it slide on the false pretext that the costs of mistakes are diluted within the pair. Third, I believe pair programmers work best when they are working on tasks which can benefit from their collective knowledge. If, for example, both individuals are not familiar with the codebase or technologies used, it might be preferable for the individuals to work on their own first to learn before coming together to pair.
On Trunk-Based vs Feature-Based Branching
This contention between having to choose between trunk-based and feature-based branching strategy was yet another interesting lesson for me. Where I was working previously, programmers contributed to a large mono-repository and we had adopted the feature-based branching strategy. This meant that when a programmer wanted to work on a new feature, he or she will create a feature branch off of main and do the work on the feature branch. When the feature was ready, the programmer would follow a process to review the changes (submitting a pull request for example) before merging it back to the main branch. In my opinion, one key advantage of this strategy is that programmers can continually upload their changes to the remote repository even if the changes are not complete. This might be especially relevant when programmers are working in pairs and there's a constant need to regularly switch roles while working on a feature. However, as the changes are only reviewed when the feature is complete, one big drawback of this strategy is that branches are often long-lived and the changes are not continuously being integrated back into main. This can lead to long lead times between when a story is kicked off and when feedback can be received from the client or end user. Having worked on a feature that spanned several weeks in my previous company, I can definitely attest to these issues.
At Thoughtworks, the default branching strategy is trunk-based. This strategy revolves around one main branch (called the trunk) where all programmers work off on. Whenever a change needs to be made, developers would perform a "check in dance". Briefly, this involves pulling the latest changes from main, making small incremental changes locally, rebasing from main, running all tests and the merging back to main. Trunk-based development means that all work takes place in very short lived "branches" and changes are continuously being integrated back into the main branch. The key advantage of this is that programmers are encouraged to work in small incremental changes and these changes can be regularly reviewed by relevant stakeholders. This is especially so when it comes to pair programming, since developers are constantly looking to push changes back to main so that their roles can be switched. If a change grows too large (which I have experienced myself during TWU), it becomes challenging to bring the changes back to main and to switch roles. In my view, this branching strategy is instrumental to Test Driven Development too, as developers are forced to be conscious about writing good tests in order to turn any work in.
When this concept was first introduced to me, I acknowledge that it was quite difficult to grasp having come from a feature based branching background. This contention even led to an intense discussion among the team during one of the regular meetings. Eventually, through the patient explanation by my fantastic and knowledgeable trainer, I was convinced of the merits of the trunk-based strategy. The team eventually decided to adopt it and I'm immensely thankful that we did. Truly, this was one of the issues that forced me to challenge my previous assumptions and to learn and grow.
For more information about this topic, I highly recommend listening to the Software Engineering Radio's interview with James Socol on Continuous Integration (CI) and Continuous Delivery (CD).
On Leadership
"Yet sometimes, even when I was in the midst of these splendid men or with the forward divisions, doubt and fear slunk in upon me. I was asking so much of them - was it too much? In no other theatre would an army have launched on such a task with so pitiful in equipment. Success depended on what? Luck? A Japanese pilot streaking the treetops in his Oscar, and enemy agent with a wireless set crouched above the track counting tanks, or a prisoner tortured until he talked - and Kimura's divisions would move, the muzzles of his guns swing towards our crossing places. Imagination is necessary for a general, but it must be controlled imagination. At times I regained control of mine only by an effort of will, of concentration on the immediate job in hand, whatever it was. And then I walked once more among my soldiers, and I, who should have inspired them, not for the first or last time, drew courage from them. Men like these could not fail. God helps those who help themselves. He would help us." - Field Marshal Viscount William Slim
My understanding of leadership is admittedly simplistic - it's about recognizing when something needs to be done to bring others closer to their objectives and taking the initiative to do it. We all practice some form of leadership everyday, whether it's being there for our loved ones or caring for our friends and colleagues. I am indeed blessed to have been given the opportunity in TWU to lead, in the form of facilitating meetings during the first two weeks of TWU. Yet sometimes, doubt and fear do sink in upon me. There were many times where I do not know what's the next step to take, or when I question the effectiveness of my leadership. There were also many times where I catch myself wondering if I'm listening effectively, doing things right or saying the right things to encourage my peers. Thankfully, it's truly wonderful to be surrounded by the most amazing and talented colleagues who I have learnt so much from and who are there to offer suggestions and to work together to figure things out with me.
The topic on leadership is one I hold very dear to my heart. I'm honoured to have been given the chance to lead men in the field during my time in the Singapore Armed Forces, and I'd very much like to develop this trait further in the workplace. Yet, I recognize that there's still a long journey for me ahead on my path to becoming an effective leader. One of the first steps I'd like to take at this stage of my career is to learn how to be managed well, and I plan to do so by reading the first few chapters of Camille Fournier's The Manager's Path. I'd also like to explore the topic of emotional intelligence further by reading Daniel Goleman's book.
Related to the topic of leadership, there are two other key lessons from this TWU experience which I'd like to highlight. The first is about taking a step back to listen to others and to be genuinely interested in the things that others are interested in or which they find meaning in. The second is on feedback. Thoughtworks places a high degree of importance on the feedback process. Thoughtworkers are encouraged to constantly give, seek, receive and act on the feedback they received. I resonate strongly with this practice. Looking back at some of the projects I've been on in the past, there were many times where I felt I could have done better but I was not sure how to. It would have helped tremendously if I had asked for feedback from my supervisors and my peers. This is a practice that I'd continue to promote and practice more in the future.
Conclusion
I've met so many amazing folks and learnt so much from this experience at Thoughtworks University. I am immensely grateful for this experience. Now, onwards to the next phase of my journey!