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