[HN Gopher] On Trust in Software Development
___________________________________________________________________
On Trust in Software Development
Author : alexzeitler
Score : 20 points
Date : 2023-03-23 04:45 UTC (18 hours ago)
(HTM) web link (blog.ploeh.dk)
(TXT) w3m dump (blog.ploeh.dk)
| kvark wrote:
| There are small teams that are highly effective without PRs,
| given how little their owned areas intersected. Forcing the PR
| reviews there would only harm - any knowledge sharing is more
| effective at the whiteboard, anyway.
| re-thc wrote:
| Depends if effective means the code is not maintainable or is
| full of bugs or gotchas that will only be caught later down the
| line.
|
| PRs are good even if it's just within the small team as a way
| to peer review and have an extra pair of eyes.
| rektide wrote:
| Trust erodes, if we ongoingly have to step in & someone did it
| esnt seem able to eventually grok all the hurdles. So having
| systems that help automatically tell us of issues, that can be do
| the job, are really important.
|
| It was more an organizational rather than peer level concern, but
| I've heard some good discussion of trust being the currency of
| the profession. Feeling like you are adequately regarded, even
| though it's likely few others really see into your part of the
| faxtory floor. Being able to trust the org to make good choices.
| The article focuses on peer relationships & risk & getting good
| output, but I think the social factors around trust more broadly
| are at least as important.
| JohnFen wrote:
| I strongly dislike checking in code that hasn't gone through code
| review.
|
| I trust that I'm not doing anything malicious, but I am also
| aware that I'm a human being and make mistakes. Sometimes really
| dumb ones. I like running it past another pair of eyes that
| aren't intimately familiar with my code to minimize the amount of
| dumb that makes it into the final product.
| kerblang wrote:
| There's another kind of trust: _I trust the organization to
| prioritize core competency among staff and not use me as a crutch
| to compensate for that lack of effort by burning all my time
| reviewing crap programming work_.
|
| I think the discussion around reviews becomes more informed once
| you're past that hurdle.
|
| Also, as I've said before, architecture reviews yield 10x the
| value of reviewing programming logic.
| lapcat wrote:
| The author keeps equating code review with pull requests and
| gated check-ins. This is a fundamental mistake.
|
| Code review is fine and necessary. The problem is when a coworker
| can veto your own work, rather than just review it and offer
| helpful suggestsions. Pull requests are simply an artifact of
| certain version control systems that have somehow become
| pervasive to our entire software methodology. It doesn't have to
| be that way.
|
| It's not a question of trusting in perfection. Of course everyone
| makes mistakes. But do you trust your coworker to not be overly
| pedantic and opinionated, to not get in your way and block your
| progress? You shouldn't necessarily trust that either.
| eterm wrote:
| I absolutely trust my co-workers to not be overly pedantic and
| opinionated.
|
| If they were, I would raise it with my line manager and try to
| get the issue fed back to them.
|
| What kind of workplace do you not trust your coleagues to be
| reasonable?
|
| I don't trust myself nor anyone to not make mistakes or have
| blind-spots that pull requests and code review helps catch.
|
| Here's an example from today of an issue caught code review,
| that could have been a bug that easily slipped through testing
| only to become a hard debug issue months or years later:
|
| "You're assuming the order here, but it should be set
| explicitly".
|
| Caught by the reviewer, and easily fixed in seconds.
|
| But that could have been a really expensive bug to fix later.
|
| And it wasn't really through a lack of competence, just an
| oversight because the data wasn't necessarily sorted at that
| point.
|
| And the gating helps enforce and audit that code is reviewed,
| that everyone can go back and read the reviews to understand
| the journey the code went through. If there's later a bug in
| that area, there are now two different people I can know to ask
| first about that code.
|
| Making code review optional is a good way to get it waved
| through with little oversight.
|
| Having the people who okay the request share responsibility for
| fixing that code is a good way to motivate better code reviews
| as well as share knowledge.
|
| Why would a coworker want to block your progress? Maybe I've
| never worked anywhere toxic enough to understand.
___________________________________________________________________
(page generated 2023-03-23 23:00 UTC)