Culturally transmitted skills and values

by ramimac • 5 years ago

205 85 5 years ago

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.

itsmemattchung• 5 years ago

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.

bawolff• 5 years ago

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"

bsder• 5 years ago

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.

bopbeepboop• 5 years ago

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.

ralmeida• 5 years ago

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

wence_ipon• 5 years ago

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.

dexterdog2• 5 years ago

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

quickthrower23• 5 years ago

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

eloisius2• 5 years ago

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.

rectang• 5 years ago

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

quickthrower23• 5 years ago

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.

caffeine3• 5 years ago

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.

stared• 5 years ago

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.

bedobi3• 5 years ago

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.

throwawaythekey• 5 years ago

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.

AlotOfReading• 5 years ago

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.

jerf• 5 years ago

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

zz865• 5 years ago

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.

mirekrusin• 5 years ago

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

bedobi3• 5 years ago

Not according to Uncle Bob

8note• 5 years ago

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

tharkun__2• 5 years ago

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.

henning• 5 years ago

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.

neilk3• 5 years 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• 5 years 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• 5 years 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.

emodendroket4• 5 years 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.

vincnetas• 5 years ago

But not for multiple code bases. Or?

aitchnyu2• 5 years 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.

laputan_machine2• 5 years 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.

carschno• 5 years ago

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

afarrell3• 5 years 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”.

neilk3• 5 years 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.

agumonkey2• 5 years 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)

picardo2• 5 years 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.

neilk3• 5 years 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.

makeitdouble• 5 years ago

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)

oreally• 5 years ago

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.

emodendroket4• 5 years ago

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.

bhouser• 5 years ago

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

m0zg2• 5 years ago

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.

uyt• 5 years ago

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)?

mettamage• 5 years ago

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

Leetcode problems require you to know that.

smorgusofborg• 5 years ago

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.

specialist• 5 years ago

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.

SergeAx• 5 years ago

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

temikus• 5 years ago

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.

ksec• 5 years ago

I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That's a slap in the face to anyone who writes software for a living. ... It's a shame you have to do so much pre-screening to have the luxury of interviewing programmers who can actually program. It'd be funny if it wasn't so damn depressing

Not sure if I should be happy or sad by this. Because I still dont think I can program at all. And I think part of the reason why FAANG ( or are they called MAMAA now ? ) are paying $200K for fresh grad and yet other there are part of US paying sub $100K. The range of qualities in terms of programmer is far too wide.

KingOfCoders• 5 years ago

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.

roca• 5 years ago

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.

tomerv• 5 years ago

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.

thrashh• 5 years ago

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.

afarrell3• 5 years ago

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.

sleepysysadmin• 5 years ago

So I was a sysadmin scripter(powershell/cmd/bash) then network admin, then infosec. Ive really blown up using python for all kinds of things last few years. I've built a whole honeypot -> threatfeed project. More recently I built a solarwinds ncm replacement(solarwinds got pwned) almost entirely in python. Long story short, it downloads config backups of network devices and then can programmatically report on security hardening guide rules.

I work alone so my extent of 'culture' has been pycharm warnings. I imagine if another programmer saw my code they'd vomit so violently they'd have to buy new electronics.

I try to do the right thing, but PEP 8: E501 line too long (125 > 120 characters) I'm not really caring too much about being 5 characters too long. I tend to comment my code well but there's certainly areas where there's nothing because the comments wont help much.

Yet what ego do I have to get in the way? I know I'm not a programmer, I know there's tons of room for improvement. Its just... I don't know what I don't know. I feel this article speaks to me but I don't really have a mentor :(

Edit/ just ran pylint against one of my projects. It fell over laughing.

Culturally transmitted skills and values

Related Stories