Anyone that has known me for more than, say, a couple of weeks, knows that my other big passion (coding is one, of course) is cooking. I love to cook. As I’ve progressed in my journey as a novice developer, I have seen parallels between learning to code and learning to cook.
When I was first learning to cook as a newly minted ex-student who actually had enough money to live off more than ramen noodles, I did so by buying cookbooks, selecting some recipes that didn’t look too complicated, and following the recipes exactly. There was no experimentation. No “what happens if I swap the basil for cilantro?”, or “I don’t think I want that much salt”, or “I think I should add more tomatoes to this”. No meaningful tasting (testing) of the recipe halfway through cooking. And certainly no cooking with others.
As my confidence grew, I started deviating from recipes – a little more coriander, less turmeric, swapping potatoes for parsnips, or spinach for swiss chard. Generally these deviations were edible (although there were some disasters), and this led to more experimentation.
Now, when I look at a recipe, if the cuisine is generally familiar to me, I take the ingredients and overall instructions as mere guidelines; freely changing it up to suit my personal taste and, to my mind at least, creating something better than the original.
Of course, cooking at home, where you are likely the only cook in the kitchen, is very different to cooking in a commercial kitchen, where there are many cooks each with their own individual tasks and hopefully none are spoiling the broth.
So it is with coding.
When first learning to code, as I have been, you follow the tutorials and you follow them exactly. No deviations. Because, really, at this stage, you don’t understand how all the pieces fit together, what they do, and how tweaking one might affect another component. Just like reducing salt might lead you to add more lemon juice or herbs to the basic recipe, so you have to learn what each part of your code brings to the table.
But this isn’t all there is to being a professional coder. One of the things CoderCamps gives its students is the experience of coding with others on a group project. Contrary to popular belief, coders do actually have to work with others. And there are two common approaches, often used together, that are found out in the real world:
- You can code with a partner (“paired programming”, which ideally is closer to what the CTO expects than not).
- Or you can code as part of a team (commonly known as “Agile”, which is hopefully not too close to the ever-dysfunctional world of Dilbert).
So how does this relate to cooking?
Well, paired programming is a little like having a sous-chef to help you out. One of the pair will be the lead (or the one with their hands on the keyboard, at least). The other will play a supporting role – ideally there to offer helpful suggestions, critiques and fetch caffeinated beverages. At least, in my ideal scenario that would be the case. For paired programming to work well, you need two people with complementary skills – I might be awesome at database design, but terrible at CSS. My perfect programming partner would be someone who’s awesome at CSS, and is at least familiar enough with database design to point out when I’m doing something silly.
Coding as part of a team – which is how most large software products get created – works best when you have complementary skills among the team members, and clearly defined tasks for each person. This is where Agile methodology comes into play – the team may be self-managing, but at any time you should know exactly what tasks you should be working on and how your task relates to others’ work. As with cooking in a commercial kitchen – if it’s your job to chop the vegetables, you have to get that done well before the chef even thinks about plating the dish.
I’m now two weeks into my group project (which is why I’ve been so quiet the past couple of weeks). We have a diverse group of 5 people, all with different skill levels, strengths, and weaknesses. Some of us (like myself) have been at least dabbling in code for a few years. Others are brand new to the field. Learning to work together (especially as we are mostly remote) has been a challenge at times. And learning to effectively use a source control (Visual Studio Team Services, with Git, in our case) has been a challenge.
But the key lessons I have learned here are:
- Communication. Not just at stand-ups, but just in being aware of what everyone else is working on and how my little piece fits in.
- The right task for the right person. We all have different strengths and weaknesses. Don’t give someone a task that they cannot possibly complete.
- Asking for help. You’ll get stuck. Someone else might have the answer, and even if they don’t sometimes just talking it out with another human being can make things “click”.
- Always keep a local backup of your work. Bad merges happen and you don’t want to lose a day of work because you’re still figuring out the intricacies of Git.