#pair-programming

I'm officially bilingual.

If I count my Python experience before a/A, I'm already a polyglot. On the other hand, considering that I can now do more with Ruby after two weeks than I ever did with Python, the standards have been raised. (Although I'm sure I could quickly improve my Python on the back of Ruby should the need arise.)

Today's new language, however, was SQL. Static typing, mysterious "databases," unfamiliar syntax. Weird disagreements on pronunciation. (It's pronounced "sequel" at a/A, with the caveat: "When you get hired by a company, get them to say 'SQL' first, so you can follow their convention. Or risk being mocked to forever and back.")

We spent the day working through SQL Zoo, a series of increasingly complicated database queries. The first half was straighforward (I daresay some of it was trivial!), but it got challenging pretty quickly afterwards, and by day's end we were walking around in circles trying to fit two self-joins with two other self-joins to select all bus routes, and the companies that serviced them, that could take us anywhere that was two buses from "Craiglockhart." Or was it "Sighthill"?

An Uber ride would have saved us a lot of trouble.

Earlier in the day, we saw our last of pure Ruby in Assessment 02. It's incredible to think that we're now capable of building a functioning card game (except for the display, a separate problem) within an hour. With a working, reasonably intelligent AI player, no less.

I also finally encountered a pair-programming challenge today, though it was minor. For the first time, it felt like my partner was picking up the day's material significantly quicker than I was. I've been pretty well matched so far, but today, at times, it was difficult to keep up. I've learned it's best to stop my partner and say, "I have no idea what this does or why this works. Can you explain it to me?"

On Day 5, Friday, we built minesweeper with the goal of minimizing dependency between the Game and the Board/Tile classes. Exactly what that meant, however, was left for us to decide.

Since we've only been at the this for a week, "dependency" is, at its clearest, still fairly subjective to us, so deciding (to say nothing of agreeing on) what was and wasn't too much coupling was a challenge. For instance, should individual Tile objects on the minesweeper board have any information about their x- and y-positions on the board? If so, are they being initialized with too much information? If not, do we really iterate over every tile each time we want to find a particular one?

I felt, here, that giving a tile information about its position was perfectly reasonable; my partner did not. We were at an impasse, briefly, but Thursday's lecture on effective pair-programming instructed us to give in to reasonable alternate ideas quickly when working in pairs, and to focus on building those ideas as well as possible. The aim, of course, is to write good code while working in teams (as we will out in the real world), not to become attached to, and insist on, a particular method to solve a given problem. (The Ego and Idea classes shouldn't be coupled too tightly, after all!)

I relented this time, just as I'm sure my partner did at others. It certainly felt like I was making more progress today than on any previous day, just in terms of the volume of code we created and understood, regardless of where the ideas originated---or perhaps because we didn't make that distinction. I think I'm getting the hang of this pair-programming thing. I've also been fortunate (though we've all been warned the day will come) to have not yet been paired with someone who is at a significantly higher or lower level than I am.

Tomorrow, we face Assessment 01. The weekend involved lots and lots of practice. So, fingers crossed. Then uncrossed and typing for all they're worth.

Friday ended early with a break from coding: we split up into assigned groups of 8-10 people, broke the ice, and got to know each other as humans rather than blocks of code for the first time, in what will be a Friday tradition with the same group for the remaining eleven weeks. We shared what we were excited about, what we were terrified about, why we're here. The idea is to support each other through the program; it already feels like quite a rite of passage. (Additionally, homework for next week: a group sign or secret handshake. Never mind the assessment, this is important.)

I’ve wanted to work in a pair programming environment, but it was always difficult to justify the lost initial productivity of two programmers working on the same task. When the tasks are numerous and trivial it makes sense to break them up so they can be solved in parallel. Even when an individual task is difficult, I’ve found that it can be even more challenging for two people to see the same solution to a problem. Sometimes the solution to a problem is straightforward once the problem itself is well defined, explaining the problem to another person or rubber ducky can be helpful in fleshing out those undefined details.  Brainstorming sessions, sanity checks, and intermittent reviews can provide some feedback on the solution and an understanding of the problem. These are great cooperative progress checks to ensure the quality of the final solution without absorbing all of the time of the reviewers in the process.

How to: How to help a struggling newbie do a better job?

How to help a struggling newbie do a better job?

I have been the only developer and the de-facto “senior developer” on my company’s flagship product for a while (a .NET WinForms app, but that is not related). Just recently, they brought in a “newbie” developer with a fresh computer science degree. No experience with source control, unit testing, software maintenance, etc.

I recently assigned him…

Yesterday was my birthday and a lot has happened here at coding house! We have been working on a new project that will help us track our social media duties per day, and the plan is to use the D3 library to visualize our statistics over time. For the first project we were divided into two teams of three people each but for this project all six of us are collaborating.  To prepare us for team collaboration, coding house introduced JIRA, a task manager, and we spent a while figuring out how to divide up the tasks and estimate our time to complete each one.  

To start my birthday off we had yoga in the morning and it felt amazing to get that kind of stretch and strength training in.  Our instructor has a good balance of hybrid exercises and while they never seem impossible, they definitely require dexterity, strength, and endurance.  Especially the portion where we do 60 push-ups split between bridges and planks, whew!

Since we have six people working on this project we decided it would be good to pair program tasks and my partner is Aleks, the guy from Denmark.  We made a lot of progress in the morning but then got stuck on a problem with firebase, a data service we are using for logging in, controlling sessions, and storing our data.  The problem for us occurred when we were trying to load previous data into our variables.  The confusion stemmed from firebase's reliance on event based data-reads.  So, instead of us being able to just say, hey we want data from X table, we have to create a callback function that reads data based when an event occurs.  The curious part was that our program was working, as long as we didn't redirect the user after they submit their information. Long story short, our script was correct, but we were only triggering it when we clicked on the submit button, and the script needs to occur both when the page loads AND when the user submits their information (to detect if there are any changes in the database). The solution was to copy the portion of the script and paste it into the document.ready function.  As much as it was frustrating, I can't be mad because little things happen like this in programming all the time, and it requires patience and logical thinking to overcome seemingly trivial bugs like this.

Halfway through this bug the doorbell rang and it was a special delivery for me from my girlfriend! She had found a really good cupcake bakery near our house and ordered strawberry and cookie butter cupcakes.  They were amazing, I highly recommend cookie butter on anything! We continued to work and finally got to a spot where we were happy, and right after we fixed the bug, dinner was ready! I requested the chef make pad thai as I haven't had thai food since we've been here.  She seemed hesitant at first because she has never made it, but it was amazing! She really outdid herself, including baking me a cake along with cookies and cream ice cream. We all celebrated by devouring the cake and then playing games the rest of the night.  All in all a great birthday, but I can't wait to head back to my apartment in the city on sunday and spend time with my girlfriend.

Today I spent nearly all day working on our first project which is a restaurant ordering app.  We need to get a list of restaurants and their menu items, allow users to select and place an order, and then store the information in localStorage. After that we need to read from the localStorage and somehow render the data.

Initially our instructor said we could just allow users to click a checkbox for an entree item, but we thought it would be more realistic to have a number input field so users could order multiple items.  I was pair programming with one of my group members, and it was a great experience solving problems collaboratively. Then we thought it would be a cool idea to display the total order amount in real time.  This choked us up a little bit as if the input field hadn't been clicked on yet it was NaN! We went through a few different solutions that didn't work, but then found some good documentation on NaN. Turns out NaN has some weird quirks.  For example NaN === NaN would return false! How can something that looks like it should be equal not be equal? Finally we decided to use the method isNan(num) to create an if statement that ignored all empty input fields.  

I was stuck in the middle of how to parse the whole menu table when we needed to leave for a meetup.  It's definitely not fun when you're right in the thick of solving a problem and get interrupted.  Oh well.  I rode with Nick, the Coding House CEO, and we passed by Facebook HQ which was pretty cool.  We headed to the Ninefold Meetup which had the speaker Yehuda Katz, a well-known thought-leader in the programming world, who gave a demo of Thor which is based in Ruby.  Since I haven't studied any Ruby, a lot of the technical demonstration didn't make sense to me due to the syntax, but I was able to follow his logic as he built a quick program that allowed you to see other github user's profiles.  He also built a quick program that converted an image into ASCII, pretty cool. 

After the meetup we headed back here and had our daily circle talk about highs and lows for the day, which ended around 10:30.  We were all pretty tired but Nick encouraged us to get a couple more hours of work done and I'm glad that he did because I returned to my previous problem and was able to figure out a good solution for getting all the relevant data from the user's restaurant order and then I went through a tutorial on localStorage.  It is actually pretty simple, but obviously shouldn't be used that often due to the low amount of memory that can be allocated.  What does seem interesting about localStorage though is the possibility to save form fields.  So, if a user is filling out a really long form with tons of different information and accidentally close their browser or something goes wrong.  If you have a script autosaving their progress every few seconds, you can make it so users can pick up where they left off.  This seems like a cool html5 feature that is subtle, but very effective.  I can't even fathom the amount of times I've hit the back button or accidentally closed out of an order form only to have to re-insert every tiny detail.