In our company, code reviews are mandatory and that restriction is built into checkin triggers (clearcase). No exceptions.
When this process was instituted about an year ago, expert programmers wanted to checkin without code reviews. They only wanted to review new-hire or inexperienced programmers' code. However, the new-hires all knew the 'right way' that they are taught in school, though they should be reminded to keep following those good ways (in school you lose points for writing bad code in programming assignments and your grade is at risk).
Over the last one year, after the triggers were instituted, the team culture has changed from having lengthy email disputes to something more like teamwork. Every comment is greatly appreciated and good reviewers are rewarded.
The only ones people still don't agree upon are indentation and code-formatting related. People still have different opinions about those (we found a different solution for it that everyone agrees with). However, there is almost no dispute in our team about what constitutes good, working, maintainable code. Everyone in the team has learned and would not want to live without mandatory code reviews any more.
If the expert programmer disagrees with the comment, fire him. There are thousands of other expert programmers out there that work well with the team and lead by example.
Companies that produce products: - hire highly skilled workers locally - sponsor H1-B visa for skilled workers from outside US to work in the US - transfer jobs from US to their own subsidiary to reduce expenses if skills-cost ratio makes business sense - transfer jobs to contract-companies for short term contracts or if subsidiary is more expensive - so far, can't find any fault. But then, they also - hire consultants from other companies that have in-turn brought people over to US by sponsoring H1B visa. (This is where the problem begins and exactly where the senate is focusing. Kudos to the senate).
Contract companies: - are multinational and so can issue H-1B visa for someone from outside US to work in the US. - usually place consultants into parent-companies. Actual work gets performed in the US. These workers get totally screwed by the contract-companies. They get paid less than those H1-B workers directly hired by the parent-company. The parent-companies do not pay much attention to this difference officially ("well... it is not our business.. it is internal business between the consultant and his employer...") Some good managers actually do care and they take immediate action. Some smart H1-B workers know this and renegotiate their positions as well. These contract-companies make unethical and irresponsible use of the H1-B program. - By hoarding H1B permits, they make it impossible for other, usually smaller companies sponsor H1B for really skilled workers when such a talent is really not available in the US
I am not going to debate who is more skillful (a citizen, a permanent resident, H1-B-worker sponsored by the parent-company or the H-1B-worker sponsored by the contract-company). That is a different topic of discussion.
The truth is there is usually a big difference between two H1B-workers working in the same parent-company in adjacent cubicles in the US, but then their employers/sponsors are different. I have never come across any difference in salary levels between a local worker and a H1B worker sponsored by the same employer of the local worker.
For the duration the work is performed in the US, the wages must be the same as what the parent-company would pay. Unfortuatenly, the contract-company usually takes a lion's share and the H1B-worker gets screwed. Like I said, only the good managers notice this and negotiate the contract before hiring the consultant. Many are somewhat ignorant or don't care enough to confront the contract-company (deadlines to meet or real shortage of workers.. whatever excuse it might be).
There is nothing simpler than a word processor (like Word, Openoffice, Frame Maker) that has built-in version control and commenting features.
If you use any version-control mechanism like CVS, SUBVERSION etc, you don't need branching or tagging. Everyone should see the latest version from their view. I've found that the mmost useful features are change bars and a page that talks about the major changes in every version. I use clearcase. I create an element for "controlled source" and "uncontrolled PDF". Check out the files, make modifications, update revision history, check in both the "controlled source" as well as "uncontrolled PDF/HTML" formats. Have a cron job or a checkin-trigger that publishes the "uncontrolled PDF/HTML" files over to a public web-site every night (which is then accessed via links from sharepoint). I use sharepoint only for creating hyperlinks to another webserver which actually has the repository of the uncontrolled PDF and HTML documents.
I have not found Wiki's or HTML useful for engineering specifications. They are useful for creating one-page how-tos or sequences of instructions. Word processors can create these web formats automatically anyway. HTML/Wiki prevents people from following a specific structure or template for all specifications. If you want to save time for writers and reviewers, you should create templates. They create some sort of uniformity among the docoments.
Slashdot Mirror
In our company, code reviews are mandatory and that restriction is built into checkin triggers (clearcase). No exceptions. When this process was instituted about an year ago, expert programmers wanted to checkin without code reviews. They only wanted to review new-hire or inexperienced programmers' code. However, the new-hires all knew the 'right way' that they are taught in school, though they should be reminded to keep following those good ways (in school you lose points for writing bad code in programming assignments and your grade is at risk). Over the last one year, after the triggers were instituted, the team culture has changed from having lengthy email disputes to something more like teamwork. Every comment is greatly appreciated and good reviewers are rewarded. The only ones people still don't agree upon are indentation and code-formatting related. People still have different opinions about those (we found a different solution for it that everyone agrees with). However, there is almost no dispute in our team about what constitutes good, working, maintainable code. Everyone in the team has learned and would not want to live without mandatory code reviews any more. If the expert programmer disagrees with the comment, fire him. There are thousands of other expert programmers out there that work well with the team and lead by example.
for long flights. This is even more important now that the TSA in USA does not allow spare laptop batteries on board.
Companies that produce products:
- hire highly skilled workers locally
- sponsor H1-B visa for skilled workers from outside US to work in the US
- transfer jobs from US to their own subsidiary to reduce expenses if skills-cost ratio makes business sense
- transfer jobs to contract-companies for short term contracts or if subsidiary is more expensive
- so far, can't find any fault. But then, they also
- hire consultants from other companies that have in-turn brought people over to US by sponsoring H1B visa. (This is where the problem begins and exactly where the senate is focusing. Kudos to the senate).
Contract companies:
- are multinational and so can issue H-1B visa for someone from outside US to work in the US.
- usually place consultants into parent-companies. Actual work gets performed in the US. These workers get totally screwed by the contract-companies. They get paid less than those H1-B workers directly hired by the parent-company. The parent-companies do not pay much attention to this difference officially ("well... it is not our business.. it is internal business between the consultant and his employer...") Some good managers actually do care and they take immediate action. Some smart H1-B workers know this and renegotiate their positions as well. These contract-companies make unethical and irresponsible use of the H1-B program.
- By hoarding H1B permits, they make it impossible for other, usually smaller companies sponsor H1B for really skilled workers when such a talent is really not available in the US
I am not going to debate who is more skillful (a citizen, a permanent resident, H1-B-worker sponsored by the parent-company or the H-1B-worker sponsored by the contract-company). That is a different topic of discussion.
The truth is there is usually a big difference between two H1B-workers working in the same parent-company in adjacent cubicles in the US, but then their employers/sponsors are different. I have never come across any difference in salary levels between a local worker and a H1B worker sponsored by the same employer of the local worker.
For the duration the work is performed in the US, the wages must be the same as what the parent-company would pay. Unfortuatenly, the contract-company usually takes a lion's share and the H1B-worker gets screwed. Like I said, only the good managers notice this and negotiate the contract before hiring the consultant. Many are somewhat ignorant or don't care enough to confront the contract-company (deadlines to meet or real shortage of workers.. whatever excuse it might be).
There is nothing simpler than a word processor (like Word, Openoffice, Frame Maker) that has built-in version control and commenting features.
If you use any version-control mechanism like CVS, SUBVERSION etc, you don't need branching or tagging. Everyone should see the latest version from their view. I've found that the mmost useful features are change bars and a page that talks about the major changes in every version. I use clearcase. I create an element for "controlled source" and "uncontrolled PDF". Check out the files, make modifications, update revision history, check in both the "controlled source" as well as "uncontrolled PDF/HTML" formats. Have a cron job or a checkin-trigger that publishes the "uncontrolled PDF/HTML" files over to a public web-site every night (which is then accessed via links from sharepoint). I use sharepoint only for creating hyperlinks to another webserver which actually has the repository of the uncontrolled PDF and HTML documents.
I have not found Wiki's or HTML useful for engineering specifications. They are useful for creating one-page how-tos or sequences of instructions. Word processors can create these web formats automatically anyway. HTML/Wiki prevents people from following a specific structure or template for all specifications. If you want to save time for writers and reviewers, you should create templates. They create some sort of uniformity among the docoments.