As developers, we refer to the tools we use as 'programming languages,' but we don't always think of learning to code as a form of language learning. There are of course differences between natural languages and programming languages, but humans have been learning natural languages for hundreds of thousands of years longer than we've been learning programming languages, and there are lots of insights we can glean from the field of second language acquisition.

Below I'll outline three concepts from the field of Second Language Acquisition and how they can be applied to learning to code - computer language acquisition, if you will. Some terms I'll be using throughout this article:

• Second Language Acquisition (SLA) - a sub-discipline of applied linguistics that studies the process by which language learners acquire any language other than their native language(s)
• natural language - a spoken or signed language that has evolved naturally through usage in human communication (e.g. English, Japanese, Arabic)
• programming language - a system of notation used by programmers to develop computer programs (e.g. Python, Javascript, Java)

Comprehensible input

Comprehensible input in the field of SLA refers to language input that is just slightly above the level of the learner. Language input generally refers to receptive skills like listening or reading, whereas language output refers to productive skills like speaking or writing.

According to Stephen Krashen, comprehensible input is "the only true cause of second language acquisition" (64). It's often represented as i + 1 (or i++ for all you programmers), where i is the learner's current level. To further translate that into programming speak,

for (let i = 0; i <= fullProficiency; i++) {
    const comprehensibleInput = i + 1
    practiceLanguage(comprehensibleInput)
}

Generally, the idea is that learners should encounter language beyond what they have already learned so as to challenge them, but not so far beyond what they've learned as to completely discourage them.

Comprehensible input applied to coding

Gaining exposure to code just slightly above your comprehension ability will help you to expand the limits of your knowledge. There are a few places we can look to find comprehensible inputs in programming. Documentation, courses, and tutorials can all serve as excellent sources of comprehensible input.

For those that are already familiar with at least one programming language, a less obvious source of comprehensible input that I really love to use is code review! If you work with any team members that use different programming languages than you, have any friends that do, or even know of any open source projects that do, I encourage you to do your best to review their code. You won't understand everything, and might not be able to provide high-value feedback at first, but if you already have context around the project they're working on, that's a great starting point to build from. Depending on the context, you might even be able to ask questions to learn more about the code they wrote.

Making mistakes is a critical skill

One of the biggest hurdles for most adult language learners is getting over the fear of failure or of being wrong. This limitation delays many adult language learners from progressing at the rate of many juvenile language learners. This is because many adult learners are so debilitated by a fear of using language incorrectly that they barely use the language at all.

It has been suggested that inhibition discourages risk-taking, which is necessary for progress in language learning. (Lightbrown and Spada, 61)

Counterintuitively, getting comfortable with making mistakes is one of the best ways to make progress as a language learner. Focusing on the goal of communicating instead of on the goal of producing grammatically perfect sentences allows a learner to gain practice using new vocabulary, which will help them better remember it; and using new grammar structures, which will help them gain intuition for when and how to use them.

Sometimes language acquisition is reflected in a decrease in the use of a correct form that was based on rote memorization or chunk learning. New errors may be based on an emerging ability to extend a particular grammatical form beyond the specific items with which it was first learned. In this sense, an increase in error may be an indication of progress. (Lightbrown and Spada, 77)

I love this idea that mistakes can be a sign of progress, and think it can be a very helpful reminder for folks who get discouraged when they make mistakes.

Making mistakes applied to coding

It's important not to be so afraid of making mistakes as to never write any code in the first place. Try not to be afraid of a blank page - start with a 'Hello World,' add some complexity, and correct when necessary.

Making mistakes will be a natural part of the process of applying new knowledge, and it's important not to get discouraged when mistakes occur. Instead, see mistakes as an essential part of the process of gaining proficiency and an opportunity to learn. Get comfortable with reading error messages, debugging code, and asking for help. These are some of the most important skills for leveling up as a developer.

Scaffolding

As you might expect, one of the fastest and most effective ways of learning a language is to actually use that language. Using language productively to create meaning is infinitely better practice than simply reading or listening to someone else use language.

In the field of education, scaffolding refers to the strategy of gradually progressing students toward increased independence in the learning process. In a language classroom, this could look like:

1. The teacher introduces a new grammar concept to the class
2. Students read a short passage and identify all instances of the new grammar structure
3. Students then complete an exercise where they complete sentences by filling in the blank with a verb conjugated using the new grammar structure
4. Students think of and write three sentences using the new grammar structure
5. Students converse with a partner using a prompt designed to elicit the new grammar structure naturally

In this process, students begin with lots of support (or scaffolding) from the teacher, but as they gain familiarity with a concept, they are able to demonstrate more and more independence until they are finally able to use the new concept independently and could even use the new concept outside the classroom. Working toward productive language use is generally always the goal in a natural language classroom because it is the most effective way for learners to internalize information about a language.

Scaffolding applied to coding

Similarly, reading coding tutorials is a great way to start learning a new coding concept, but we should work to scaffold our learning with the ultimate goal of writing code and working on real life projects. In the context of learning to code, scaffolding could look like:

1. Reading documentation about a programming concept
2. Watching a course on the new concept and perhaps completing small challenges if they exist in the course
3. Following along with a tutorial using the programming concept
4. Working independently (i.e. not through a tutorial) on a project applying the programming concept

If you're feeling overwhelmed while learning something new, a great way to set yourself up for success is to first think about how you ultimately want to apply your knowledge, then work backwards to build up some scaffolding for yourself.

TL;DR - How can I be a more effective (computer) language learner?

1. Start with input that is just slightly beyond your current level.
2. Embrace mistakes as part of the process.
3. Give yourself support as needed, but make it a goal to work towards independently developing projects.

Works Cited

Brown, H. Douglas. Principles of Language Learning and Teaching: A Course in Second Language Acquisition. Pearson Education, 2007.

Krashen, Stephen. “Immersion: Why It Works and What It Has Taught Us.” Language and Society, 1984, p. 64.

Lightbown, Patsy M, and Nina Spada. How Languages Are Learned. Oxford University Press, 2006.

Our team of four software developers met weekly with our mentors as we worked to develop a smart shopping app. Our mentors, experienced software engineering professionals, led learning modules on topics like code review, pair programming, communication for developers, and accessibility. During the week, we would pair program to meet the acceptance criteria on GitHub issues for our project, submit PRs, and provide code reviews to our teammates. In our weekly meetings, we shared demos of our feature work, and participated in retrospectives with the team.

Through it all, I learned so much about how to be a good software engineering team member. Here are some of my biggest takeaways:

Write clear documentation

Especially as an early-career developer, it can be tempting to try to make your skills look more impressive by adding complexity for the sake of complexity. This is completely the wrong instinct. Your priority should be on making your code easy to understand.

How can you do this? Write clean code, but also write clear documentation! Before my experience with The Collab Lab, I always thought of documentation as just MDN, and the official documentation of widely used libraries and frameworks. That’s just the tip of the iceberg! Documentation also encompasses everything from descriptive PRs and commit messages to thoughtful comments in your code. As a developer, basically anything you write for people instead of computers is documentation. Make sure you’re writing it to be as helpful as possible.

Descriptive PRs and commit messages

One thing I really loved was that Collab Lab created a template for us to use when creating pull requests. All of our PRs included a description of the change, a list of the acceptance criteria, a checklist of the types of changes made, before and after screenshots or screen recordings of our app, and the testing steps/QA criteria. While this meant that we had to spend a little extra time creating the PRs, the benefit was twofold: 1) the process of creating the PR could help us catch errors before sending the code to be reviewed and 2) code review was so much easier when everyone had a clear understanding of what had been changed and why.

Similarly, writing meaningful commit messages makes code review much easier on your team, and it also makes it easier down the line for yourself and others to understand why changes have been made.

Thoughtful comments in your code

I had been under the impression that code comments were a mark of weakness, and to be avoided at all costs. That is, until one of our mentors, Luis, shared this fantastic video from Sarah Drasner on “The Art of Comments,” that was an eye-opener for me.

While commented-out code (or as Sarah refers to it, “hoarders, but for code” 💀) can certainly clutter up your files, intentional and considered comments can improve the quality of your code.

If you have an unintuitive solution to a tricky bug, it could be helpful to leave a comment explaining why it’s necessary. If you found a solution on Stack Overflow, it could be helpful to leave a comment with a link to the page.

Inclusion necessitates accessibility

One of my favorite things about The Collab Lab was the emphasis on accessibility. The apps we built were expected to be accessible, one of our learning modules was dedicated to accessibility, and throughout the spring cohort we were sent a wealth of accessibility resources and articles through Slack.

To me, an emphasis on accessibility is a natural extension of Collab Lab’s mission:

The Collab Lab increases access to web development jobs for early-career developers and, in particular, people in under-represented groups in tech by providing experiential skills training in software team collaboration and career management.

A mission that prioritizes bringing opportunity to under-represented groups in tech speaks to a desire for a more inclusive tech world. One facet of this is of course bringing more diversity to the teams developing technology. Another is to ensure that the tech we are building is built for everyone, which means making it accessible.

If you’re interested in learning more about accessibility, I’d recommend starting with this article written by the former head of accessibility at the BBC, or the A11y Project (a11y is a numeronym for accessibility, if you haven’t come across that term before).

I learned so much and am so grateful for my time at The Collab Lab, and highly encourage fellow early-career developers to apply! Tomorrow is the deadline for the summer 2021 cohort, and if you’re reading this after June 19, 2021 you can follow the Collab Lab on Twitter to find out about upcoming cohorts!

View the job interview process primarily as a learning experience, and secondarily as an opportunity to get a job.

This is of course much easier said than done, and not everyone has the luxury of approaching the job hunt this way; but in my experience the more I was able to make this mindset shift, the happier and more successful I was in my job hunt.

Why should you try to make this mindset shift?

1. Mental/emotional well-being

Job hunting is extremely stressful and emotionally draining. There is so much pressure to get a job, that it is difficult not to take rejection personally. On top of this, the outcome of a job interview is ultimately out of your hands, and the lack of autonomy can be extremely anxiety-inducing.

By making it the primary objective of your job interview to learn something, you are reclaiming autonomy and putting yourself back in control of your own success.

2. Success in the job hunt

Ironically, in slightly de-prioritizing the hiring outcome of a job interview, you can also make yourself more appealing to employers.

When employers hire junior developers, if they know what they’re doing, they’re not looking for the candidate with the most technical skills. If that’s what they wanted, they would be hiring for a more senior position. Instead, they are looking for a candidate with the most capacity to learn technical skills. If you make learning your priority (and if you are able to effectively demonstrate this to the employer), you will make yourself a very attractive candidate for the position.

How can you begin to make this mindset shift?

1. Look for opportunities to learn new ideas and technologies

A great way to do this is to look at the company’s tech stack and try to learn more about the technologies they use, especially if you are unfamiliar with those technologies. If they have a tech blog, read it and discuss it in your interview! If you’re working on a take-home assignment, try to incorporate part of their tech stack. If you’re doing a code review, talk about how you might refactor to utilize a technology they use on the team. If an interviewer mentions a term or technology you’re unfamiliar with, read up on it after your interview and mention what you learned in your follow-up/thank you email.

It might not be realistic to learn a new framework or language for every job you apply to, but demonstrating a passion for learning will go far in a job interview, and hopefully it will also make the process more fun or interesting for you.

Of course the hope is that you’ll be able to impress the hiring manager with your newfound skills and demonstrated ability to learn, but even if you don’t get the job you’ll have a new skill to put on your resume or a new concept you can talk about in future interviews!

2. Ask questions that demonstrate your curiosity and desire to learn

I was a hiring manager in my previous (non-tech) career, and I noticed that something a lot of entry-level job applicants forget is that a job interview really should be a two-way conversation. Don’t be afraid to ask questions! In my experience, the more I remember this, the less scary job interviews are. Not only this, but an interesting conversation will be a lot more enjoyable for the hiring manager and you’ll leave a much better impression on them. Job interviews can be stressful and/or draining for hiring managers too, and they’ll really appreciate an engaging conversation.

As a junior developer, in the interview process you will almost certainly be speaking with developers who are much more experienced than you are. Take advantage of this! There is so much you can learn from them — about the company’s tech stack, about their personal career path, and about the tech industry in general. Even if a job offer doesn’t come out of the interview, you could be making a connection that will help you in the future.

I hope this tiny hack helps you the way that it helped me, and I wish you the best of luck in the job hunt!

Getting Started

Since we wanted our website up and running as soon as possible, and since I was splitting my attention between building the website and planning a wedding, I decided to start with a Gatsby starter. There aren’t any Gatsby starters specifically intended to be used as wedding websites, so while browsing the Gatsby starter library, I was looking for a starter that was minimal enough to allow me room for customization. Before starting, I knew the primary function of our website would be to direct our virtual guests to the livestream of our ceremony. We also wanted space to share details about the big day and stories about our relationship. We were also considering adopting the website after the ceremony to share wedding pictures with friends and family.

The original Gatsby starter

I ultimately chose the startbootstrap-agency starter from Thundermiracle. This starter was designed to be a business landing page, but I liked that it had a clean design that would look good in both mobile and desktop views; it had a call to action button that I could use to direct our virtual guests to the livestream, and the “portfolio” section looked like something I could adapt to display our wedding photos. As a bonus, the “about” section featured a timeline that I could use to share details of our relationship.

Adding Functionality

Upon selecting a starter, I first set to work reorganizing and deleting unnecessary sections and updating images and content within the preexisting framework. I also updated theme colors and fonts to match our aesthetic. In order to have a minimally viable product, I added a message at the top of the page, as well as a link to our livestream.

The MVP wedding website

Once I had a minimally viable product, I began building out additional features for the site. First, I added a countdown feature to the site. This was both a feature to build anticipation of the event, and a way to customize the display depending on when the user was accessing it. By using a countdown feature, which I implemented using the react-countdown library, I was able to build multiple versions of the page: one version for our page’s visitors in the days and weeks leading up to the event, another version for visitors on the day of the ceremony.

Using React Libraries to Optimize User Experience

Some of the additional features: copy-to-clipboard and add-to-calendar

After looking over the page I had built, my husband and I came up with some additional features that would make the page more useful for our guests. He had the great idea of adding an “add to calendar” button at the top of our page, to help our virtual guests remember to log on for the livestream. To do this, I utilized the react-add-to-calendar library, and customized the display to blend in with the rest of our page. I also reused the react countdown library so that I could display the add-to-calendar button leading up to the ceremony, but hide it once the day had arrived, as its functionality would no longer be useful at that time. On the day of the ceremony, the “add to calendar” button would be replaced by a “watch the ceremony” button.

Like any good millennial couple, we also had a wedding hashtag for our virtual guests to use if posting to social media. I turned all references to this hashtag into a clickable button that would copy the text to the user’s clipboard. To do this, I utilized the react copy-to-clipboard library, as well as the react toast-notifications library for an aesthetically pleasing way to alert the user to the action taken.

Challenges

What surprised me about this project was that the most challenging part of coding it was not adding new features, but rather tweaking existing ones. As a Gatsby starter, the code was written to allow for some superficial customization very easily. The text and images displayed on the page were intended to be replaced, so it was easy to find where to edit this information in the code.

The rest of the code was not written to be easy to navigate, but rather to allow a user to easily make those superficial changes, and have those changes automatically permeate throughout the code. I wanted to write user-friendly code that could potentially be used by others looking to make a similar wedding website, which ruled out the option of hard-coding my adjustments as a workaround to integrating them deeper into the code.

Some features that I anticipated being difficult to implement, like the countdown feature and time-sensitive displays, came down to a matter of carefully reading the documentation for various React libraries.

Other features that seemed much simpler in theory, like turning images into links in the “giving” section, were much more difficult. Because this change required making adjustments to existing code, I needed a comprehensive understanding of how that code worked. I realized in the process that the codebase relied often on mapping through arrays and passing props through many generations. Keeping a clear mental image of the data flow was difficult but crucial for making these deceptively simple tweaks to the website.

Next Steps

Now that the wedding ceremony has happened, the purpose of our wedding website has shifted slightly. Instead of directing our friends and family to the livestream of the ceremony, it will be a place to share photos, videos, and highlights from our wedding. I will add a gallery and/or carousel to highlight wedding photographs.

I will also be further cleaning up the code in order to make it as user-friendly as possible for future users who might want to use it as a template for their own wedding websites. Stay tuned for the final product!

• Wedding website code

• Gatsby starter

This article was originally published as part of the Building Couch Potato blog series.

Working on Couch Potato was a huge learning opportunity for our team. It was one of our first times developing a project from scratch, without any kind of starting template. To face such a daunting challenge and be able to create a product we can stand behind and use regularly was extremely rewarding and empowering.

Successes

Overall, the single feature we are proudest of is the synchronized play/pause across Couch Potato users. As Grace mentioned in her comparison of Couch Potato to Hulu Watch Party, even Hulu’s official social distance viewing solution does not include this feature. This feature undoubtedly took us the most time to work out, but it is also the one that brings the most value to our extension. It’s what gives our extension an edge when compared to the other messaging systems on the market while streaming video with friends.

In addition to the technical challenges we overcame, we also consider it a huge success to have our product deployed, and being used by real people. As of today, there are 110 users of our extension.

On a personal note, I’ve also found it extremely rewarding to have helped develop a tool that I actually use regularly. Since shelter-in-place measures have gone into effect, my family has had weekly virtual dinner and movie nights. Whenever we watch content on Hulu, Couch Potato is the tool that we use to make this possible.

Possible Improvements

While we are extremely proud of our product and the work we put into it, we can also learn a lot by reflecting critically on the process and decisions we made along the way.

One decision we made early on was to create a web app that allowed users to chat in private rooms (or “couches”), then to create an extension that loaded that web app into the user’s browser window through an iframe. We took this approach because it allowed us to break down a huge challenge into more manageable pieces. We would start by creating a web app (something we had experience doing), then incorporate socket.io (a new-to-us technology) to allow for real-time chat, then finally bundle it into a Chrome extension (another new-to-us technology) via an iframe.

If we were to refactor our extension, we would consider doing so in a way so that Couch Potato would load directly onto the user’s browser, rather than through an iFrame. This could remove a layer of complexity from the process and optimize our extension for speed.

As we have not faced any issues with the speed of our extension, and since we have a relatively small user base for now, we have not yet seen a need to refactor Couch Potato. For now, we’re watching the comments on the Chrome extensions page to hear feedback from our users.

Future Features

In the future, if we decide to revisit Couch Potato, one of our first orders of business will be to add support for additional video streaming services, such as Netflix, Amazon Prime, or Disney+. This is the feature that would most benefit our users, as it would drastically increase the amount of content they could access while using Couch Potato. In order to implement this feature, we will have to familiarize ourselves with these video streaming platforms in order to be able to manipulate the DOM effectively.

One of our favorite features of Couch Potato is the drinking game button, as it brings a more social element to watching movies and TV remotely with friends. In the future, we would consider additional features that seek to bridge the distance between our users and further incorporate social interaction into the viewing experience. For example, while we currently allow users to react with emoji in the chat window, we would consider making these emoji reactions more dynamic by making them float across the screen. We could also add a “popcorn button” that simulates throwing popcorn at the screen (which users could do, for example, when the horror movie protagonists decide to split up, or when the rom-com lead’s ex tries to start drama).

Have you tried Couch Potato? What do you like about it, and what would you like us to improve? Leave a comment below!

This is the last installment of our blog series, for now at least. We’ve loved having the opportunity to reflect on this project with you, and hope you’ve enjoyed following along. If you’ve missed any blog posts, you can find them all here.

If you’d like to keep up with us around the web, here’s where you can find us:

Dani Meyer

Medium | Github | LinkedIn | Twitter

Caitlin Floyd

Medium | Github | LinkedIn | Twitter

June Hwang

Medium | Github | LinkedIn | Twitter

Grace Murray

Medium | Github | LinkedIn | Twitter

Interested in learning more about Couch Potato? Start this blog series from the beginning! And don’t forget to download Couch Potato from the Chrome store so you can start watching shows with friends now!

Before getting started, make sure you have optimized your GitHub profile as it currently exists. Edit your profile to include a brief bio, and some additional information such as your city and a relevant link (such as your LinkedIn profile). Add a professional profile picture if you’re so inclined. By default, GitHub will display six recent or popular repos on your profile. Highlight projects you’re proud of by pinning up to six of them to be displayed instead.

GitHub recently unveiled a new feature that allows users to highlight a readme file at the top of their profile. To enable this feature, simply create a repository with the same name (and casing) as your GitHub username. Be sure to also initialize the repo with a readme.

When you edit the readme file, GitHub provides suggestions of the types of information you may want to include. In addition to these suggested insights (such as what you’re working on, what you’re learning, your pronouns), you may want to include information about what languages or frameworks you’re familiar with, your non-coding interests, or information about your background and education.

If you want to finish here, you’ll have turned your GitHub profile into a portfolio in as little as 5–10 minutes!

Because this highlighted file is a markdown file, and it supports HTML tags, there is also a lot of additional room for creativity. Think of ways to make information more visual, with images or tables. (Canva is a great resource for easily creating images.) Include any links you think are relevant, such as links to social media accounts or to live projects. While videos can’t be embedded into a markdown file (you’ll have to externally link them instead), gifs can. Consider recording a short video of your project to convert into a gif that can be displayed on your profile.

With this new ability to personalize your profile, you are only limited by your own creativity. If you need inspiration, consider browsing Twitter to see what others have shared.

Feel free to check out my GitHub profile for ideas!

Have you taken advantage of this new GitHub feature? Leave a comment with a link to your profile — I would love to check it out!

This article was originally published as part of the Building Couch Potato blog series.

In our last post, we outlined our process for collecting feedback from users of our Chrome extension, Couch Potato. How did we then incorporate this feedback into our product?

Based on the feedback from our users, we identified a few areas for potential improvement. First of all, while some users found our extension to be intuitive to use, others were less confident and felt they could have benefitted from more explicit instructions. While reviewing this feedback, we realized there were actually two separate problems being described. Some users were unfamiliar with Chrome extensions in general, and others were confused by our specific Chrome extension. During the feedback process, we also noticed that some parts of the user experience were not as seamless as we would have hoped, so we made it our goal to remove any inconveniences we could for the user in order to make their experience as pleasant as possible.

Once we had identified these problems, we began brainstorming how to solve them. For users who were unfamiliar with Chrome extensions, we decided to utilize a Chrome popup notification that would instruct users on how to initialize the extension whenever they were on a supported domain. This had the added benefit of reminding all users that they were on a supported domain and could use Couch Potato.

Chrome notification

For users who needed further instruction on how to use Couch Potato after initializing it, we wanted to add instructions to our homepage without adding clutter for users who didn’t need instructions. To accomplish this goal, we added a React component that would only display detailed instructions if the user required them.

Instructions in a React component

In order to selectively display components on our homepage, we added indicators to the state that would dictate whether or not the component should be displayed. When the user clicked on a button, it would change the corresponding state, thus triggering a rerender of the page. Clicking the button again would reverse this state change and again rerender the page.

export default class HomePage extends Component {
  constructor() {
    super();
    this.state = {
      showJoin: false,
      showStart: false,
      showInstructions: false,
      showHelpButton: true
    };
    this.toggleJoinPopup = this.toggleJoinPopup.bind(this);
    this.toggleStartPopup = this.toggleStartPopup.bind(this);
    this.toggleInstructions = this.toggleInstructions.bind(this);
  }

  toggleJoinPopup() {
    this.setState({
      showStart: false,
      showJoin: !this.state.showJoin
    });
  }

  toggleStartPopup() {
    this.setState({
      showJoin: false,
      showStart: !this.state.showStart
    });
  }

  toggleInstructions() {
    this.setState({
      showInstructions: !this.state.showInstructions
    });
  }

A portion of our code that allowed us to selectively display components on the home page

In order to further streamline the user experience, we wanted to make it easier for users to share their couch ID with their friends. To do this, we utilized two React libraries; react-copy-to-clipboard, and react-notify-toast. React-copy-to-clipboard allowed us to turn the user’s couch ID into a clickable link that would automatically copy their couch ID to their clipboard. To make sure the user knew this action had been successful, we utilized a toast notification confirming that the ID had been copied.

React-copy-to-clipboard and react-notify-toast in action

Beta testing and collecting user feedback was an essential part of our process. It forced us to take a step back from our code and center the user. Not only were we able to respond directly to user feedback, but we were also empowered to think creatively of further features our users might enjoy. Stay tuned for our next post when we will dive into some of these additional features.

Interested in learning more about Couch Potato? Start this blog series from the beginning! And don’t forget to download Couch Potato from the Chrome store so you can start watching shows with friends now!

This article was originally published as part of the Building Couch Potato blog series.

So far in this blog series, we have detailed the technical challenges we faced in creating Couch Potato, the Chrome Extension we developed allowing users to stream video content together remotely. We wanted to pause now to address the physical challenge we faced in unexpectedly having to develop our project remotely.

Our team (and the rest of our cohort) had signed up for a 13-week in-person coding bootcamp. At the end of the eighth week, we were told that we would temporarily be going remote in response to public health concerns. Ultimately we were forced to complete the remainder of our course remotely, which meant that the entirety of our Couch Potato project was also done remotely.

When collaborating with other software engineers, team members’ communication and collaboration skills can be just as important as their software engineering abilities. As much of the world has discovered while working from home this year, these skills become even more essential when working remotely. When we began our project, before anything else — before even discussing the content we wanted to develop — we discussed our individual expectations and set our team routines.

We decided to err on the side of over-communicating to make sure everyone was on the same page and no one was going rogue or getting left behind. We would have stand-up meetings first thing in the morning to confirm what everyone had been working on, what challenges they were facing, and what they planned to work on that day. We also checked in with one another after lunch to make sure everything was progressing as anticipated. At the end of the day, we would regroup to review our code changes, push the code to the main branch of our repository, handle merge conflicts, and have a “pull party” to ensure that every member of our team was working with the most up-to-date code.

Another decision we needed to make as a team was the extent to which we wanted to pair program. We came to the decision that while we wanted to develop an awesome product, our top priority was learning from this project. This led us to decide to pair program for as much of our project as we possibly could, and to even mob-code as a group for earlier portions of our project. While this meant sacrificing some of the efficiency that might have been gained from coding independently, it also meant that every member of our team was able to contribute more holistically to our project, feel more of a sense of ownership over the project, and understand the different nuances of our code.

An important skill for software engineers is knowing the proper tools to use for a given situation. We came to rely very heavily on video conferencing and instant messaging platforms to communicate with one another throughout the day. Screen sharing was also extremely valuable for long-distance pair programming. This might be an unpopular opinion, but I think making the choice to turn on our cameras for our calls made a huge difference in our group dynamic and the effectiveness of our collaboration. In our stand up meetings and when pair programming, we almost always had our cameras on. I think this small detail made our team feel more familiar, and made us more willing to request and offer help to one another.

While collaborating remotely was certainly an unanticipated challenge for us, ultimately it proved to be an excellent learning experience. We experienced firsthand the importance of many of the coding habits we had been building. Writing clean code, proactively communicating with one’s team, and knowing how to look for information were essential skills for us as a remote team, but they are also crucial habits that we developed and will be able to rely on throughout our careers as software engineers.

Stay tuned next week as we address some of our UX challenges and how we addressed them!

Interested in learning more about Couch Potato? Start this blog series from the beginning! And don’t forget to download Couch Potato from the Chrome store so you can start watching shows with friends now!

This article was originally published as part of the Building Couch Potato blog series.

After working through the challenges of converting our code to React, we were eager to incorporate all the additional functionality that React allowed.

To begin, we created React components to allow users to start or join “couches” (chat rooms) upon launching the extension. Utilizing React components for this purpose allowed for more modular and cleaner code. Notably, it also allowed users to navigate to their target couch through a single page application-style div element. By avoiding the need to navigate through separate pages in this way, we prevented any unnecessary interruptions to the user’s web player.

We designed our “home page” component to include basic instructions for users and options to either start or join a couch. Depending on which option the user selected, their state would change and trigger a re-render of the page, displaying either a “join” or “start” component with the appropriate user input fields. Users that selected to start a couch would be asked for their name, and to select an avatar before creating a couch. Users that had chosen to join a couch would be asked for the ID number of the couch they were joining, as well as their name and an avatar.

For the dual purposes of preventing backend errors and improving user interface, we added several layers of form validation. Users would not be able to submit the form unless all text fields were completed. (If no avatar was selected, a default option would be assigned.) If the user was asked for a couch ID number, only a numerical input with the expected number of digits would be accepted. Unless all these criteria were met, the submit button would be disabled, and a warning message would display over the relevant input fields to alert the user of the issue.

Upon submitting their information, all users would be redirected to a final “chat” component with the appropriate couch ID number (either the one provided by the user choosing to join an existing couch, or a randomly generated ID for the user creating a new couch).

At this stage, we were not yet ready to incorporate additional React libraries into our code, but had already begun identifying which of our planned features could be implemented with the use of React libraries. For example, we knew that we would eventually want to allow users to use emoji in the chat or to edit their user information, and we felt React would likely be useful in addressing these issues. Stay tuned to hear how our journey continued, and how we utilized some of these React libraries to solve problems we encountered.

Interested in learning more about Couch Potato? Start this blog series from the beginning! And don’t forget to download Couch Potato from the Chrome store so you can start watching shows with friends now!

This article was originally published as part of the Building Couch Potato blog series.

So you’ve decided to create a piece of technology that lets people watch shows together from the comfort of their own homes and chat while doing so. Where do you start? That’s the daunting question we faced when deciding to create Couch Potato for our bootcamp’s Capstone project.

Once we had a clear vision of what we wanted our product to be, we knew pretty immediately that we would be most effective with a Chrome extension, since this would allow us to overlay the chat next to the user’s streaming content and also pull information about the user’s streaming activity. With some cursory research, it also became clear that if we wanted to incorporate real-time chat features, socket.io was the way to go.

Since we didn’t have experience with either socket.io or Chrome extensions, we decided to tackle the technologies one at a time and begin by creating a web app that incorporated socket.io. Before we could do any coding on our project, we needed to research, watch tutorials, and read articles about socket.io. In addition to reading the official socket.io documentation, we also came across the below video and corresponding repo which helped us to understand some of the mechanics of socket.io.

Once we familiarized ourselves with socket.io, our first step was to create a very basic chat room. Putting fingers to the keyboard for the first time was a little intimidating for me; up until that point I had almost always worked with some sort of starter code, so facing a blank .js file was a little overwhelming. Having literally anything on the screen is a lot less scary, so if you’re feeling the same way, just get started and worry about debugging later! The initial iteration of our chat room came together relatively easily, but as you’ll hear in a future post, we definitely came back to it a lot more to add features. We knew that we eventually wanted users to be able to create private chat rooms to use with their friends, but initially, we wanted to create one universal chat room, which would allow us to have a starting point that could be incorporated into our Chrome extension.

To begin developing a Chrome extension, another new-to-us technology, we started by following the tutorial in the Chrome documentation. The documentation was extremely easy to follow, and in less than twenty minutes, we had each created the basic extension outlined in the tutorial. The extension allowed us to change the background color of any website, and it was really fun to be able to implement it so quickly.

Incorporating our chat functionality into our Chrome extension was a little more daunting, but we did come across a video (below) and repo on using socket.io within a Chrome extension. There were some key differences between the chat extension from the demo and the chat feature we were building, but it was a very helpful starting point.

After watching and discussing the video and examining the source code, we needed to consider: 1) how to auto-generate new rooms for users, rather than requiring them to create new rooms themselves; 2) how to keep rooms private from other users; 3) how to “garbage collect” old rooms that were no longer being used; and 4) how to embed the chat window into the browser window rather than existing as a pop-up.

Stay tuned to continue following our journey towards building Couch Potato! In our next post, we’ll take a deeper dive into our chat room and the process of converting it into React.

Interested in learning more about Couch Potato? Start this blog series from the beginning! And don’t forget to download Couch Potato from the Chrome store so you can start watching shows with friends now!

Part of what initially drew me to become a software engineer was the immense problem-solving capacity of the industry, and that quality has been on full display these last few months. I’ve been so inspired by solutions I’ve seen developed by the tech world — everything from resources to connect volunteers with the elderly and immunocompromised in need of groceries and supplies, to tools allowing for social connection in a time of physical distancing.

One of the most rewarding parts of my bootcamp experience was working to develop my capstone project with a team of three other software engineers. When we began our project, we had just recently transitioned from in-person to remote classes in response to the pandemic. Already beginning to feel the effects of isolating ourselves from friends and family, we wanted to create a tool to connect people from the safety of their homes. We developed Couch Potato, a Chrome extension allowing multiple users to watch Hulu together remotely.

Since wrapping up with bootcamp several weeks ago, my family and I have had weekly movie nights from our respective homes by using Couch Potato. It’s been so rewarding to see the tangible results of a solution I helped engineer. While I realize it might have been a small problem we were solving, in the scheme of everything happening in the world right now, it was nonetheless a motivating and eye-opening experience. I can’t wait to continue to use my software engineering skills to create good in the world.