Hacker News Reader

There are other possible interpretations of this:

1. They disagreed with you about code quality. For example: Imagine your tool highlighted duplication across tests and pushed people into using things like rspec’s shared examples. People would disagree with (their interpretation of) you that duplication was worse than the wrong abstraction.

2. They were already overwhelmed trying to follow multiple rules from multiple people (PM, CTO, manager, team lead, various staff engineers) who all have conflicting ego-driven priorities.

3. They see rules not being followed by other people and consequently feel like they lack the skill to be the unique engineer who can simultaneously jump through all the hoops and execute fast enough to avoid losing their home by being judged as “the slow one”.

Your speculations don't really apply to this company but perhaps I wasn't clear - I wasn't saying the "speed above all" company was bad, or even that they weren't thoughtful. They made conscious choices to have different priorities and I didn't pick up on any of that. If there's a villain of the piece, it's me.

There are no villains but the ignorance of our former selves.

"You could get promoted by making another hoop for programmers to jump through." That's right outta something Douglas Adams would think up.

A junior designer joined my company.

He was introduced to Slack and Basecamp.

Working really fast, he got in trouble (and by that I mean about a 50 minutes brainwashing session) because he doesn't report "properly" the tasks he finishes and ticks off on Basecamp to his manager.

Your description makes the first company seem better in comparison until you stop to think the tradeoffs. There are always tradeoffs.

My previous role was in a team run like the first company. There were sky high barriers to get code into production, mostly centered around code reviews. It could take weeks to get the attention of enough people to review your code. Complex features had to be broken into multiple code reviews, and only people at your level or higher could review your code. So you ended up with a lot of code reviews and not enough reviewers.

The result? Politics. And where there is politics, there is corruption.

One time, one of my former team mates casually asked me to send him some Bitcoin if I wanted him to move faster. I refused, and the code review was delayed. Another team member stonewalled my code reviews as a retribution on an unrelated technical dispute.

It took me weeks to move through all my code reviews into production. I left the team immediately thereafter.

Be careful what you wish for.

Yeah, I was worried that I'd painted the second company as the bad guys. They were not. They made different choices. And both have been extremely influential in terms of process, but... influential at different extremes.

At the perfectionist company we were six weeks away from final release - for a year. On the other hand, that company's codebase almost brought me to tears with its conceptual unity and perfection. And some process was worthwhile for us; we were adding fintech features to a userbase of hundreds of millions.

At the speedy company we did social media, so there were way lower stakes. Projects turned around really fast. LAMP stack all the way. The attitude was that code would always be kind of sloppy and unpredictable, and there would always be unforeseen disasters. To cushion shocks like that, they invested a lot in their feature flag and deployment system.

These are both paths borne of wisdom and experience.

But here's where culture comes in. The culture at both companies was that these weren't choices that worked for them, but the optimal choice for everyone. At either company I think most people would think the other company's approach was not just bad, but literally impossible.

Even teams with good team cultures can screw up their processes.

In my experience, a bad process is one that 1) produces responsibility without accountability, and 2) does not account for process bottlenecks.

For what it's worth, such a feature is baked into IntelliJ IDEA now. It will yell at you for repeating blocks of code.

But not for multiple code bases. Or?

If they’re in the same “project” it will detect them.

This is also a good way to use IntelliJ because it makes it easier to do large changes that span many code bases / repos.

I've actually warmed up a bit to a bit of repetition in multiple repositories. There's overhead to packaging which is just not really worth it for fifty lines of code.

Is there something I could integrate in CI for Python code? It should pick up adversaries who change variable names and grandfather old copy paste code.

IMHO DRY is one of the worse things we teach new programmers, and is an anti-pattern for 80% of use-cases.

Creating an abstraction that makes no sense is worse than just having code being there twice (e.g. different codebases). I worked with a guy who would apply DRY to literally everything like it was a panacea. It was an awful time.

On the other hand, it’s also pretty bad to have a code base with a few iterations of “copy function; edit lightly; leave now stale comments untouched; replace some, possibly all, calls to old function with new ; do not delete old function ever.”

ctrl + alt + h on most ide's will list the callers of a function. It's pretty safe to repeat things and delete things, version control is a safety net.

I've done a lot of legacy work, and most repetition is due to a loss of business context. Naturally support staff don't want to be hero's and make big changes.

Right now I work with a system that's been in active development for 30 years and it's a dream to work on because everyone knows it and I can just ask some of the original authors what something is, or to explain an edge case.

Most dev's aren't that lucky.

> ctrl + alt + h on most ide's will list the callers of a function

that very much depends of how the function is called. there are a lot of ways I've encountered in the wild which wouldn't be found by this.

80% pulled out of thin air. If the logic is non trivial, always extract into separate function or file, because future maintainance not code reusability.

Read my post fully.

> Creating an abstraction that makes no sense is worse than just having code being there twice

The key point being 'that makes no sense'.

If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases.

This typically makes the original intent of the fn difficult to understand

Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them.

80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.

I recommend sharing this article: https://ericlippert.com/2015/04/23/dry-out-your-policies/

Mind that the free community edition does not have the "Discover Duplication" feature: https://www.jetbrains.com/idea/features/editions_comparison_...

It's interesting to approach groups that way. Finding what drives the things around and check for conflicts. I think we all have inner reflexes / ego / reference frames and it's important to state them smoothly and negotiate (constructive negotiation if possible) to find the best balance.

I've been very curious about these because I sense a lot of paradoxical behavior. People ranting about state of affairs but refusing solutions (because it clashes with some unclear principle they hold, often a pavlovian reflex that doesn't work well in large groups, only creating political issues in the long run)