Pair-programming.

It’s when two programmers are teamed up to work on the same piece of code. They either split the problems up and work on them individually, later merging the two in some form of version control software, or they sit side-by-side talking the problems out while one types and the other watches for typos.

I’m a fan of pair-programming and I wouldn’t be opposed to working at a place that capitalizes on it. Dick’s Sporting Goods is a major company in Pittsburgh that uses pair-programming exclusively and many students at Tech Elevator hope to join their ranks after graduation. Me included, though I’m open to any situation where I can work with a team and continue to grow as a programmer.

For the last two days, I’ve been paired with Craig, a laid-back former- office worker who plays jazz guitar and once wrote a dissertation on Tom Waits for a final project in college. He’s quiet, friendly, and lightning-quick with a joke or interesting observation. At the beginning of the program, I sat in different spots in the classroom every day. I finally settled next to Craig because we get along so well.

Yesterday, Craig and I wrote a piece of software that translated decimal numbers representing money amounts into the English-word equivalent. It was one of the trickier things either of us had worked on. When we finally got it (clocking in at just under an hour or so) we were jubilant, waving our hands in the air like two excited Muppets.

Today we made a file path to locate an excerpt of Alice in Wonderland. Once we accessed the file, we made a method to count both the words and the sentences. This was much easier than the money translation and we accomplished it even quicker.

Craig is a little better than me at seeing the big picture. During our work together, he often came up with the first pieces of architecture. I have found that I have a natural knack for efficiency, and was able to contribute by following Craig’s lead and refactoring his ideas down to the paths of least resistance.

Tom told us a saying a few days and it went like this: “What one programmer can do in one month, two programmers can do in two months.”

It’s sorta true. If the two programmer’s aren’t on the same wave-length, it’s easy to step on toes and to make each other confused. But Craig and I were able to communicate at a high level these last two days. We were each able to contribute in ways that made our sum skills greater than our individuals.

TDD stands for Test Driven Development. In Test Driven Development, a programmer looks at the specifications he is given and begins by writing tests that his software must later pass. It is backwards from what we’ve learned so far and sort of feels like writing with your left hand.

Here is a classic coding problem called FizzBuzz: Given a number between 1 and 100, return the number as a string (meaning, return it as a word with quotation marks rather than a naked number). If the number is divisible by three, return “Fizz.” If the number is divisible by five, return “Buzz.” If the number is divisible by both three AND five, return “FizzBuzz.” This sounds complicated to a layperson, probably, but most programmers do stuff like this (and much worse, complexity-wise) all day.

To solve this problem normally, I would just start jotting down things I need on a sheet of paper. At this point in my study, I could probably sleuth this one without much sweat (not the case three weeks ago). I would write down some code with some conditional clauses to make sure that all my Fizzes and Buzzes showed up at the right time and then click the “Run Test” link.

But in Test Driven Development, we start with the tests. So, instead of staring at the screen wondering where to start, we write a simple test. The FizzBuzz Method, if given the integer 1 should return “1.” So we make a test that looks like this:

Assert.AreEqual(“1”, testerForFizzBuzz.FizzBuzz(1);

This code is basically saying, if the integer 1 is fed into the method, “1” should be returned. It’s as easy as it gets. We write the code to pass the test and nothing more.

Then we move on to 3. If three gets entered, then we should return “Fizz.” So we go above the place in the code where we returned “1” and write that if the integer is 3, we should return “Fizz.”

And we keep going. Specification by specification and test by test, the code is built.

It’s easy to overwhelm your brain while trying to hit all of the specifications at once. But TDD requires that you break it up into simple, little decisions that are hard to screw up.

I was skeptical during Tom’s lecture, but I really came to enjoy it. I put in a twelve hour day today and drove home with a smile, thinking of Fizzes and Buzzes.

So, you’re going to be in an intensive learning environment for nearly twelve hours a day in five-day spans for fourteen weeks. One question to consider is, what are you going to put in your body? The students at Tech Elevator Pittsburgh have several different answers to this.

Many students at Tech Elevator are aggressively health-conscious. Around the tables at lunch time, salads are popular, along with quinoa, chickpeas, hummus, and one confirmed sighting of bee pollen, sprinkled into Greek yogurt. If you’ve read a few of my blogs, you might predict that I fall into this category. You wouldn’t be wrong. I bring a salad of assorted vegetables, baked chicken and avocado for lunch. I also bring two pieces of fruit, usually an apple and a pear. I also make sure I don’t leave the house without a package of almond bars purchased from Trader Joes. I love these things. I eat them for our fifteen minute break and whenever else I’m hungry. Or whenever I need an excuse to walk away from the computer.

Tech Elevator is on Pittsburgh’s North Side. There aren’t many restaurants, fast food or otherwise, within walking distance. Some people who I think would probably eat out most days don’t have that option. So there is usually an array of tasty leftovers from previous night’s dinners–chicken and rice, cuts of pork, potatoes, and vegetables, cold pasta.

Many opt for the sandwich and chip route. There are a lot of nice-looking salami or ham subs with lettuce, tomato and mayo. I’m always jealous of these people. Salami and american cheese is basically my favorite thing in the world. But I would need a siesta if I ate of one those at noon.

And, few and far between, are the junk food eaters. Now and then a bag of doughnuts will find its way around the classroom. It’s next to impossible to say no to a doughnut when you’re drinking coffee, so I dip my hand in the bag. Sometimes you need to let yourself slide. Sometimes people eat a sleeve of Oreos with a side of nachos for lunch. Whatever. We’re all human here.

There are a few smokers at TE and a few vapers, but caffeine is the drug of choice. There is an impressive assortment of teas in the kitchen and many students partake either as their sole conduit for caffeine or as their fallback after they begin uncomfortably tweaking. But, in my opinion, man cannot live on tea alone. Coffee is king.

The kitchen is always stocked with a massive container of ground beans from Commonplace Coffee. Brandon, a .Net student and former drinker of Maxwell, can’t take a sip without commenting how good it is. He’s right.

Brandon drives all the way from Youngstown to Pittsburgh each morning. He’s one of the hardest workers in class, reportedly clocking twelve to sixteen hours of coding on the weekends. He drinks one cup in the car and then several of the good stuff after arriving. By mid-morning he’s talking like an auctioneer.

Another .Netter, Wade, had been quitting coffee when the cohort started. Wade is a former collegiate baseball player with a deep voice. He’s a quick learner with some coding experience and sometimes likes to stand towards the back of the room while Tom teaches, folding his arms across his chest like a third-base coach. He had been working from home for over a year before starting at the boot camp and his coffee consumption had spiraled out of control.

He reported to us back on the first day that he had cut back, down to a half a cup in the morning. But as the days piled up, he could be seen walking to the brewer, staring at the black pot and shaking his head as he wrestled against the bitter fragrances. I think Wade’s up to two or three cups a day now.

No matter what we put into our bodies, focus is difficult. As the days wear on in the week, it becomes hard to keep the energy levels up. But we’ll keep experimenting, keep trying to make our minds fertile land for the storm of information raining on us.

On this last day of the third week, Tom set time aside for a review day. When he mentioned this, I thought, “Yes. Review. We desperately need a review!” So much has been covered in such a short period of time that I thought we should, perhaps, have a review every Friday. But now I’ve changed my mind.

There were a few things we needed brushing up on–getters and setters, when to use which type of loop, some simple syntax questions. But after about forty-five minutes the flow of queries dripped dry and Tom was looking about the room saying, “That’s it? No more?”

I guess we’re retaining more than we realize.

After a quick break, we switched gears. With the first capstone coming up next week, Tom wanted to cover an example of design architecture. He let us decide what to build and we chose an ATM. To see the impetus of software design was cool. But even cooler was seeing Tom’s brain kick into high gear as he organized his thoughts on the whiteboard.

He made two lists: nouns and verbs. The verbs were things like deposit, withdraw, transfer and the nouns were simple items like account, customer, pin number. The nouns he explained, were prospective classes to be created, and the verbs were methods, waiting to be born out.

He continued sketching and talking for over an hour, fielding suggestions from the room like a nimble ballplayer, catching each one and returning it to the white field of the board in green dry-erase marker. Before long he had four classes, populated with different methods and an interface applied sparingly throughout.

Combined with what I’ve learned thus far, the example from today felt like a corner piece of a puzzle clicking into place. It’s not a clear picture yet, but we’ve got that corner piece taken care of. It’s a good piece to have.

Tom taught unit testing today. You know the cruel tests that the Tech Elevator students are made to run at the end of every exercise which either ignite pure green ecstasy or the red shame of failure? Today I learned how to write them. Today the tables were turned. It was satisfying.

And quite useful.

I arrived in the morning and did some dry reading on the subject. Like, saltine-challenge dry. Honestly, I couldn’t get through it. And I’ve read The Financier, by Theodore Dreiser.

Tom’s lecture was considerably more interesting, but still sort of numbing. People that don’t usually lose focus were nodding their heads like dolls of a lazy puppeteer. I got a little drowsy myself. But things changed when we started the exercises.

First, I was reunited with New York Will. We dived back in to one of the pieces of software that we wrote together, this time to write a series of tests designed to smoke out the bugs. And, crazy enough, it worked. We made a list of things we had created that needed tested in green comments in the IDE. Next, we went about feeding the software problems and the numbers we expected to get back.

Once we figured out the syntax, two different bugs popped up that we were able to fix in seconds. Writing to command line, these same problems had eluded us for two days and would have been infuriatingly mysterious had we managed to sniff them out manually.

Despite the sleepy subject, there is a lot of power in unit testing and I plan to do it a lot going forward, especially on the fast-approaching Capstone project.