Hacker News Reader

Comment by edw519 | Hacker News Reader

I would add...

"Work in a shop that QA's the source code by people who know what they're doing." This would be in addition to User Acceptance Testing.

The first program I submitted in a shop like this was rejected for 38 reasons. Some were shop standards, but many requirements where I thought "I knew better". I didn't. And I've been a much better programmer ever since.

View on HN

In addition I would say, work where your code actually gets code reviewed. (is that a dying practice?) You will write better code.

I agree, and I fear that it is in fact a dying practice.

Well, I would hope that if you follow the first step (work as an apprentice), it would get you in the habit of requesting code reviews, even when you've entered "the guild."

It's also worth noting that code reviews should be two-way streets--that is, more junior programmers should review more senior programmers' code, even if for nothing more than a learning experience.

This is a disaster if the senior programmers are less skilled than the junior programmers. It happens a lot in big corporations. "You have more than one return statement! Go change that."

Of course if you work in a shop like that, it's advisable to leave. And I did.

I used to work where I would get skewered for misplacing the ; or about the formatting of my comments. After surviving that, I think I can survive anywhere.

One situation I was even worse; the "senior" programmers were actually juniors with nearly no experience, but who had office politics (i.e. nepotism -- one was the CTO's son) on their side.

Needless to say, the company didn't go far.

You have more than one return statement! Go change that.

Yep, that's one of the 38 reasons for my original rejection. Violations of "single entry/single exit" were not promoted into production. I argued and lost. Now I'm glad I did.

Just curious: Are you now a true believer in the "single exit always" doctrine (as well as whatever the other 37 rules were) or are you just saying that the benefits of enforcing discipline on the developers' output outweighed the disadvantages of having cargo-culted and dogmatic code standards?

I became a true believer once I got past my personal prejudices and actually made an attempt to understand "why" some rules were the way they were. I wasn't as smart as I thought. Still not.

Enforcing discipline for the sake of enforcing discipline? See military.

Code review meetings with projectors and so forth might be a dying practice (I wouldn't know), but there are tools like Code Collaborator that allow for asynchronous code reviews. CC seems to be widely used.

Reply on news.ycombinator.com