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.

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.

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.

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

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.

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

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.

But not for multiple code bases. Or?

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.

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.

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)

> Process: don't allow anyone who's late into the meeting

Amount of people being late goes up once they realize they can skip stupid meetings simply by being "late"

As someone whose calendar is often wall to wall, this is really stupid. The fact that I'm two minutes late because I'm a biological creature and need to piss occasionally doesn't mean I should be excluded from critical discussions.

Being late is seen as lame, but leaving the preceding minute early is seen as badass - do that instead.

>leaving the preceding minute early is seen as badass - do that instead.

I worked in one organization where leaving early was disrespectful. Being late was a "flex" move done by leaders who were "super busy".

I'm not saying that is right. I'm just saying that is how it was viewed.

If the CEO of a company says they need to go to the next meeting that's not a flex.

Why not politely state the reason and leave?

How much faux-flexing is done in large corps ? it seems everybody is trying to inflate reality to impress or protect from the people around.

Sounds like a decent back-pressure to take more control of your calendar to me. I’m the kind of person who is almost always on time and it annoys me to no end when the first 5, 10, 15 minutes of a meeting are spent piddling around or catching late arrivals up. Leaving other meetings early feels more risky but it’s also more proactive and doesn’t waste other people’s time. At least they aren’t stalled waiting on you to show up.

The other meeting last 10 minutes is not necessary pointless waste of time. That is when the tasks are split final decisions made.

The issue here is in scheduling. Forcing people to leave other meetings early is no different then coming late to this one.

And at minimum, by the start of the meeting you can choose which topic to start with.

I disagree. It is different because showing up late effectively robs another group of people of their time. You can always say, “hey I have to duck out at a quarter til, so…”

In any case, it’s probably best to make all meetings 50 minutes long instead of scheduling in blocks of hours. I always set speedy meetings on in Google Cal.

> It is different because showing up late effectively robs another group of people of their time.

In a way that is no different then leaving sooner. Missing start is no more harming then missing end.

Plus, if it robs so much, then check out with people prior organizing it. Or whoever is organizing the meeting should. In an ideal world, the meeting that was scheduled second without regard of already existing schedule should be one where people miss part.

> it’s probably best to make all meetings 50 minutes long instead of scheduling in blocks of hours.

Imo, ideal is to have maximum run time determined. It is perfectly ok to have and schedule short meetings.

That's why all meeting should end at least 5 minutes before the hour or half hour.

I've tried this. Personally, I still forget the meeting is supposed to end. I'm trying to start meetings 5/10 minutes LATER.

The problem with that is that external meetings will still start on the :00/:30 so your overlaps will be a problem or you'll lost another 5 minutes from your internal meetings when anybody on the call bumps against a :00. Besides if you start all of your meetings at :05 as a company you'll still have people wandering in at :07.

This is the right answer, mostly because no one ends meetings intentionally at 5 minutes after the hour. However, even calendars that support "short meetings" don't seem to support this.

They should have Bells, like school.

The Lesson of the Bells is that nothing is worth finishing.

Lunch is worth starting.

I think not allowing late people in is bad, but ruthlessly starting on time (with no “catching up” people who are late or revisiting decisions) is good.

As a person with ADHD, I hate the rule "no one is allowed after time" - unless it is a symphony. Plus, it often backfires - sometimes a crucial person is missing, and people need to wait, or the meeting makes no sense.

Still, starting sharp on time is essential. Once it is done often, people learn that they will miss important stuff when they are late. Allowing to start later often makes people show later and later.

I have no problem with this, actually. If only people would actually take advantage of this.

One the banes of good meetings are people who don't belong in your meeting but whose feelings will be hurt if they aren't invited.

I quit a job because a manager made it insufferable by insisting he be invited to every developer meeting, then interrupting with useless tangents and requests people explain things to him.

You'll get better mileage by just setting the default meeting length to 45 minutes rather than an hour in your calendar software.

15 is a good default. You'll soon extend it if you get a gut reaction 'that's not enough'. More likely than you'll shrink a longer meeting to 15 if it defaults to 45 or 60.

We had people do this. It sounds good in theory but in practice you wind up scheduling the next meeting 45 minutes later because you know the first one will run over.

The second or third time the “boss” rolls into a meeting 30 minutes late, you go look at his calendar and realise somebody scheduled a 1 hour session as a 15 minute catch-up.

Meeting discipline is also needed for 15 min meetings to work! This and good estimation skills. Ideally meetings would be planning things in advance that scheduling a follow up isn’t the end of the world.

Fair enough, but in many cases some attendees attend only by inertia and would be better off declining instead anyway. Which is probably good overall if the meeting is indeed "stupid".

> I do know of two cases of "fake programmers" (...) the person was able to sneak under the radar at Google for multiple years before someone realized that the person never actually wrote any code and tasks only got completed when they got someone else to do the task. The person who realized eventually scheduled a pair programming session, where they discovered that the person wasn't able to write a loop, didn't know the difference between = and ==, etc., despite being a "senior SWE" (L5/T5) at Google for years.

I thought this only happens in tv shows. Was it more like Big Head from HBO Silicon Valley (the company forgot about the employee) or Frank Abagnale from Catch Me If You Can (conman who managed to fake his identity and credentials)?

I've seen this. Decades later, I still don't know how it happened.

Civil engineering company hired CAD savvy engineer. A rarity back then. Jared. Then sent him to advanced training. Before his first day in office. Then bought him the best gear, including extra monitor and custom desk. Which caused a little bit of resentment, of course. (New hires generally got hand me downs.)

Second day on the job. Yay, welcome to the team. Jared got his machine booted. Pulled up a drawing. Stared at the screen for a while. Then he asked me how to draw a line.

Smart ass me: "Ell eye n e, then hit enter."

Jared presses the keys, repeating the letters out loud, hits enter. Then says "LINE. Oh."

The rest of the drafters and engineers looked up, unbelieving.

Jared was also adept at sloughing his workload and tasks onto others.

I'm now remembering some other Jared stories.

Jared tells me his machine is broken. He kept erasing a line. And when he did 'refresh', the line was still there. Of course I debug. Turns out Jared had made dozens of copies of his entire design, in exactly the same location. So he was just erasing the top instance, one at at time.

Remember acoustic ceiling tile? Jared was adept at flicking pencils up so they'd stick in the ceiling, like darts. One of his hobbies. He'd lay multiple pencils flat in his hand. Then kinda slapped that arm against the other hand. Jared proudly claimed his personal record was something like 4 pencils at once (successfully stuck in the ceiling).

Remember when GIS systems were the new hotness? Jared scored a job at the county, becoming the director of GIS systems. I'm sure if any actual work happened during his reign, it was accidental. Our tax dollars hard at work.

Big Head from "Silicon Valley" actually coded a working MVP of Nip Alert.

Worked at Google. Wouldn’t doubt this story for a second. Met a ton of amazing people at google but also some _very_ interesting characters. Ratio of good-to-questionable has been pretty good though, so can’t complain.

How do you get past the interview stage if you don't know the difference between = and ==?

Leetcode problems require you to know that.

Google seems to limit people to testing in a few similar abstracted assembly languages, but they buy out startups which might be using languages that discourage these simple loops, reassignments, etc that "every programmer uses".

So quite possibly this was a perfectly good architect/programmer from a successful product who was turned into a C++ engineer on paper but never actually accepted the new role and only continued to architect.

I'm stuck on the first few paragraphs. It's clear that the author is heavily biased again anything-that-is-not-culture, and therefore gives really bad examples for non-cultural solutions. It's easier to convince everyone you're right when you give the worst possible alternative solutions.

> Incentive: dock pay for people who are late

There are much better incentive-based solutions. For example: - Managers reprimand employees who are frequently late. - Positive incentive for physical meetings: have a nice fruit bowl with just enough fruit so there are no leftovers for anyone who's late.

> Process: make process for creating or executing on a work item so heavyweight that people stop doing simple work

Better process-based solution: every employee has a "big" item that they work on, with planning weeks/months into the future, and syncing occasionally with their manager and/or peers.

I still find that there isn’t a true replacement for the right culture. Culture has wide ranging effects on how someone does everything, while a process only tackles one specific issue. You can’t make up enough processes to cover all cases as that results in overbearing bureaucracy.

I’ll usually interview a company for at least a hour before I consider taking their offers seriously just to identify the type of culture that they have.

> debug a bug that takes more than a couple hours to debug because engineer time is too valuable to waste on bugs that take longer than that to debug, an attitude this person picked up from the first team they worked on

Depends on where you live in the stack and the impact of the bug. Critical bug causing customer impact? You bet you are going to have tons of (senior) engineers jump all over it — bug will get squashed, fast. Low impact impact ... they tend to get backlogged, very rarely revisited. Definitely context dependent.

For some start ups I've worked with, there's a move fast and who cares if it breaks mentality. At AWS, I was on a more critical, mature networking team and while speed was important, correctness (and lack of bugs) were valued much higher.

> Culture: people enjoy building complex systems and/or building complex systems results in respect from peers and/or prestige

Seems great for architecture astronauts. Maybe they'll stay long enough to eat their own crap. In the meantime, I'll keep in mind to stay away from such companies.

In case it didn’t occur to you: I think this was put forward as an example of culture producing negative outcomes.

Dan is actually referring to Google where "complexity" for a very long time was an explicit requirement for career progress to Staff level and beyond.

I bet it's the same way even now, unofficially. For better or worse, engineers do not seem to sufficiently value simplicity, so people hated the rules, but played the game, producing insane rube goldberg like backends all over the place that you need whole teams of experienced SREs to run successfully. The fact that this is ridiculous was not at all lost on people either - memes on Memegen (an internal meme site) were pretty vicious. But, not a heck of a lot you can really do if you want those golden handcuffs to turn into platinum ones.

I'd be remiss if I did not mention the silver lining in all this: Google's SRE team is very likely the most experienced in the world, and SREs are respected there. Stuff wouldn't run at all if this wasn't the case, and certainly not with five nines of reliability.

Another bullshit requirement in the general case is "cross-team impact". No matter how valuable you are as an IC, you gotta get a bunch of other people involved so they write your peer feedback and endorse you for a promo. Sometimes this makes sense. Often it does not. And those people better be one or two levels above you, which is a problem in a remote office.

There was a whole slew of antipatterns like that which might have made sense at some point in the past, but now are perceived as an immutable thing nobody can do anything about. So in a way, "culture" is not necessarily an _universal_ good, although at the time I was there the good outweighed the bad IMO.

This cultural stuff is also why Agile by itself does not mean you'll be particularly "agile", nor is Agile required for high agility. As a manager I've found that if I can get people to care about things and give them autonomy, most of them will not require close supervision and will move faster than they'd otherwise. Some will require supervision, reminders, incentives, and all that, and those are best sequestered from the rest and grouped with folks with similar working styles and put to work on tasks that tolerate that kind of thing, or in clinical cases let go.

It is the same now, and officially so. One of the dimensions for perf/promo is complexity.

IIRC it is still for "Software Engineers" but it has been replaced with Simplicity for "Site Reliability Engineers". Of course just changing the written rules doesn't change everything, and it creates an interesting friction.

Sadness. There was a period of time when upper management knew this was a problem and tried to do something about that.

I would hope nobody wants complexity for its own sake, but I do think there's something to be said for not shying away from a problem just because the only way to solve it is complex.

Incentivizing people to create complex systems sounds really scary to me. I guess there's an implied "where the complexity is absolutely necessary", but anything that approaches rewarding people for complexity sounds to me like one of the worst things you could for a software development organisation.

That process solution for getting people to meetings on time. I'd expect the meeting times to be changed to have more affordances for say, going to the bathroom between meetings, or the elevator being busy. A proper process solution says that the process is the problem, not the people using it

I see Google tried to 'address' this by having an option to make meetings go 5 minutes less than the "full" standard length. 30 minutes becomes 25, the hour meeting is 55 minutes.

My experience, which matches exactly what I would expect from a technological solution to a people problem:

Nobody cares, meetings still go 5 minutes too long instead of ending 5 minutes early.

If at your company nobody keeps the time to the regularly scheduled time, nothing will change! It takes people actually keeping the time box of the meeting to change any of this. Be the guy that says "2 minutes left" 3 minutes before the end of the meeting. End your own meetings early by saying "running up on the time box, 2 minutes left" when it's 5 minutes to the end of the meeting and actually ending it. If nobody does that, nothing will change.

These examples at the start are great. I read the first thinking it was a bit silly and contrived but it worked super well to prepare for the second which was succinct but sounded familiar and then the third which sounded relevant to businesses but more positive and constructive than the first two.

> Bob Martin saying "The solution to the software apocalypse is not more tools. The solution is better programming discipline."

A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm).

I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude.

Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason

https://softwareengineering.stackexchange.com/questions/3202...

Which caused the big OSX/iOS SSL bug in 2014, see https://www.imperialviolet.org/2014/02/22/applebug.html

This link and thread on hackernews is good too

https://news.ycombinator.com/item?id=15440848

    The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time).

    Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it.

    But of course, that stupidity fell out of favor. After all, when mistakes kill, people are serious about it. After a while, serious people realize that blaming and clamoring for care backfires big time. That's when they applied, you know, science and statistic to safety.

    So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it's more. They figured out what trainings and processes provide high impacts and do them rigorously. Nurses are taught (I am not kidding you) how to question doctors when weird things happen; identity verification (ever notice why nurses ask your birthday like a thousand times a day?) got extremely serious; etc.

    My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.

One of the things I love about software is that if you put your mind to it, you can have some of both. You can have both the culture and the process, because with software, we can create cultures of encoding process into automated procedures, like continuous integration and strong automated testing suites.

This obviously doesn't completely solve the "culture or process?" question on its own. I just enjoy software for having a relatively unusual place where the two can be overlapped. I'd have a hard time going into any other engineering field where I lost unit tests, they're so integrated into how I think.

I actually kinda consider myself personally not all that strong with processes... but you wouldn't know it to look at my output because I put the processes in my code.

(This is also one of the reasons I find the slowly-but-not-slowly-enough dwindling obsession with claiming programming isn't a "real engineering discipline" to be silly. We don't do what all the other engineers do because we have quite a lot of options that are better than what other engineers do. Sure, if you're a "senior" dev who has never heard of a unit test, you may be cowboying it too much, but, I mean, other engineering disciplines would murder for some of the processes we can create around quality.)

It's not really fair to call craftsmanship toxic. The obvious local maximum is to embrace craftsmanship on a personal level and profit from the tooling of others (preferably outside of your own company).

Wait... maybe that is toxic.

There's nothing wrong with craftsmanship and it can coexist happily with what's described in the GP. Most of the engineering marvels of the early 20th century were done with an abundance of incredibly skilled craftsman running machine tools and process controls.

The toxicity is in blaming an inherently fallible human for having the audacity to be fallible. It's not productive, it's just an intellectual dead end.

This. Everyone, even the best, most experienced people, can and do slip and make outright mistakes.

If someone's answer to that is "just don't slip or make mistakes", well... I don't even know what to say to that, it's so dumb it can't really be meaningfully responded to.

It's the combination of things if you ask me.

I'm out of car analogies today but how about a software analogy?

"just don't slip or make mistakes" makes sense as an "Acceptance Criteria".

The implementation details of that? I minimize my mistakes and slip ups by doing things like always fully curly-bracing all of my if-statements and actually enforcing it through a linter that doesn't let me merge any code to master that doesn't adhere to this rule, because it'll make the build red and our repo doesn't allow me to merge anything that doesn't have a green build and I can't push directly to master.

Do I still slip up sometimes? Sure, the build catches it. The slip ups this doesn't catch? We try to find implementation details that reduce those slip ups too. Rinse, repeat.

If you slip up as a manager/team lead? Show your developers. Show how you handle it. Lead by example.

In our team(and i suppose in most places), the maxim to follow is to make novel mistakes. Making the same kind of mistakes is frustrating for both users and developers.

Yeah I like his book in general, but all the gurus usually work on their own or dip into projects. I'd love to see him in a typical code base that was written by a bunch of people that left years ago and a manager that wants new functionality tomorrow.

Linter or compiler should warn/error on unreachable code in this example, shouldn't it?

Not according to Uncle Bob

> But if we look at quantifiable output, we can see that, even if processes and incentives are the first-line tools a company should reach for, culture also has a large impact.

This split between incentive, process and culture doesn't make me comfortable. I think culture and processes emerge from incentives, and incentives are not just what the company signals (pay, perks) but also the effects of actions.

For instance if reducing bugs brings company wide fame, money and makes everyone's work visibly better, people will spend more time on avoiding/fixing bugs, and a culture of quality will impregnate the teams. Process will be adjusted accordingly when they don't align with that culture.

Someone moving to another job might bring that culture with them, but we know it will disappear if the incentives are completely different in their next job (if shipping 2 weeks faster and fixing bugs afterwards make a ton more sense, they'll adapt)

These three things also influence each other. Incentives act as a signal of the type of culture you want to incentivize. Process allows or blocks people from following that culture.

Seeing leadership create processes and incentives that align with the stated values of a culture builds trust that those stated values are authentic.

What I'm amazed over and over again is the culture of children. Songs, rhymes, games are transmitted from kid to kid and stay the same over the years, without them being teached by parents. Although kids quite fast grow out of this the culture only moves very slowly.

> When debugging a bug like that, there will be numerous wrong turns and dead ends, some of which can eat up weeks or months

Warning: doing this at a startup will get you fired.