Are you in the project team?

Original article think you have a team? You don't. "-Jason Cohen

 

It mainly explains the role and significance of the Code review for the entire team, and partially translates it.

 

"Team building" is a load of bull. it's happy-talk that changes nothing. it's a laughable trust exercise. it stifles the best developers to serve mediocrity. suspend your judgment for the five minutes it takes you to read this essay. it isn' t all about "ra-rah, go team go."

 

The so-called "team building" cannot truly make us a team member.

 

I'll give you the punch line first. peer code review not only finds bugs, it creates an environment where developers work together instead of in parallel. it's team building in the real sense-people helping each other to achieve something greater than each cocould achieve alone.

 

A pair of code reviews can not only discover bugs, but also create an environment for developers to work together, rather than simply doing it ". This is the "Team building" in real scenarios-Everyone helps each other to reach a higher level that individual cannot reach.

 

Developers write code while squirreled away behind doors and headphones. After the architecture and interface discussions are over, code is written in isolation. Does that sound like a team to you? I'll bet most of the Code in your application has been seen by only one person. think about that for three seconds. it's a frightening thought. teams supposedly work on projects together. do you really have a team?

 

After the architecture and interface are discussed, the code is developed separately. Is this like a team?

 

I bet most of your programs are only viewed by one person.

 

New hires want to get into code fast and get their hands dirty but they need a safety net to make sure nothing bad happens. How do your developers handle this? Isn't "Teaching and supporting" a team activity?

 

New programmers want to get started with the code as soon as possible, but he worries that the original code will be accidentally destroyed and needs a "security net ".

 

The "American Heritage Dictionary" defines "team" as "two or more draft animals used to pull a vehicle or farm implement. "The same is true of" teamwork "in most software development organizations, too. being a team doesn't mean we're re merely marching in the same direction. you're not a team just because you know everyone's name and you eat lunch together. that's just being acquainted. real teams actually work together. let's see how peer code review can help build a real team.

 

As you can see from the dictionary, "team" means "two or more animals used to draw vehicles or farming equipment ". For a software development organization, being a "team" is not because you are traveling in the same direction, nor because you know everyone's name and have lunch together. A real "team" is an organization that does work together. Peer code review can help us build a real "team ".

 

One is the loneliest number

 

"It's scary how much code I 've ve written that no one else has ever seen. "I was told this by a developer who had just started using our software to do peer reviews. "the worst part is, I know it can't all be right. "Yes, you shoshould be scared. the average Professional novelist makes nine mistakes per page. no surprise; that's why there are editors. in fact, the 2000 census shows that in America we hav E more professional editors than professional writers! So why do we recommend CT developers to write reams of technical code without the safety net of an editor? Aren't we guaranteeing errors?

 

On average, professional writers may encounter 9 errors per page. This is why there are edits.

 

What's your "bus number ?"

 

A project's "bus number" is the number of people who have to get hit by a bus until no one is left who understands the code. A startling amount of code has a bus number of one, which leads to a software process that is easily derailed. if that someone is sick, leaves the company, or really is hit by a bus, arts of a project can stall or might be implemented incorrectly.

 

Code review provides a safety net for both developers and managers. for managers, they like the project stability that comes from having a bus number of two or more, and developers like the comfort of knowing that someone has their back. in a real team, people look out for each other.

 

Code review not only provides developers, but also provides managers with a "security net ".

 

"Those guys suck"

 

It was a large software company. A small overworked software group in Austin had been asking for additional developers; Finally their wish was granted in the form of 20 developers in India. the group in Austin was annoyed. it was responsible for running the remote group and inconfigurating its code into the local base. "Those guys suck," was what the Austin team said exactly, referring to the Indians . "They don't know how to write code. and they don't do it the way we ask them. and they don't write comments. forget about comments in English, they write no comments at all!"

 

Austin started using code review software to check everything being done in India, right down to communicating on individual lines of code and having twoway conversations. four weeks after the reviews started, the same developer who had told us they "suck" now said of the Team, "they're pretty cool. "" they're doing a good job now. they just needed a little ction. we're re actually getting a lot of good code written."

 

It turns out that the Indian developers were inexperienced, but they were smart and wanted to learn. once the two factions had a mechanic for easily talking to each other about code, the knowledge transfer cocould begin.

 

The developers organized themselves into a team. all they needed was an environment of communication and a tool to make it easy. they taught each other without managerial pressure or rules or strict process controls. working together, teaching and sharing, being happier, all without being told... sounds like a team!

 

Developers organize themselves into a team. They only need a communication environment and some auxiliary tools, we can work together, communicate with each other, share knowledge, and train each other without management constraints, rules, and process control, and enjoy working happily, this is a "team "!