Once upon a time, there was a CTO. This CTO prided himself on being able to both write code AND manage his business. One dark and stormy day, he deployed his code to production and in short order his company was infiltrated by hackers! In his hubris, he forgot to follow best practices and sanitize his database inputs. It was a SQL injection attack that led to the breach! A rookie mistake 🤦♂️
That story is, unfortunately, not a fairytale, but a reality for Gab AI Inc. Their CTO, who had stellar credentials (and 20+ years of software development experience) made that mistake and his git commit history shows it. Not only did he not sanitize his inputs, but he actually removed code that had been in place to protect his company.
This situation occurred in March of 2021, and illustrates my opinion on why I don’t think engineering managers should push their own code to production.
Could a situation like this be auto-detected with good static code analysis tools? Yes, if you look at the reports or have quality gates auto-block your builds when these types of issues are found. Unfortunately, if Gab had that policy in place the CTO was apparently above the policy.
Could a peer review have caught this situation? Yes, in this case it would have been trivial to find the issue. You can see the actual code commit in the linked article and be the judge there.
The issue, in my opinion, is not the technical aptitude of a CTO or a manager. It’s the power imbalance that a manager has that’s the issue. Even if a manager has the authority to risk-accept their changes and ignore static code checks, during a peer review someone would have to tell their boss that they wrote bad code. Wouldn’t that be awkward!
Don’t misunderstand me. Overcoming what’s called “the shadow of the leader” and creating a safe environment where employees feel comfortable telling their manager “Hey, your code sucks, it’s rejected!” can absolutely be done. But it takes a very skilled leader to create this type of working environment, and not every manager is at that level. A blanket policy where engineering managers can safely write and release code into production is not scalable unless you put in the effort to create a world-class culture of engineering excellence.
So back to the question: should an engineering manager also write code? Absolutely, they should write code, but a lot of intentionality should be put into making the decision of whether or not that type of code should be allowed into production.
What do you think?
You can read more on Gab’s story below: