Codeslinger

Story time: Back in my first job out of school, when I didn't really have much broad context on software development, I was working for Lockheed Martin as an entry-level developer. One of my weekly tasks was to write a status report email to my manager, in paragraph form, describing all the things I had been doing that week, and the value that they provided for various projects and initiatives. This was something which all the developers in the team needed to do, and my understanding was that it was a fairly common thing in the company (and by assumption at the time, within the broader industry). At some point, I was asked to also write these in the third person, which was a bit odd, until I realized what was going on with them. My manager was aggregating them into a larger email communication to his manager, in which he was informing his management as to all the value that his team was providing under his "leadership". I don't know to what extent he was taking credit...

Code reviews (https://about.gitlab.com/topics/version-control/what-is-code-review/) are a fairly standard practice in the industry, especially within larger companies. The process of having multiple developers look at code changes critically is found in several development methodologies (eg: extreme programming, paired programming, etc.), and they are often perceived as essentially for maintaining a level of overall code quality. I'd imagine that no respectable engineering leader in any larger organization would accept a process which did not incorporate mandatory code reviews in some form. So with that intro, here's a bit of a hot/controversial take: I think code reviews are overrated. Before I dive into why I think this, a quick tangent for an admission: the majority of code I've actually written in my career, personally and professionally, has been done without a formal code review process in place (and thus, not code reviewed). I've also, personally, experienced con...