Hacker News Reader

Comment by anthomtb | Hacker News Reader

This hypocrisy reminds me of one of my former lead developers. He required everyone on the team to go through multi-person code reviews and pass an extensive CI suite before merging changes into our mainline.

But him? Half that time he'd approve his own changes without review, the other half he would force-push and bypass the CI system entirely.

He knew the system well and seemed to do enough local testing to avoid major breakage but still. Why have a bunch of rules and policies that you do not follow yourself?

View on HN

He knew the system well and seemed to do enough local testing to avoid major breakage but still. Why have a bunch of rules and policies that you do not follow yourself?

Because these rules and policies are for people that are judged to need them by the person with the authority and responsibility for making the decision.

Policies like these always have a cost and (hopefully) a benefit. Presumably this lead dev judged that the cost vs benefit didn't make sense for themselves but did for others. It's entirely possible they were correct.

One of the main purposes of code review is to ensure that your code is understandable to other people. Good lead developers understand this. Bad ones find a way to push through their changes without review or get them rubber stamped, in my experience. Then you end up with big parts of the codebase that only the lead dev can work in productively.

the whole team has to review every single line of code to make sure everyone understands it? or is there a threshold like “we good if 7 out of 79 understand it?” almost 3 decades hacking and have never heard anyone saying that purpose of the code review (in the top 987 reasons teams may institute it) is to ensure your code is understandable by other people… wild :)

This page is literally the second result when you Google "benefits of code review":

https://www.browserstack.com/guide/code-review-benefits

> Code Review enhances the maintainability of the Code. It ensures that multiple people are aware about the code logic and functioning, which makes it easy to maintain in case the original author of the code is unavailable.

The fact that you've been "hacking" for three decades and never considered this isn't something to wear as a badge of honor. As for your absurd straw man about everyone on the team reviewing every line of code, I've never seen one organization that does that.

are aware about the code logic and functioning

awareness does not imply understanding :)

No, but it's a minimal threshold. In the end, following the same rules prevents you from doing dumb mistakes and prevents a feeling of unfairness such as OP felt. And, if you can't follow your own rules because they're too annoying, maybe you should change them. So, really, there are multiple benefits. Just follow the rules.

which rules specifically are you talking about?

The rules of the code review that the top level OP was talking about.

As long as authority and responsibility land on the same person, I see no problem with it.

If, however, a junior develop is responsible for making a change, but has no authority to make the change, then there is a problem.

Code reviews are often used as an excuse to disclaim responsibility when problems occur, and as a way to deny authority under the guise of mandatory review requests. They do also have many benefits for e.g. continuity of service, but those two drawbacks remain relevant today.

lord help all people that work in places where you need “authority” to make a change…

Rules are to be followed by everyone without exception, otherwise they should not be called rules.

> Why have a bunch of rules and policies that you do not follow yourself?

If you can get away with it, why wouldn't you set things up this way? Rules for thee, not for me. You can't try to view power plays like this through the lenses of ethics or morality. The point is to use rules to bind and punish your enemies and to make sure that only your friends can get away with breaking them. You do this with media capture and twisted narratives, taking advantage of the erosion of rule of law as a respected concept among the public.

I think it's more likely a trust issue. He didn't trust the other devs to push things directly, but ofc he trusts himself. I do this with somethings myself. But I also do the inverse, where I don't want to trust myself so I setup a bunch of checks and tests to save my future self from my present self

I think when you're the 'architect' or know the full stack very well, to where you fully repl/grok it and occasionally need to do hot patch type work, the former approach is nice. But, my brain has limited memory and time erodes quickly, so I also know when to rely on the latter approach and I try to do it as much as possible

That's a real difference when something is your final responsibility too (as team lead or an architect). You think of it differently, you predict and anticipate changes better. It's like taking care of your kid vs your kids friend.

That’s the definition of authoritarianism.

> If you can get away with it, why wouldn't you set things up this way?

Ethics and morality.

> You can't try to view power plays like this through the lenses of ethics or morality.

Yes, you can, that's the entire point of ethics and morality.

> The point is to use rules to bind and punish your enemies and to make sure that only your friends can get away with breaking them.

Well, yes, that's the point of the specific actions being discussed; that doesn't make it impossible to look at them through a lens of ethics and morality, it just makes them look bad through such a lens.

Perhaps rather than "can't try to view" it's more accurate to say that it's an ineffective lense to try to understand the motivations and dynamics at play. You can, and should, analyse the ethics of just about everything in order to make value judgements. Those judgements just have very little to do with people's motivations, and to assume a principled moral stance on the part of an observed actor will leave you baffled more often than enlightened.

Power is less appealing if you aren't seeking to abuse it. I agree that an ethics and morality lens is both useful and necessary, but I fear it doesn't illuminate the actions and motivations of the powerful. Perhaps in contrast or relief, but not directly.

I think he could have just been a bit lazy.

You want a better outcome.

Culture transmission is more effective when followers can emulate leaders — so you’ll have an easier time getting people to obey when your goal is to get them to act the way you do. In this case, you’ll expend less political capital on enforcing your policy regarding code reviews and testing if you adhere to the same policy. (And accordingly, have an easier time avoiding disgrace like public failures if your service.)

If you want to view it purely through the lens of power politics, saving your political capital on issues like this preserves it for things with better rewards — eg, you’ll have an easier time getting your projects approved if your manager isn’t constantly having to deal with the fallout of your policy double standards impacting morale. Or for setting a standard that working fewer hours is acceptable if you’re meeting your quotas — which nobody can dispute you’re doing, as the whole teams is validating that you are.

This kind of petty power game is rarely an optimal exercise of power.

Apples and Oranges? If he is the person responsible should a system break then it's totally up to him. In that case, he made sure you did not break his system (because he'd be responsible). And if he broke his system himself then it's on him.

I don't see a problem with it (as long as he can't transfer the blame somewhere else).

The example you give is about control - he wanted control over everyone else's inputs but trusted himself. Not a great look as a leader.

That’s one of the reasons I always worry about high level employees who “still write code”. It’s just too much opportunity for them to make bad choices and many ICs are afraid to speak up to avoid it.

Same goes for some “10x developers” who are fast because the rules don’t apply to them. Meanwhile the rules slow everyone else down (yea big surprise he is faster). And everyone else has to clean up after these guys when they get sloppy.

My personal pet peeve is network admins that have unfettered Internet access from their workstation IP, but everyone else has to traverse half a dozen “security” appliances that break developer CLI tools and slow down everything else.

I relate to this a bit...

But for me the foundational issue is that my coworkers aren't holding up the bar when reviewing contractor code. And reviewing all the code isn't my job description.

Meanwhile my job description does include maintaining a system my coworkers don't really know anything about, and so I mostly make sure it's tests pass and let me manager know about anything I need to do to it.

>Why have a bunch of rules and policies that you do not follow yourself?

Because the goal is to keep risk to a reasonable level, not necessarily minimize it as much as possible.

Another interpretation of this is that the lead developer adequately mitigated the risk of errors while also managing the risk of not shipping fast enough. It's very easy to criticise when you're not the one answering for both, especially the latter.

As one such developer, it is a powerful ability to be able to bypass restrictions meant to be used sparingly for a good reason

I rarely commit the same kind of code the full time professional developer do(when bypassing policies).

Typically it is stuff like urgent patch in prod that may not have coverage , or partial long running refactor which breaks existing tests but better to be able merge quickly than keep the branch constantly free of merge conflicts , or experimental exploratory new type of code(new lang , stack whatever )for which we have to yet evolve processes, part of what the lead is supposed to be exploring and so on.

Although In my experience junior leads more often than not abuse their privileges than use it well.

At least he knew the system well, this is more akin to a bunch of junior devs writing an app by editing their code on a shared plain text file

I’m not seeing the parallels.

Trump went on about Hillary’s mail and made it a big thing for political points, not because he was particularly caring or didn’t have infamously bad opsec when he got in.

You lead dev trusted himself more than the team. He was probably right.

The parallel is senior leaders ignoring secure communication rules that their rank-and-file must follow. Hillary's email server did not immediately spring to my mind.

Edit: Its safe to say that this story involves multiple levels of hypocrisy by the current administration.

You're correct that Trump's entire cabinet are hypocrites and they deserve to be raked over the coals for this and have their past statements thrown back in their faces. At this point there's no reason to believe Trump or anyone in his circle ever saw the email scandal as anything but a cudgel with which to rhetorically bash their opponents.

But the problem with them being hypocrites in this regard is that it follows from them doing the same thing Hillary did, and in that case the "fair" way to punish them would be the same way she was punished, which is not at all. So I don't see any real accountability ever coming from this beyond maybe trump firing a couple of sacrificial lambs from his administration.

Reply on news.ycombinator.com