Alumni Q&A: Pair Programming Guide
Great software engineers are skilled at more than just coding. In fact, at Codesmith, we know that...
As I enter the first week of the Production Phase at Codesmith, the emotional twists and turns of the past 6 weeks and subsequent blows to my confidence levels remind me of the lessons learned in my University psychology courses. Specifically, the Dunning-Kruger effect suggests that as one steps out of the realm of novice, we quickly begin to learn just how expansive the topic at hand truly is and how much knowledge/experience we have yet to acquire.
Although my confidence levels have certainly reached record lows as I jump from researching Docker to Kubernetes to GraphQL in the span of a few days, I constantly remind myself of how far I’ve come throughout my time at Codesmith.
Having taken a few classes in Java/OCaml during my undergrad, I was not only eager to tackle Javascript and the Frontend/Backend technologies in the Codesmith curriculum, I was mostly excited to finally learn in a cooperative environment.
Unlike the stringent environment of university computer science courses that actively discourage students from collaborating on code, Codesmith’s curriculum truly embraces collaboration through their pair programming model. Not only did I find myself making great new friends in my cohort, I also found myself learning constantly from each pair programming partner.
RELATED: HOW CODESMITH BRIDGES THE GAP BETWEEN A CS DEGREE AND A CAREER IN SOFTWARE ENGINEERING
As we switched Driver/Navigator roles, I was truly blown away by how my cohort mates would translate my verbal suggestions into bits of code that solved each problem in ways I wouldn’t have considered otherwise.
This intensely collaborative environment enabled our cohort to not only grow closer as a team and intimately learn with one another, but this structure also meant we could learn wealths of information in a small period of time. Regardless of whether one partner (likely me!) dozed off slightly during lecture or if one partner had a hard time wrapping their mind around a new tech stack, having another partner to lean on meant we had another shoulder to lean on. Filling these small gaps in each other’s knowledge meant we could practice our teaching/technical communication chops, clear up any misunderstandings, and breeze through tons of new/difficult information.
Perhaps the most startling reminder of the power of cooperative learning came about when we finally hit the project phase of the curriculum. Finally reaching the Solo Project meant I was wildly excited about getting to turn my video camera off, queueing up jams on spotify, and coming up with my own, unique/creative project. While I quickly came to the idea of a Full-Stack Stock Simulator that would allow users to buy/sell stocks using historical Stock data from early 2020... I soon realized just how much I missed working with a team.
RELATED: A DEEP DIVE INTO THE IMMERSIVE PROGRAM'S PROJECT PHASE
By the end of the two Solo project days, I had successfully pulled historical stock data from a free API, allowed users to select starting money amounts, users could then see the Open-Price for stocks like AAPL, TSLA, and GOOG and they could thereby purchase stocks. The app would then let users advance a day to see how their stocks performed. However, did the app have a login page? Did I have enough time to prettify and make a slick interface? Could users search/add more stocks? The answer is a resounding No!
Although I was certainly proud of the project I accomplished utilizing new tech stacks/technique, the Solo project truly reminded me of the importance of bouncing ideas off a team, divvying up tasks, and having another shoulder for emotional support.
Contrasting with the following Scratch project in which my team of four created a beautifully crafted, Farmer-to-Consumer app that let consumers signup/login, browse an aesthetic market-place, add items to their cart, view a map, and checkout... collaboration is a world’s apart from solo projects. Not only did we meet most of our MVP goals, but we also supported one another throughout every step through frequent stand-ups to check-in, hopping zoom rooms to solve technical bugs, and setting clear expectations.
So, as I embark on the next big-step along my software engineering journey... I can’t help but be immensely grateful for my unbelievably collaborative and knowledgeable cohort mates. The roller coaster of emotions caused by the production project ideation week certainly wouldn’t be the same without the lovely Codesmith Cohort NY22!
Blog written by Miguel G.
---
Miguel is one of many graduates sharing their insights on the Codesmith Immersive experience. Take a look at this blog where Cedric shares why he chose Codesmith and what the admissions process was like. Cedric lost his job due to the pandemic and decided to make a career-change into tech. Within a few months, he enrolled in Codesmith’s Software Engineering Immersive in NYC.