6 ms·

I've run into issues of programming culture many times. I once joined a team that had tremendous amounts of copied code. I got a bit fed up with fixing the sam

by neilk 5y ago

I've run into issues of programming culture many times. I once joined a team that had tremendous amounts of copied code. I got a bit fed up with fixing the same issues across multiple files, so I created a tool to flag files with copied code in the codebase. This would have made me a hero at my previous company. The encouraged you to have a low programmer ego, and be very concerned with quality. Teams were often weirdly eager to try anything that could plausibly improve code. You could get promoted by making another hoop for programmers to jump through. But the new company had programmers with rockstar egos, and thought following rules were for losers. They valued how quickly they could get code from a programmer's editor into production, and organized everything around that metric. Introducing an automated code quality tool, that from their perspective, slowed things down and pointlessly blamed some people as lazy? That didn't make me popular. Programming culture is really an underrated aspect of the job. I'm not remotely as good as Dan, but I've also had a pretty varied career. I think many programmers, even if they job hop, spend their whole careers in the same sort of company. So they don't even know what else might be possible.

fartcannon 5y ago
"You could get promoted by making another hoop for programmers to jump through." That's right outta something Douglas Adams would think up.
- barrenko 5y ago
  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.
emodendroket 5y ago
For what it's worth, such a feature is baked into IntelliJ IDEA now. It will yell at you for repeating blocks of code.
- aitchnyu 5y ago
  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.
- carschno 5y ago
  Mind that the free community edition does not have the "Discover Duplication" feature: https://www.jetbrains.com/idea/features/editions_comparison_matrix.html https://www.jetbrains.com/idea/features/editions_comparison_...
- vincnetas 5y ago
  But not for multiple code bases. Or?
  - caffeine 5y ago
    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.
  - emodendroket 5y ago
    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.
- laputan_machine 5y ago
  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.
  - karatinversion 5y ago
    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.”
afarrell 5y ago
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”.
- neilk 5y ago
  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.
  - afarrell 5y ago
    There are no villains but the ignorance of our former selves.
agumonkey 5y ago
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)
picardo 5y ago
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.
- neilk 5y ago
  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.
  - picardo 5y ago
    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.

by neilk 5y ago

fartcannon 5y ago

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

barrenko 5y ago
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.

emodendroket 5y ago

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

aitchnyu 5y ago
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.
carschno 5y ago
Mind that the free community edition does not have the "Discover Duplication" feature: https://www.jetbrains.com/idea/features/editions_comparison_matrix.html https://www.jetbrains.com/idea/features/editions_comparison_...
vincnetas 5y ago
But not for multiple code bases. Or?
- caffeine 5y ago
  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.
- emodendroket 5y ago
  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.
laputan_machine 5y ago
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.
- karatinversion 5y ago
  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.”

afarrell 5y ago

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”.

neilk 5y ago
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.
- afarrell 5y ago
  There are no villains but the ignorance of our former selves.

agumonkey 5y ago

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)

picardo 5y ago

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.

neilk 5y ago
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.
- picardo 5y ago
  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.