Hacker News Reader

Comment by icebraining | Hacker News Reader

Besides scandox's comment, where do you work that you can actually do that and get away with it? Where I've worked, a programmer who did that might get to decide a few things unilaterally, but not for long.

View on HN

I'd say 40% of the time of my career I've been in a place where my ideas were valued and I felt like "part of the team" as a programmer, and later as a programmer/manager. Those places I stayed the longest. They make up 15% of the number of companies I've worked for (my résumé has a lot of places on it..ha!).

The rest of the places I was beaten down, much like the programmer in this story. Unlike that developer, though, as soon as I started to feel like the only skill I was valued for was raw programming I started looking for another job.

Good leadership is so hard to find!

... which is why my position is HTTP 402 "PAY ME AND I WILL SCREW A LIGHT BULB"

Reviewer feedback (high priority):

    @@ -1 +1 @@
    -I WILL SCREW A LIGHT BULB
    +I WILL SCREW IN A LIGHT BULB

It is just a question of price.

In my comment I am describing the culture at my former employer -- a culture that led to processes where you had to get your manager's permission to check out a file before you could modify it.

This happens if your superior doesn't critically evaluate anybody's work, and there are no code reviews. So if there's no feedback culture. At my company, my superior sometimes writes emails regarding commits, but since he doesn't write that down (waiting-for list in GTD) I figured that I can simply ignore the emails, and nothing happens. The result is cowboy coding.

My experience with code review is that code reviewer is the one holding the power and refuses to accept code until it does what customer did not wanted.

If you have position without checks, including code reviewing, it will be abused.

This is an unfortunate experience. The best environments I've seen have a core value of respect for others, and code reviews exist to benefit not just the customer but also future programmers (which also ultimately benefits the customer but in more indirect ways, such as reducing cost of change). The absolute best are the ones where the reviewer is giving advice, but can't hold back integration. Much less threatening circumstance. More collaborative.

The best reviews that I have experienced are side-by-side reviews with the author walking the reviewer through the code. The author finds most of the bugs; the role of the reviewer is to force the author to cover all the ground; asking questions where he does not understand something.

Reply on news.ycombinator.com