Culturally transmitted skills and values

I&#x27;ve run into issues of programming culture many times.<p>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.<p>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.<p>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&#x27;s editor into production, and organized <i>everything</i> around that metric. Introducing an automated code quality tool, that from their perspective, slowed things down <i>and</i> pointlessly blamed some people as lazy? That didn&#x27;t make me popular.<p>Programming culture is really an underrated aspect of the job. I&#x27;m not remotely as good as Dan, but I&#x27;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&#x27;t even know what else might be possible.

&gt; Process: don&#x27;t allow anyone who&#x27;s late into the meeting<p>Amount of people being late goes up once they realize they can skip stupid meetings simply by being &quot;late&quot;

&gt; I do know of two cases of &quot;fake programmers&quot; (...) 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&#x27;t able to write a loop, didn&#x27;t know the difference between = and ==, etc., despite being a &quot;senior SWE&quot; (L5&#x2F;T5) at Google for years.<p>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&#x27;m stuck on the first few paragraphs. It&#x27;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&#x27;s easier to convince everyone you&#x27;re right when you give the worst possible alternative solutions.<p>&gt; Incentive: dock pay for people who are late<p>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&#x27;s late.<p>&gt; Process: make process for creating or executing on a work item so heavyweight that people stop doing simple work<p>Better process-based solution: every employee has a &quot;big&quot; item that they work on, with planning weeks&#x2F;months into the future, and syncing occasionally with their manager and&#x2F;or peers.

&gt; 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<p>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.<p>For some start ups I&#x27;ve worked with, there&#x27;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.

&gt; Culture: people enjoy building complex systems and&#x2F;or building complex systems results in respect from peers and&#x2F;or prestige<p>Seems great for architecture astronauts. Maybe they&#x27;ll stay long enough to eat their own crap. In the meantime, I&#x27;ll keep in mind to stay away from such companies.

Incentivizing people to create complex systems sounds really scary to me. I guess there&#x27;s an implied &quot;where the complexity is absolutely necessary&quot;, 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&#x27;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

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.

&gt; Bob Martin saying &quot;The solution to the software apocalypse is not more tools. The solution is better programming discipline.&quot;<p>A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like &quot;craftsmanship&quot; and &quot;clean code&quot; (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&#x27;re not a Real Programmer (tm).<p>I&#x27;m not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude.<p>Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason<p><a href="https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;320247&#x2F;has-can-anyone-challenge-uncle-bob-on-his-love-of-removing-useless-braces&#x2F;320262" rel="nofollow">https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;3202...</a><p>Which caused the big OSX&#x2F;iOS SSL bug in 2014, see <a href="https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;2014&#x2F;02&#x2F;22&#x2F;applebug.html" rel="nofollow">https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;2014&#x2F;02&#x2F;22&#x2F;applebug.html</a><p>This link and thread on hackernews is good too<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15440848" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15440848</a><p><pre><code> 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&#x27;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&#x27;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.</code></pre>

&gt; 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.<p>This split between incentive, process and culture doesn&#x27;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.<p>For instance if reducing bugs brings company wide fame, money and makes everyone&#x27;s work visibly better, people will spend more time on avoiding&#x2F;fixing bugs, and a culture of quality will impregnate the teams. Process will be adjusted accordingly when they don&#x27;t align with that culture.<p>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&#x27;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.<p>Seeing leadership create processes and incentives that align with the stated values of a culture builds trust that those stated values are authentic.

So I was a sysadmin scripter(powershell&#x2F;cmd&#x2F;bash) then network admin, then infosec. Ive really blown up using python for all kinds of things last few years. I&#x27;ve built a whole honeypot -&gt; 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.<p>I work alone so my extent of &#x27;culture&#x27; has been pycharm warnings. I imagine if another programmer saw my code they&#x27;d vomit so violently they&#x27;d have to buy new electronics.<p>I try to do the right thing, but PEP 8: E501 line too long (125 &gt; 120 characters) I&#x27;m not really caring too much about being 5 characters too long. I tend to comment my code well but there&#x27;s certainly areas where there&#x27;s nothing because the comments wont help much.<p>Yet what ego do I have to get in the way? I know I&#x27;m not a programmer, I know there&#x27;s tons of room for improvement. Its just... I don&#x27;t know what I don&#x27;t know. I feel this article speaks to me but I don&#x27;t really have a mentor :(<p>Edit&#x2F; just ran pylint against one of my projects. It fell over laughing.

What I&#x27;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.

&gt;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&#x27;s a slap in the face to anyone who writes software for a living. ... It&#x27;s a shame you have to do so much pre-screening to have the luxury of interviewing programmers who can actually program. It&#x27;d be funny if it wasn&#x27;t so damn depressing<p>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.

&gt; When debugging a bug like that, there will be numerous wrong turns and dead ends, some of which can eat up weeks or months<p>Warning: doing this at a startup will get you fired.