Hack Reactor week 2 is done! Let’s do a review over some beer.

nQueens

nQueens was the most rewarding paired programming project I’ve done so far, even though it was technically probably the most difficult.

Kickoff

Right from the beginning I had a great kickoff with Kenny, where we established our experiences thus far - what we liked, what we didn’t. As it happened, our experiences up to the pairing were somewhat opposite, so it was a great opportunity for us to grow.

For me, I let him know I felt I had been taking too much control “drivigating” in my other pairings, and that it was important to me to have my partner be able to not feel deprived of their technical learning experience here. In response, he told me it was his experience up til then that he didn’t really feel like he had been able to code a lot. I got the sense he wasn’t finding programming to be very satisfying because of this.

I told Kenny I wanted him to challenge me if he disagreed with any ideas or he needed clarification on any of my thoughts. I think this set a great precedent for our work together, as there were many instances where we disagreed or the direction was vague, and the resolution was found by stopping and taking the time to draw out our thoughts.

Debug your life!

We had a great time coding during our sprint. Kenny fed me some awesome compliments such as repeatedly calling me a “debugging god”, which I have to admit, I had to try very hard not show my ego growing :). To be fair to myself, and to recognize my own strengths, it’s something I’ve received compliments on from my partners and other students thus far. Many people have asked, and I explain that my dad taught me how to debug when I was younger, and my mindset has always been to constantly overthink and trace problems back to their root. As I’ve said many times and will continue to do so throughout this cohort (and beyond), I truly feel that debugging isn’t a programming concept, it’s a life concept. Debug your life! :)

Highlights

During our paired feedback session, Kenny asked what my highlight was. I told him that coming into the sprint, it was my deliberate intention to be more empathetic and supportive as a programming partner - to make it my goal to not only grow, but help my partner grow as well. I told him that with this in mind, my highlight was seeing with my own eyes how much better and more confident he was in programming in only our two days working together. I didn’t want to attribute his growth to myself, but I did tell him it was a goal of mine to push him up. He seemed to be very happy with my response, and told me that it really was the case that he felt better about programming after our pairing. I felt a camaraderie was established, and in being validated for my effots, I felt I had grown as a person.

Growth opportunities

In terms of paired programming, I felt we did a great job. However, I definitely had personal weaknesses here.

Algorithm analysis

First, we spent about half a day pseudocoding then coding a solution, and that process was great. However, our initial algorithm completely missed the mark and was too naive, and returned only a fraction of the expected results. We had many conversations and design discussions, and yet the flaw in our starting logic didn’t occur to either of us. I’m not sure what to say about this except that in further specifications I’ll need to attempt to drill even further down to ask myself about other scenarios, e.g. whether given one input, is there really only one solution? There answer can and definitely will often times be no.

Personal maintenance

Secondly, I’ve always had a terrible habit of going into the deep end when I like doing something. Whether it be Jiu Jitsu or coding, it’s very easy for me to neglect other responsibilities when I’m deep into something. In the case of this sprint, I skipped dinner everyday because I was so obsessed with finding the answer when we’d be stuck. I’m sure if I keep on doing this, partners may feel pressure to do the same if they see me continuously sitting there drawing diagrams to myself and analyzing code, and that wouldn’t be healthy for them or myself.

Chatterbot

It’s strange. Coming out of nQueens I was on a paired programming high and was so excited for more. When I found out my partner was going to be Zach, I was ecstatic, because I’ve given him shoutouts before for being such a positive and encouraging student. However, I felt more challenged in this pairing than I had before.

Kickoff

Like with Kenny, I explained to Zach I didn’t want to be drivigating, and that I wanted him to ask me questions and challenge me any time. We were off to a good start.

Verbalizing logic

Zach’s area of strength, and something I really appreciate, is that he’s not afraid to put the brakes on in order to discuss something until he understands it. This was actually great for me because it pushed me to explain logic starting from a higher level, and then drill down as his understanding increased.

Mistake: assuming shared backgrounds

Despite my initial excitement, our pairing wasn’t as smooth as I expected, and I still reflect and feel bad about it. I guess I’ve lived in a tech bubble most of my life and assume people know the general flow of internet and web development. I forget that the concept of servers, backend code, frontend code, relational data tables, are not regular parts of everyone’s lives, and that many people choose to come to Hack Reactor from a non-technical background.

Based on this faulty assumption, I think I was explaining things in ways that made Zach frustrated because I may have made it seem like they’re easy concepts, when they’re not. Not to say it was only him that showed frustration, because even though I didn’t want to, I think my own delivery may have conveyed frustration as well. He reassured me I wasn’t offending him, and that he enjoyed being able to see how I think, especially when I’m coding and talking out loud. However, I know there were little moments of frustration, and it’s a disappointment and a learning lesson for me because coming into this, I knew Zach was cognizant of not coming from a techincal background, and I didn’t want him to feel pressured by that. In that regard, I don’t think I did well, and will need to continue to think about this.

Opportunities for growth

I’ll focus on being more deliberate about meeting my partners in the middle, and continue to push myself to be more empathetic toward my them.

On a technical level, some of the good habits I had built in terms of code design weren’t in strong display in this sprint. The concept of MVC isn’t new to me, but the actual implementation of it was challenging. We spent a day writing code that didn’t explicitly adhere to the MVC archeticture, and had to do some refactoring on the second day as we came to understand it better. Looking back, I wonder if it have been better for us to study it a little more ahead? The pace of the program is so fast, so it’s hard to tell if even that would have been the right approach.

Something else I’m thinking about is how people ask for help. For me, I rarely do so even if I’ve been staring at lines of code for hours. The process of debugging, tracing and solving on my own is very important to me. However, Zach and some others do have a different philosophy in that they feel it’s better to ask for guidance rather than spend too much time not seeing an answer. I don’t think the method is wrong or any less valid, but it’s just not how I seek to resolve blocks. Am I too stubborn?

Self assessments and toy problems

I am feeling a lot better about these, although there’s always going to be room for improvement.

Following my last post about bombing an assessment, I began wearing earbuds the moment work on the problems began. It’s helped me tune out the frantic typing that always happens, and allowed me to focus on my own thoughts. I wasn’t able to solve according to some of the constraints, but I’ve been happier about forcing myself to take the time to draw and pseudocode before writing any actual code.

Goals for Week 3

• If my partner isn’t technical, make the conscious decision to meet them in the middle
• Continue to think about what it means to be empathetic, e.g. warm, approachable, open - and take action on it
• Take more time to analyze problems
• Go eat dinner even when there’s problems with code
• Prepare a presentation