What I’ve learned from full-time remote pair programming for a month

For the past month, I’ve been pair programming with a remote partner 8 hours a day, 5 days a week. This is thanks to a new company called Microverse and their Fast Track Program. This program is designed to help aspiring developers gain the skills and experience needed to succeed in remote development positions.

Remote pair programming is a core aspect of the Microverse program. Before I was even accepted into the program, I was paired with another potential student (in my same time zone). We completed a simple two-day project together in order to evaluate how we worked together. Once we were both accepted, we began the program and have been working together eight hours a day, Monday to Friday.

In the past month, I have learned as much or more than I did in the previous six months of studying and building on my own. While the content structure of the Microverse program had certainly contributed to this, most of the credit must be given to the incredible value pair programming adds to the learning experience. Here are some things I’ve learned.

Engagement is paramount.

As I mentioned, I spent several months learning programming and web development prior to beginning the Microverse program. I made progress, but there were days where I didn’t at all. It was easy to get distracted and spend an entire day reading articles about how to learn programming or checking out different programs. I even wasted a lot of time searching and applying for jobs, for which I now fully realize that I was not qualified.

Coding with a partner, whether in person or remotely, provides several advantages in terms of engagement.

• It forces you to remain focused.
• It helps keep you motivated.
• It pushes progress along
• It provides “breaks” where your partner is coding and you are watching/absorbing.

No pair is perfect, and that’s a good thing.

No matter how well you and your coding partner get along, there will be times when you disagree. Maybe you want to work on different things. Maybe you’d rather take a different approach to solving a problem. Or maybe you’re thinking, “if I were driving, we’d be done with this by now.” We’ve all been there, and you should keep in mind that your partner has been there too. Working with a partner teaches us to be patient and humble, realizing that our way is not always the only, or even the best, way.

The great thing is that even at the times when I have been frustrated, pair programming has been better than working alone. The insights and experience gained from working (or patiently watching) through these times has been just as valuable as everything else I’m learning.

I didn’t know Ruby…

as well as I thought I did. One of the main resources we have been using is The Odin Project, for learning Ruby. I had actually (mostly) completed their Ruby course prior to starting the Microverse program, so I thought I knew Ruby and object-oriented programming pretty well. Now that I have gone through the material again, I better understand a lot of things I had skimmed over the first time. When my partner and I got to the first projects, I had a much clearer idea of how to approach them than I did the first time. (By way of example, the OOP section of The Odin Project has students build two command-line games, Tic-tac-toe and Mastermind. I had originally written both without creating any classes — they were not object-oriented at all!)

We’re now working through the projects related to testing. Remember how I said I mostly completed the course before? While I read the material and understood the basics of RSpec the first time, I had become weary with all the projects and did not complete them. Instead, I skipped straight to the Final Project so that I could then move on to learning Rails. Working with a partner this time makes it much less daunting (plus the program requires us to finish it, which always helps).

The main takeaway from this is that working with a partner will sharpen your knowledge of the things you think you know.

Data structures and recursion.

For the last two weeks, we’ve spent about an hour each morning learning about data structures on Learneroo. I remember covering the basic data structures before, and even building breadth-first and depth-first search functions for binary trees. I didn’t truly understand them, though, until my partner and I went through them together. We still have quite a bit to learn, but doing it together helps us both process our thoughts and build on each other’s understanding, so that we comprehend more than either of us would if we studied these things on our own. Recursion, in particular, makes sense to me now in a way that it never did before, and I’m almost even excited to learn more about data structures. Almost.

JavaScript isn’t quite this bad.

JavaScript isn’t all that terrible.

My coding partner has a lot more experience with JavaScript than I do (a month ago, mine was primarily from CodeCademy’s Introduction to JavaScript course). By working with him, and watching him code, I’ve gained a much better grasp of the language and how and when to use it. Before, it was just another language that’s a lot uglier than Ruby, but now I really understand its value. This is an example of another great thing about pair programming: you get to learn from your partner’s strengths while they learn from yours. Where you are stronger, you get to teach and solidify your knowledge; where your partner is stronger, you get to learn from her. Everyone wins all the time.

Building webpages takes practice.

And a ton of patience with CSS. In the afternoons, one thing we have been working on is building projects to add to our portfolios. The first of these have responsive web pages. While “learning” HTML and CSS is relatively easy, putting them together to make a website, or even a page, that looks great on a variety of screen sizes takes some effort. It’s the kind of task that can seem too big, but not when you have a coding partner! Together, we have learned to use media queries, debated the merits of Bootstrap vs a DIY approach, and chosen to ignore jQuery in favor of plain JavaScript.

If you need inspiration or something to build, check out dribbble. It’s a site where designers post concepts, AKA sites that have not been built and probably never will — unless you do it. It’s great to be able to show a potential employer that you can take a website concept and build it, because if you get hired as a web developer that’s what you will most likely be doing.

Contributing to open source makes you want to fix every error on the internet.

Contributing to open source projects is intimidating at first, and I never made any contributions until I began pair programming as part of the Microverse program. Since then, however, my partner and I have made several contributions to a few different projects. It’s a bit addictive, to the point that every mistake we find on a website, we ask “Can we submit a pull request to fix this?” Most of the time we can’t, because it’s an article on someone’s blog or otherwise not open source. It’s still cool to have that mindset of wanting to make the things we use better, though.

Freelancing when you’re an aspiring developer

Freelancing is difficult for new developers to get into.

In our first two weeks of the Fast Track program, we applied for several freelance jobs, because part of the focus of the program is getting real-world experience. We didn’t have any success, however, and are now focusing on creating projects to add to our portfolios, as mentioned above.

The one time we did get a response on a submission, we mentioned that we were pair programming, and the client said that it gave him pause. That’s unfortunate, since as you can tell by now, pair programming is actually a huge advantage.

I have enjoyed my first month of full-time remote pair programming. More importantly, I have been learning more than I would have on my own. Having a partner is a great help when learning anything, and I thoroughly recommend it to anyone learning software development.