Beginner Developer Learning Center

Video Transcript: Working Together

Intent: Discuss how a development team works and how it’s different from being a hobbyist developer
in isolation. Include talk about coding conventions, code reviews, and source control. A brief
introduction to the various roles will be included.

Abstract: If you’ve been programming for yourself for some time, you probably spend hours figuring out
the best way to do things. Sometimes working alone seems great since you get to make all the
decisions, but other times you’ve probably wished you had help just when you needed it. Learn about
how a professional development team works together to get the job done – hopefully both on time and
on budget!

Key takeaway: List five conventions or source control systems. Expectations of code reviews
(when/how). Concrete examples always good.

Male Narrator: Teamwork. It’s not just for sports. An effective office is all about teamwork too.
Programming by yourself is a great way to get started, but employers are looking for more than a great
programmer – they want someone who will fit in well with the team and work together to accomplish
great things.

Female Narrator: When you start on your first team project you may be a bit overwhelmed at first.
“Why can’t I just get coding!” you might wonder. Instead you have seemingly unproductive meetings
and lots of new rules to follow. Prepare yourself for this and it won’t seem so bad.

Male Narrator: When you start coding, you may be in for a shock when you learn that you aren’t doing
things the right way. “What do you mean?” you might ask, especially if your code works fine. This is
when you’ll learn that the company has a set of coding conventions and you weren’t following them. So
what’s a coding convention and why is it so important?

Female Narrator: Some companies might only have one or two programmers, but teams of five, ten, or
even forty aren’t uncommon. When groups of people are working on a team there needs to be a way to
keep code consistent. Rules to enforce this consistency are called coding conventions. At first it might
feel constraining to have these rules, but as you integrate your work with that of other programmers,
you’ll appreciate it! You can learn more details on coding conventions in the “Going with the Flow”
flow, also in the Professional Developer section of the BDLC.

Male Narrator #2: Once you finish your work, you may feel like people don’t trust you when they want
to sit down and examine your code. This isn’t an attack though, and in most companies this is common
practice for everyone. Getting one or more senior developers in the room to look through your code is
called a code review. The point of it isn’t to single anyone out, but rather to make sure that code quality
is consistent throughout the organization. If you connect to a database using a different way than in
other code then you’ll probably need to fix it. If you read your settings from a local text file when other
applications get them from a shared server they’ll want you to change it.

The reason for all of this isn’t to make you do extra work. Just like with code conventions, code reviews
help to ensure consistency. If someone else needs to update your code later on, they want to be able to
be productive as quickly as possible. If they need to spend time figuring how you did things, this won’t
happen. The great thing about code reviews and code conventions it that you benefit from them when
you need to look at other people’s code.

Female Narrator: Let’s talk about Source Control. Team Foundation Server, Subversion, and CVS may
well be new names for you, but you’ll want to get used to them quickly. Unlike your own projects, you
can’t just store source code on your hard drive. First of all, it’s too dangerous if your computer fails. For
another thing, other people may need to be working on the project at the same time. Even storing the
files on a network server isn’t enough by itself.

Programmer: In order to allow teams to collaborate on software development, most organizations

employ source control servers. Let’s take a look at how that works.

This is a great way to keep projects shared properly across a team. I’m going to grab some code for a
project. The TFS server is the definitive source. Anything on a team member’s local machine is
considered newer, but not yet merged into the source file. So now I’m going to make some changes.

Now I can check it back in with a comment. That was easy enough, but sometimes two people update at
the same time. As long as they update different parts of the file it’s no problem, but if both members
are working on the same block, a decision needs to be made. Now here another teammate has changed
the code and checked it back in.

If I change that same block, TFS detects that I wasn’t working from that same code and I might not be
aware of my teammate’s change. I can either merge the code, or choose one version over the other. In
this case, I’ll choose my code as the better version.

Team Foundation Server and similar offerings make all the difference in allowing a team to function
well.

Female Narrator: At home or at school you are in charge of figuring out how to implement your
solution, then doing the work to write the code. An organization might involve more people than you
can count on both hands to manage code as a project. People need to figure out what’s needed and
how to fulfill the needs. People need to write and test the code, and of course someone needs to
manage all of the various people so things can get done quickly. Let’s meet some of these people.
BA: As a business analyst, I’m in charge of looking at business processes to see how they might benefit
from software. I don’t know very much about what software can do, but I know what I need it to get
done. By talking with different business groups I come up with a statement of requirements.

PA: As a project manager my job is work with the business analyst and the programmers to make sure
that the project stays on track. I schedule meetings, come up with schedules, and make sure that all
parties have what they need.

SA: Hi. I’m a software architect. I study the business needs and create a blueprint of how the software
will work. I need to make sure that new software works well with existing systems both now and in the
future. I may also create a document that examines the requirements and maps it to functionality in the
proposed software.

Programmer: I’m a programmer. I’m responsible for translating the blueprint of the software into code.
I need to really understand the software platform, the various connected systems, and exactly what
needs to be created, then turn all of that into code.

Tester: Once the code is complete, then it’s my turn. I’m a tester and I need to run the code through its
paces. By comparing the statement of requirements to what I actually see, I can determine if the goals
have been met or if more work is required. Depending on how testing goes, the code might bounce
between the programmers and me until everything is ready to go to the users.

Narrator: By understanding how a team works and how to adapt to a business environment, you can
avoid surprises! Instead of being overwhelmed, you can feel prepared. Learn some new terms, take the
time to understand the process, and be productive sooner. You’ll be glad!