The Best Programming Advice I Ever Got (2012)

> most people get defensive when newcomers (especially juniors) come in with suggestions

Reminds me of that quote "science progresses one funeral at a one".

I had a good boss at a previous company. Shortly after I was hired, he scheduled a meeting with the rest of the team and said, "We want to get your opinion on this thing X we've been working on for over a year. Since you're new, you may have some fresh perspectives about what can be done." I generally think that's the right approach.

Judging by the number of systems in different fields that have been overhauled by outsiders to the field, I imagine real innovation has less to de what thinking of new ideas and more to do with navigating the minefield of human psychology.

> When they've gone on an unauthorised excursion through some code that has say, safety critical or legal, concerns

> especially if said code was rattling in the building around somewhere it might get into the code base.

Reading code should never require "authorization". There might be some edge cases related to logistical technicalities (e.g. there's a security clearance/IP/trade secret/plain-text password concern). But there is no reason that the criticality or risk from changes to code should prevent people from reading it.

Writing or rewriting code should never require authorization; getting it released should.

That's not some 'everyone should do whatever they want, damn the managers' statement: do your job and try meet your goals; if you go off the reservation and waste time, don't be surprised if you get slapped. If you take your code to your boss/team and they say "that's too critical to touch right now/at your experience level", "I don't have time in my day to review your side-of-desk rewrite, shelve it", or "that's incredibly misguided and too stupid to even try to improve", that's on you to work through.

But the act of [re]writing code alone should never be forbidden.

If one of your job's responsibilities is "don't rewrite this code, even as a scratchpad or personal what-if,", that is fucked.

If one of your job's responsibilities is "don't read code that is out of your lane, and don't try to understand the haunted forests"[1], that is fucked.

Your responsibilities might not be explicitly to do those things. But if your responsibilities include the negatives ("never touch this, even if you don't check it in"), something is very wrong.

If code "rattling around the building" might somehow "get into the codebase", that is fucked: you have a horrible problem with your code review process, your release process, your developer prod-access/permissioning system, or your colleagues' willingness to accept as gospel things they find lying around. Or all of the above.

To be blunt, that comment seemed harmfully closed-minded, paranoid without reason, and lacking in understanding of how engineers grow and learn: by reading and writing code, even if nothing release-able comes out of it immediately.

[1]: https://john-millikin.com/sre-school/no-haunted-forests

That's a real problem, and quite common. I think it's important, when confronting or correcting someone doing that (whether they're your employee, colleague, superior, team lead, etc.) to emphasize that they're not being punished or thought poorly of because of their ingenuity or initiative, but because they're wasting time and need to stick to the plan. Otherwise, initially headstrong but very capable people are often ground down before they have a chance to get used to the roadmapping/planning/etc. process at a company. This is especially true with new engineers.

I have no idea if the GP post you're replying to is someone rationalizing being in that position as being "disciplined for touching the wrong code", or whether something actually screwy was going on. I just wanted to mention that distinction because it was important to me when I started out (if people had come down on me for having ideas, instead of for wasting time, I'd be in a much less useful, happy, and capable place today).

In those cases, why not respond by explaining the risks or other considerations that might not be apparent from the code?

Frankly if there is real risk that the code is pushed to production by someone who shouldn't be touching it is a failure to properly safeguard critical assets.

Retaliating because someone tried to make something better is abusive and dysfunctional.

"I want your opinion on...." for me is a potential landmine. Such questions can be used to detect potential troublemakers.

https://en.wikipedia.org/wiki/Hundred_Flowers_Campaign

In college 10 years+ ago, one of my roommates had a laptop with 500MB ram and took a 500MB ram chip from anther room mate's laptop to speed up a game he was playing.

He did this without the knowledge or permission of the laptop's owner who was sleeping and forgot to put it back.

Morning came, owner woke up to a laggy system. Discovered the cause and went straight to the culprit. Instead of an apology, he got insulted and reported to school authorities.

Culprit panicked and threw his own ram into another room mate's locker - not knowing that rams have brand names and serial numbers. The owner refused the found chip and after a search, found it in the culprit's laptop.

Case over right? Wrong!

We all got called up to an office and asked, "Who do you think took it?"

I naively answered with all the logical evidence. The "judge" accused me of slander. And warned me not to talk about it any longer or face disciplinary measures.

I later discovered that the culprit's father visited the official and our meeting's true purpose was a coverup.

In other words, be wary of higher-ups who ask for critique, advise, improvements, ideas...