Non-Technical Things I Learned At Coding Bootcamp
- Rubber Ducking Debugging
Rubber ducking is a debugging technique first described in the book The Pragmatic Programmer by Andy Hunt and Dave Thomas. A programmer is encouraged to go about debugging by explaining her code, line-by-line, to a rubber duck. The experience of explaining what the code is supposed to do while observing what the code actually does is a powerful problem-solving tool. It forces the programmer to identify the point at which her code is not doing what she wants it to do. It turns oh-shit moments into aha moments! Brilliant.
As David Hayes explained in his article The Psychology Underlying The Power Of Rubber Duck Debugging, two things happen when you use the technique. First, you slow down and explain things more clearly and thoroughly as humans think faster than they speak. Second, you are inherently assuming that your duck is more ignorant than you are in all code-related matters. In the process of slowing down while helping someone more ignorant understand your problem, you not only forced to be more accurate but also to pay closer attention to things you previously took for granted. It is at these times that you most often will discover errors in your reasoning or logic. This is the reason why coding communities such as Stack Exchange require members to put effort behind formulating questions as they have found that this process actually helps these members figure out the answers for themselves.
2. Pomodoro Technique
The Pomodoro is a time management method developed by Francesco Cirillo in the late 1980s. This is how it works: you break down your work into tasks, work intensely and purposefully for 25-minutes, put a check on a piece of paper (or the app nowadays), take a 5-minute break, repeat step two and three four times, after the fourth set, take a larger 15 to 30-minute break, then repeat the whole thing again. Fun fact: it is called Pomodoro -tomato in Italian- because the inventor used a tomato-shaped cooking timer when he first implemented the technique.
This simple yet highly effective technique was introduced to me by our instructor and has proven to be invaluable. There are a few ways in which it helps increase productivity. From taking time to plan a task before diving in, to eliminating distractions, reducing burnout through the use of frequent breaks, or achieving a better work/life balance by eliminating some of the guilt brought on by procrastination, to name a few.
3. Pair Programming
Pair programming is an agile development practice in which two programmers work together on a single workstation. The two rotate through the roles of “driver” and “navigator”. The “driver” handles the keyboard and mouse and focuses on the tactical issues at hand while explaining the code she writes. The “navigator” observes for errors and also provides strategic direction to the “driver”. Studies have shown that although pair programming on average increases the man-hours it takes to deliver code, it increases the quality of the resulting code and results in significant cost savings from prevented code defects. Programmers have also reported greater job satisfaction when engaging in pair programming. If pairs switch roles regularly and communicate openly, as they should, the practice contributes to increased learning and effective team-building.
Pairing variations include: expert-expert, expert-novice, and novice-novice. The first pairing may seem the less troublesome and most productive but has been shown to hamper creativity in problem solving as experts are least likely to challenge established practices. The expert-novice pairing most often leads to insights and new problem solving techniques provided that, on the one hand, the novice does not engage into the ‘watch the master’ mentality (described below), and on the other hand, the expert does not lack the patience and openness needed to make room for and accept the novice’s contribution. Lastly, the novice-novice pairing is usually avoided.
There are a couple of pitfalls to watch out for: the major one is disengagement often resulting from poor communication or lack of trust or respect between members. The second (which often leads to disengagement) is the “watch the master” phenomenon where a less experienced member always follows the lead of a more experienced member. Pair programming should not be a teacher-student relationship. Despite experience levels, it should feel like as equals working together. Click here for a great blogpost in which Julia Evans draws insights from 160 tweets describing programmers’ experiences with and thoughts on pair programming.
4. Feelings Friday
Every Friday afternoon, the whole class of about 20 people, as well as our instructor and teaching assistants, sit in a circle and share our feelings, comments, thoughts on the previous week. It gives everyone of us the opportunity to share with the group and hopefully connect as we go through a very intense experience together. As much as this practice made me uncomfortable at first, I grew to find value in it.
Sharing circles are a tradition of some Indigenous communities from various parts of North America. They provided the opportunity for members to be heard, respected and valued while voicing their own truths. Participants are encouraged to focus on expressing their own feelings and refrain from commenting on what anyone else has said. Only one person speaks at a time, upon receiving a sharing object that is being passed around. Listeners are encouraged to not pass any judgement but be open to learning from and about the others in the circle.
A similar practice is employed in agile software development. It is called Agile Retrospective. It is basically a meeting that takes place at the end of a one to two week development cycle, during which members reflect on what went on and identify areas for improvement. Similarly to that of a sharing circle, an atmosphere of trust, honesty and respect is necessary for each member to feel comfortable opening up. In his book Project Retrospectives: A Handbook for Team Review, Norman Kerth describes the prime directive, that should guide the culture of a retrospective: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”