In most programming jobs, you’re going to be working and collaborating as a team – and many of the practices you’ll pick up when coding on projects by yourself will fall apart when you start working with other people. Most teams of developers have established certain ways of working with one another. Some people call this process “Agile.” Others call this process SCRUM. Basically, these are the rules of the game for how to code together.
Before we jump into how teams work together, let’s drop down flip it and reverse it and talk about processes individuals tend to take when writing software by themselves and how these break down when working on a team.
The Cowboy Coding Culture
When someone throws the term “cowboy coder” out, they’re generally implying a lack of maturity in a developer – but there are plenty of upsides to working on a project start-to-finish by yourself. In a nutshell, a cowboy coder is a one-man (or woman) wolf-pack,who builds all aspects of a project by themselves.
Despite common misconception – teams of 2 programmers working on the same project won’t complete the task twice as fast. In reality, a team of 2 would probably take about the same amount of time to build a project as one person doing it by themselves. In fact there are entire books written about the topic.
There are certain, huge advantages of building things by yourself.
Zero-Communication Overhead
When one person is working on a project by themselves, when they are working they are doing a single task: programming. That’s it. That means every bit of work is directly tied to writing or changing lines of code. That means every single bit of work is moving the code of the project forward.
On teams however, there is a lot more communication overhead:
- Communicating about what you’re working on, so people don’t step on your toes.
- Giving feedback on code.
- Knowing what other people are working on so you don’t step on people’s toes.
So if you’re a cowboy coder, you’re spending all your time coding. You’re never emailing, in meetings or held up by bureaucracy.
You intimately know all aspects of the codebase
When you’re writing ALL the code, you’re going to have a solid idea of how every part of the application is built because you wrote it all. This means you’re not going to be jumping into code trying to “figure out what heck someone else was thinking.”
This means when you want to add a new feature, you can know exactly the areas of code you’ll need to change immediately and spend no time looking around through code someone else wrote.
On the flip-side, there are a number of trade-offs to writing code by yourself
Cowboy coders are named such because the code you’re writing is the wicky wicky wild west. Anything goes out here:
While having no communication overhead is nice, you won’t have peer pressure to do things “the right way.”
Unit tests? Only nerds write tests! Code reviews? Nah. We can do whatever we want. We’re Mr. Manager now.
Having someone else in the code with you will give you a little more peer pressure to solve things the “right” way. When you’re writing code by yourself, it’s easy to get into the habit of writing quick hacks to gloss over problems rather than solving the root of the problem.
Having more than one person involved in coding means your personal coding output will decrease, but that overall quality and the likelihood of the project being a success increase tremendously.
For these reasons, most of the best software is written by teams of engineers. But two cowboy coders working together don’t make a team – there can only be one Chuck Norris on a team, and nobody wants to work with him. Instead, the people need to be on the same page, working together and helping each other out. Bossiness is out and communication is in.
But in order to code collaboratively as a team, we’ll need to play by the rules. The rules are called Agile. Or SCRUM.
How to Work Together as an Agile Team
The words SCRUM and Agile are the terms that developers use to describe the process of writing software on a team. It used to have a very specific meaning (related to agile methodology) – but is often abused and used to describe any process of communication that has roughly the structure we’re going to outline here.
The important thing to know is the alternative to this type of environment is working in a “waterfall” team. Waterfall is a dirty word in the programming community and basically means being given a month-long product specification document from up high, going in a cubicle and building it out. When the month is done you hand it off to the next team and then forget about all the work you’ve done the previous month. Team leads will generally not admit they function this way, or if they do, they will say so with shame and self-loathing.
But let’s talk about how SCRUM teams generally work, since that’s how most teams collaborate. There are a number of interesting components that make up these teams.
Product Backlog (Tickets)
Product managers and other engineers will generally have access to some form of a ticketing system. Examples of popular ticketing systems that are used in companies are: Basecamp, Redmine, Jira, Rally, Pivotal Tracker, or GitHub Issues.
Product Managers – whose job is to define what features will be built next – will insert tickets for features they intend to build. They’ll generally tell you the “what to build,” but usually not too many details about the “how.” Engineers will add notes on the issues that describe technical implementation details:
The product backlog is the list of all possible feature requests and product improvements that can be made.
What is a Sprint?
A sprint is a collection of work (generally tickets) that is designed to be done in a certain timeframe. In the real world, sprints of 1 week, 2 weeks and 1 month are common. The sprint will contain the top-priority work that needs to be done. Anything outside the work that is agreed upon is secondary.
It’s the answer to the question: “What the heck are you guys going to be doing for the next [NUMBER] days?”
Each team member will be assigned some tickets they need to accomplish in the sprint, and sometimes some tickets will be left unassigned for team members who finish their work before the end of the sprint to pick-up in the meantime.
Usually at the end of the sprint, the code will be deployed (or shipped, or basically just made live on the Internet). Some forward-thinking companies do things a little bit differently, and we’ll talk about that in a moment.
If you consistently are unable to complete the work you are assigned in a sprint, you (and the entire team) will generally get in trouble. Good engineers will finish all the work they’re assigned in a sprint, or if they are unable to because of reasons they didn’t know when they accepted the task, they will communicate that fact before the sprint is finished.
Sprint Planning
If a sprint is the grouping of the different pieces of work (tickets) that need to be done in the upcoming days, how do you know what tasks will be part of the next one? The answer is, it’s planned just prior to the end of the previous sprint.
Engineers, product managers and often other team members will go through the entire list of potential tickets that need to be worked on and figure out which ones are most important and need to go next.
Some tasks will be more work than other tasks. Often times during sprint planning, engineers will talk about the complexity of making a change. In order to discuss how hard something is, Agile teams tend to use the concept of a “Story Point.”
A story point is a unit of measuring how complex something is and is used to compare the complexities of different tasks. Because a single task might take a senior engineer 10 minutes, but a junior engineer 2 hours, estimating how long a task will take can’t be done as a measurement of time.
Fixing a typo on a page is something that might take 1 story point. Rewriting the core functionality of an app from scratch could potentially be 14 or 15 story points. Most things will fall in between.
The meaning of a story point is different for each team – and initially it seems pretty arbitrary – but once you have a baseline to compare tasks to, it’s pretty easy to estimate.
Once your team has identified tickets to “pull into the sprint” that satisfies a certain number of story points, the meeting is concluded.
Stand-up Meetings (SCRUM Meetings)
Software engineering teams will generally have one meeting each day, hopefully lasting around 10-15 minutes, to quickly get everyone on the same page about what everyone else is working on. Teams will generally stand around in a circle and answer the following questions:
- What did you do yesterday?
- What are you going to work on today?
- Is anything preventing you from getting what you need to do done?
People stand in a circle (rather than sitting at a desk) to prevent people from rambling on and on.
One by one, each person gives a quick update. Then stand-up will conclude, and often sub-groups of people will follow up with each other about some of the stuff they talked about during the meeting.
These meetings help hold team members accountable – it’s hard to fly under the radar if every day in stand-up you say you’re working on the same task and you’re making no progress on it. Also, if you say you’re going to finish a task one day in stand-up, people generally expect you to confirm that you did.
Task Boards
On many teams, it makes sense to keep track of who is working on which task. The way Agile teams tend to think is:
If you’re working on more than one thing, you’re really not working on anything.
Keeping track of who is working on what, and what else needs to be done is important. Agile “Task Boards” are generally used. All tasks are listed out and organized as a task that is either: “TODO,” “In Progress,” or “Finished.” Some teams will also have additional categories for “Deployed” or “Tested” too. All teams are a little bit different. Here’s an example of someone using trello to keep track of things:
You can easily move a card from one category to another. So if you start working on a task, it’s your duty to update trello and drag the item from the “TODO” column to the “Doing” column!
Technology is great at keeping track of these things, but you can also use old-school post-it notes and a bulletin board to do the same thing (assuming you’re not working on a remote team) – and pick up and stick the post-it to a new section of the board.
Talking about and updating the SCRUM board is generally done during stand-up as well (since stuff you were working on yesterday could be done today, and things that were TODO yesterday are a work in progress today).
Chat Rooms
Companies will generally have developers using a private chat room, such as Slack, HipChat, Campfire or IRC. Having a quick way to unobtrusively get help and feedback from other team members is incredibly useful.
While a lot of productive work happens in chat rooms, generally there’s a certain amount of “goofing off” in there too. Companies use these to help team members communicate, build relationships with each other, establish culture and get work done.
Rule #1 Headphones Mean: Don’t Bother Me
Especially on large teams, it can become hard to focus on tasks (like writing software!) because people from your team, other teams, and other departments interrupt you to quickly get you to answer a question for them.
You might be a programmer if you’re helping people with their small random questions so constantly that you don’t have time to code.
In plenty of places, it’s normal to obey the rule, “don’t bother someone who has their headphones on.” Heck, plenty of times I have my earbuds in, but they’re not even plugged into my earphone jack – because I need to focus on something.
Other programmers find it’s productive to come in a bit on the early side before other people come into the office, to actually “get stuff done.” Others come in on the later side, but they end up leaving late too, after most of the other people have already left.
Best Practices
Most teams try their best to follow “best practices.” The way I think about best practices is:
The stuff that is generally accepted as a good idea in the long run, even if it is a bit of a pain to implement in the short run.
Seasoned developers love so-called “best practices” – not because they’re smarter or better than less experienced developers – but because they have personally been burnt multiple times by the consequences of the often-times “easier” way to go.
So while these topics we’re going to cover aren’t “musts” by all teams the best teams will follow these steps.
Test Driven Development
When you have teams of 4-8 people working on the same project – software gets written pretty quickly. On the flip side, things get complicated very fast. Having codebases with tens of thousands of lines of code is pretty common. With codebases this complicated, there will generally be certain aspects of the application you won’t fully understand.
Working in an environment where you know how the big picture of the application works, but don’t have every intricate detail committed to memory is pretty normal.
This means it’s not terribly uncommon for one person to build a certain feature that you don’t know about, while you make a change to add a different new feature. Because you don’t know too much about the other feature, you could potentially break someone else’s work without even knowing it.
Teams of people constantly undo-ing and breaking each other’s code isn’t productive. So that means once you add a feature, it is critical to write a test to verify the code is working.
This means in the process of writing a feature, you should also write a quick little program that makes sure the feature you’re adding still works. Because there’s a program that will automatically alert you when the feature no longer works, you’ll get notified when you break someone else’s work.
This means tests are useful both in the short term, but even more so in the long term.
Continuous Integration
Continuous integration is the process of automatically running the tests you have (you’re writing tests, right!?) before the code is accepted into the codebase. This means continuous integration should prevent bad code from getting accepted.
Continuous Deployment
Most companies follow a process where they have a day and time when they will bundle up all the latest code changes and put them live on the internet. In many situations, this happens shortly after the sprint ends.
Most startups live by the motto “ship early and often” to get user feedback. This means the time between writing the code and having it live on the Internet should be as short as possible.
Some progressive companies, like IMVU, Etsy and even larger organizations like Google and Facebook use continuous deployment for certain aspects of their product. Continuous deployment is the act of putting the latest code changes live on the Internet as soon as the code is accepted. This means users can see updates and the latest changes as soon as they’re ready. Many companies that do this can have 50-100 deployments (code updates) on a given day!
Pair Programming
Good teams will encourage team members to pair program while building out certain features. When pair programming, there is one developer who is the “driver” and gets the keyboard and is able to type code. The other person will watch the code the other person writes, give suggestions for alternatives, catch potential problems in the code, and then the roles eventually switch.
The first few times pair programming, it can be a bit daunting to be in the “driver” seat – but over time you’ll get comfortable with it. When you start, you’ll be thinking “I don’t want to look stupid in front of someone else.” That quickly changes to, “I want to make mistakes in front of someone else so they can point out the problems and it doesn’t take me forever to uncover them.”
While having multiple eyes on the code at the same time is an excellent way to tackle programs that are hard, it’s also one of the best ways to level up as a developer. If you’re a junior developer, you should try to finish the tasks you’re assigned efficiently and roll up to another developer and offer to help them out by pair programming. You’ll help them get their task done and in return, they’ll teach you all sorts of things about coding you didn’t know.
Code Reviews
Performing a code review is the act of looking at someone’s proposed code changes before accepting it. It is within these code reviews that different team members can talk about alternative ways to write the code, and a fresh pair of eyes can usually identify issues that could come up from accepting the code that the code author hasn’t thought about.
By using GitHub’s feature of “Pull Requests,” you can quickly propose changes to the group. The best teams generally have a rule that:
- All code will be reviewed by someone before it’s accepted.
- The person who accepts the code wasn’t involved in writing the code change.
Some teams don’t use these rules for code that was written with pair programming (since the person who is in the passenger seat while pair programming holds the author of the code accountable).
As a coder you should be on both sides of the code review process. You should have your code reviewed, and you should be actively reviewing code that other people are proposing. When you’re reviewing code, don’t hesitate to give your two cents about it. By discussing code in depth, you’ll learn more about it, even if what you initially say is incorrect.
Code Style Guides
A lot of times, there are multiple solve a single problem with code. In ruby, you can indent your code with spaces or tabs. It doesn’t matter which you pick, and if you’re working alone, that’s fine. But having one team member choose one style of writing code and another team member using another, there will be inconsistencies when the developers work in the same file.
You may be interested in reading the ruby style guide, a series of rules on how to write code that many companies adhere to.
Fact! If you write code that conforms to a single coherent style guide, such as the ruby style guide, and a potential employer reviews your code, they will subconsciously think you’re a better programmer than someone who doesn’t conform to a style. Here’s an example of two code samples that are identical but use inconsistent methods for indentation (spaces vs. tabs). Most will think the person who wrote the consistently indented program is a better developer, even though all the code is exactly the same.
The key takeaway is that the best teams have a specific way they work together. When you join a team, there is a certain cadence that your team will have. On day 1, you’ll be expected to know the rules of the game and how to collaborate as a team.
Developers generally will not train you on these things, and instead they’ll expect that you’ll be able to “figure it out” – or ask questions about the part of the protocol you don’t understand.
During the interview process, while you’re talking with different companies, you’ll want to ask your employer what their stance is on the best practices and talk about your depth of experience with them.
Questions you should always ask are:
- Do you use test driven development? If so, dive in and find out more specifics of how they write tests.
- Do you have continuous integration or deployment setup?
- How do you feel about pair programming?
- Do you follow a certain coding style guide?
- How do you conduct code reviews?
These questions will show that you already have experience working on an agile team and appreciate the craft of building software, and that you will play by the rules and have outgrown your cowboy coding roots.
One of the best places for learning great teamwork is an amazing community. Join our Firehose Project community on Facebook.
