After watching this video, you will be able to:
Describe social coding principles and recognize how pair programming creates better code and
better programmers.
What is social coding?
I like to call it "Open Source for Inner Source."
Social coding is something that the open-source community has been doing for years.
What’s new is bringing these concepts into the enterprise and coding as a community on
internal projects.
In the past, developers worked in private repositories (repos) and you had to be a member
of the team to contribute.
Everything was controlled by access control lists and a strict "need to know" basis.
The problem with that is no one knows that you're working on it, so there is no possibility
of reusing code because no one even knows it exists.
So, enterprises continually re-invent the wheel because no one knows the wheel has already
been built.
With social coding, repositories are public, and everyone is encouraged to fork the code
and contribute.
This is a hugely different way of thinking.
Development teams love to think "this is my code and no one else can touch it" but they
need to get over that for the good of the company.
You would think that anarchy would ensue, but actually, it works quite well because
it’s controlled by the repository owner.
The person who owns the repository is still in complete control of the contributions.
What problem is social coding solving?
Let's say, you see a component, it’s 80% of what you need, but there are some missing
features.
How do you add those missing features?
You now have a decision to make:
Do you make a feature request to the repo owner for a new feature and risk that your
request will be at the bottom of their priority list?
Or worse, their funding gets cut, and your request will be cut out first.
Or do you rebuild 100% of the code just to get the 20% that you need so as not to have
a dependency on another team?
It’s sad to report, but many teams select the latter and re-invent the entire wheel
just to get the functionality they need.
This is a huge waste of resources for any company, but it happens all the time.
How does adopting social coding principles solve this?
You discuss the new feature with the repo owner, and you agree to develop it for them.
This allows you to leverage everything that they've done and add the feature that you
need.
You open up a GitHub Issue and you assign it to yourself so that everyone knows you’re
working on it.
Then you fork the repo, create a branch, and make your changes.
When you’re all done and have something to contribute back, then you issue a pull
request signaling that you are ready for a review and the repo owner can decide whether
to merge your code back into the main project.
The repo owners are in full control.
They can ask for changes because they do the merge.
They can ask that you write more test cases if you don't have adequate test coverage.
They treat you and your contribution like any other member of the team.
This is a win-win situation.
You get to leverage another team’s code and all the functionality that you need, and
the other team gets a feature added for free.
The company saves money because code is being reused instead of rewritten and everyone is
happy.
This is how open-source works and this is how companies should treat their inner source.
Pair programming is an aspect of social coding that is taken from Extreme Programming.
It consists of two programmers sharing a single workstation (one screen, one keyboard, and
mouse between the pair).
The programmer at the keyboard is usually called the “driver.”
The other programmer, also actively involved in the programming task, but focused more
on the overall direction, is called the “navigator.”
While the driver is typing, the navigator is checking their work, or perhaps looking
something up, or thinking about what's coming next.
Then, after about 20 minutes they swap roles.
This way they both get to play each role.
I pair program whenever I can at work.
I like this aspect of social coding.
One of my personal weaknesses is that I will agonize over what to call a new variable or
function.
I want to get it perfect, to make the code as readable as possible.
Having someone else to bounce ideas off of helps me make those decisions faster.
You might think that pair programming is using twice the resources to get the same amount
of work, but it’s not like that.
There are many benefits of pair programming.
The first benefit is higher code quality.
There is something about "programming out loud" that leads to a clearer understanding
of the code.
In the past, when I wrote code, and I wrote it alone, and then when I explained it to
someone, I would pick up on a bug as I was talking out loud.
I didn’t see the bug when I was looking over the code in my head, but I saw it as
I talked out loud.
Having to explain code to someone forces clarity.
This means that defects are found earlier.
That's a good thing because it lowers the maintenance costs right down the line.
The later a defect is found in the process, the more it costs to fix.
Pair programming also forces skills transfer, creating better programmers.
I like to pair junior programmer developers with senior developers.
I do this all the time so that each one learns from the other’s approach to a problem.
They pick up tips and tricks that the other one uses.
It creates better programmers.
You also get two sets of eyes on every line of code.
You don't want code that only one person understands.
Then, that person goes on vacation, and no one knows how to fix their code.
Pair programming leads to a better understanding of the code.
More people understand the code well enough to fix and enhance it.
In this video, you learned that:
Social coding is done communally with public repositories and all team members are encouraged
to contribute.
Pair programming results in higher quality code because defects are found earlier, costs
are lowered, and there is a broader understanding of the codebase.