and the only way you can get it.
The best software is written by teams of programmers working together on a single application. That’s why the most critical skill in web development is becoming a productive member of a technical team. When starting a career as a web developer, you will be thrown into a team of other developers, both junior and senior, and expected to be able to add value from day one.
Developing software as team has a huge upside for junior developers. Other members of your team have an interest in providing you mentorship and helping you become an even better developer. Through constant feedback on your code, you can expect to consistently improve and learn something new every single day. Working on a team however requires different skillsets than working by yourself.
Becoming a productive team member is something you can only learn by actually placing yourself inside a real group project, going through trial-and-error, while being in a supportive environment. This means you’ll need to code together on a project with other people, who are as invested as you are in seeing the project be a success.
Working in the right group environment will help you become a happy and productive team member that other developers want to work with, which means you will get job offers. Before you walk into your technical interview, you should have learned the best practices of modern agile web development, and the processes required to help keep your code clean and bug-free.
Key Skills You’ll get From Coding With a Team
GitHub Pull Requests & Code Reviews
When working by yourself, you alone are responsible for the quality of the code. That means if you take sloppy short-cuts or write poor quality code you will be the only person that has to pay the price. When working as a team, it is the whole team’s responsibility to make sure that only high-quality, well tested, and bug-free code is accepted into the project.
The best teams require code reviews before code changes are accepted into a project, to ensure the quality of the code is up to their high standards. Code reviews happen when another team member, who was not involved in writing the code, reviews the proposed code additions and changes line-by-line and looks for things that could potentially cause unexpected problems.
Because code reviews happen frequently, GitHub comes with advanced features empowering teams to easily perform code reviews.
Requesting a code review prior to new code being accepted into the main branch is known as issuing a pull request, and the best teams don’t allow any code to enter their project without going through this pull request process.
In this process you present your proposed code changes and allow other developers to look through those changes.
Below is a GitHub pull request example from one of our theFirehoseProject students. The lines of code that are removed are displayed in red, and the lines of code that are added are displayed in green.
You can see how a mentor used the inline code commenting feature on particular lines of code, to help a student organize his code better
Whether you’re looking to contribute to open source projects or work on a team you’ll be expected to have the following skills:
- Create new pull requests and propose your code changes to the team.
- Make notes on other people’s code about things you think they might’ve overlooked in their code.
- Respond to people’s concerns about your code, either through code changes or comments on the GitHub platform.
As a developer your job isn’t just to implement features, but to write code that implements features that lives up to your team’s high standards. This means that responding to feedback on your code is critical for you to be an effective developer. By responding to feedback on GitHub you will continue to grow, and become a stronger developer.
Breaking Large Problems into Smaller Ones
Each team member works as a multiplier on the amount of code the team can produce. In order to reap the rewards of having many people contributing to the same project, large tasks need to be broken into small tasks that can be worked on in parallel.
For example if you are working on building a BlackJack game by yourself it would be your task to do the following:
- Build a BlackJack Game
Yet if you have a team of people building the same BlackJack game, the same project could be broken into smaller chunks that each member could execute on in parallel.
- Build a landing page for the web application
- Store emails that for users who have opted-in into a MailChimp account
- Build a representation of a deck of cards in the code
- Support users logging-in and logging-out
- Make the page look awesome on Mobile
By breaking large tasks into small pieces the team will be able to make many small steps towards the eventual goal of the completed application.
Most projects, even in the professional world, never will be fully completed since there are always additional features you can add to any existing application. It’s not uncommon for a product backlog, a list of features that are desired but aren’t built yet, to take an estimate of a year or more to complete!
Because teams often have so much work, software is built by having constant steps in the right direction, and breaking large features into smaller ones plays a huge role in getting to the finish line, one step at at time.
Test Driven Development
Having a robust test suite is more important when working on a team than if you’re a cowboy coder, or coding all by yourself. This is because projects can amass a lot of code, think 10,000 lines or more, and can quickly get very complicated. With that much code, someone who hasn’t worked directly with a particular section of the application before cannot be expected to know every nuance of how the application works.
By writing tests when you build the feature you prevent other team members (or your future self) from inadvertently breaking the application in ways you cannot predict as you’re building the software.
Having the entire test suite take more than 10–20 minutes to run for a complex project is pretty normal. Professional web developers often use “Continuous Integration” tools to help them run their test suits. Those Continuous Integration tools automatically run your tests for each pull request and help prevent members from accepting broken tests into the code.
Merge conflicts happen when two team members attempt to make contradictory, or conflicting, changes. Good communication as a team can help prevent avoidable conflicts, but sometimes they just happen as a result of building software as a team.
Here’s a scenario that could potentially cause a merge conflict.
Say Marco and I are working on the same project, theFirehoseProject landing page. Right now the headline of the page says: “We Create Web Developers”.
If I change the headline to be, “We Create Awesome Web Developers” and Marco changes the headline to be, “We Create World Class Web Developers” at the same time, we end up with a merge conflict. In short, one of us won’t be allowed to send our code changes up to GitHub until we deal with the fact that we tried to change a single line of code in two different and contradicting ways at the same time.
In this example, if Marco and I communicated better about changing the headline, we could have avoided this merge conflict. In many cases, particularly when dealing with complicated projects, conflicts will come up. Learning how to stay calm, communicate with other team members to fully understand their thought process about the change they made, and resolve the conflict to achieve both your goals and the goal your teammate had when they made the change, is a skill you can only learn by coding together as a team.
Stand-up / Scrum Meetings
Since communication between team members is critical, most teams will have frequent meetings, known colloquially as “stand-ups”.
During the meeting members of the team are asked to quickly update other members of the team with the following details:
- What did you work on since that previous meeting?
- What are you going to work on between now and the next meeting?
By having each member talk for 60–120 seconds about what they’re working on, other team members, who often times know more about potential problem areas of a specific feature can prevent a team member from going down an avoidable rabbit-hole.
Stand-up Meetings are designed to be between 10 and 15 minutes, and everyone on the team is required to stand for the duration of the meeting. Standing during the process of the meeting tends to speed up the meeting, and focuses people on the most important topics.
Sometimes when you work on projects you’ll find yourself working on intensely complicated problems. Other times you’ll find yourself working on more straightforward tasks. When you’re responsible for tasks that you’re struggling to complete, it’s incredibly valuable having another team member to work with.
This collaboration process between you and another teammate, to tackle difficult coding problems, is known as pair programming. During pair programming sessions one member of the team will sit behind the keyboard, write code and “drive” the interaction. The other person will sit behind the person and watch the coding process and provide realtime feedback.
Gaining skills in leading the code that is being written and giving real-time feedback in a productive way is an important skill to master. When starting out it can be intimidating to code in front of other people, knowing they’ll give you feedback as you code. Pointing out potential problems in other people’s code, in a collaborative manner is also a skill that takes time to learn.
Working in a constantly evolving environment
One of the biggest challenges to get used to when working as part of a team is getting comfortable working in an environment where many people are writing complicated code, and not becoming overwhelmed with the process.
When building features as a team, and many lines of code change rapidly every single day, it’s important to stay laser focused on the task you’ve been assigned. Although code is consistently evolving around you, you need to trust your team and the process.
Since code is continually changing, frequently updating the code you’re working with and making sure you’re working with the latest code is important. This process is known as “pulling down” the code that was contributed by other team members, and getting in the habit of pulling multiple times per day will save you from working on code that isn’t up to date.
Preparing you for the Technical Interview
Learning how to collaborate, communicate and use the right tools is incredibly important when building projects as a team. Having said that, all group project experiences aren’t created equally.
In the real world, working on a team doesn’t always go smoothly and everyone knows that. What is important is how challenges that come up while working as a team are resolved.
Questions about working on a team frequently come up during the technical interview process. Hiring managers are particularly interested with the types of challenges you have faced when working as a team and how you overcome those challenges. Your answers and experiences gives them a real world and valuable view into your problem solving skills as a developer and a team member.
When you’re asked to describe a challenge you’ve overcome working on a team everyone learns something. On the other hand if you indicate that you’ve never had any problems coding collaboratively, the team who is evaluating you as a candidate will likely believe that you are either very inexperienced or not telling the truth. Either way, you are unlikely to get that job.
Instead, speaking from specific experiences about the importance of clearly communicating with other team members and how to overcome communication problems when they arise will impress the team who is comparing you against other candidates for the position.
If you’re looking to switch careers, it is critical that you have experience working on complex applications as a team. This is because in the real world, even when you’re working with teams of “only” 4–8 other developers, projects get complicated quite quickly.
Building Advanced Web Applications
If you’re looking for a career as a web developer, hiring managers won’t be impressed if you’ve built simple applications that simply display information from a database on the screen as a team. On the flip side, building a project like a chess game, which is incredibly complicated, and deals with intense logic will be a lot more impressive.
Although on the surface a chess game may not sound very complicated, it has many complicated features. For example:
- How would you validate that a queen can move to a particular location on the board, given where the other pieces are on the board?
- How would you enable the castling move?
- How would you make en passant work?
- How would you update the board for user #2, when user #1 moves the piece without requiring a page refresh.
- How would you check for checkmate / check?
One of our students who worked on a group project got a job at a company in NYC and the 2 hour interview process mostly entailed reviewing her code and pull requests from building the chess app during her group project
You should make sure to keep the goal of a group project in mind. It’s all about building a complex application; not necessarily to have thousands of users use it. Rather than trying to come up with ideas that would have the highest potential to be used, you should focus your efforts on a learning as much as you can during the group project.
If you’re considering joining a coding bootcamp in order to switch careers and become a web developer, you should read the Definitive Guide to Choosing a Coding Bootcamp, a no-nonsense guide to figuring out what really matters when it comes to comparing different programs.
Do you have any questions about how the importance of building software as a team? Tweet it up to @FirehoseProject and we’ll answer your questions right away!