There is an interesting disconnect in people about software engineering. They are unable to grasp that the industry/team exists to solve business problems, not to release changes as fast as possible (I mean we do want to release fast but not at the expense of solving actual problems) or to try out the latest in technology. This is why I have seen techies in companies get upset that they can’t upgrade the entire setup to use the latest and greatest (as of now) framework they just heard about. Business doesn’t care about any of that, they want the software to work reliably, have the features they want and be stable. If you have ever had to pitch a infra upgrade, addressing technical debt or system uplift (without new features) to senior management you know what I am talking about.
A good SLDC (Software Development Life Cycle) setup ensures that there is a solid code review process setup before a change is deployed into production. This allows a person (or persons) other than the developer to review the code and highlight any issues found. It also serves as a way to train junior programmers about best practices and more efficient ways to do things. I have come back from code reviews with pages of questions and better approaches to solving the problem I was addressing. Even now all my code still goes through code review. If a company doesn’t have a good code-review workflow then I would be very scared to use any products developed by them. In Git this review is initiated by creating a PR (Pull Request), once the changes are approved they are merged into the next release branch.
Programming is more than just writing code and pushing it to production. As I said earlier the goal is to solve business problems efficiently and without bugs. So when I see statements like in the screenshot below I get very scared because it shows just how unprepared/unknowledgeable some of the folks who are ‘vibe-coding’ or AI coding changes that are being pushed to production are.
software development in 2026 is going to require some to loosen up a little. code doesn’t have to be as perfectly crafted the way we did it pre-ai.
rye
@rywalkersoftware development in 2026 is going to require some to loosen up a little
code doesn’t have to be as perfectly crafted the way we did it pre-ai
call it slop if you want, but if you’re still demanding perfection on every pr while your competitors are shipping “slop” that works…
you’re fighting from a disadvantaged positionshipping velocity matters more than perfection
Even ‘Pre-AI’ no one has perfectly crafted code, which is why we have technical debt and temporary fixes that last years if not decades. That said, the main goal of the Code Review is to ensure that you are
a) Doing what you want to do correctly
b) You didn’t break any existing functionality
c) Didn’t introduce any new bugs
d) Are coding efficiently/following best practices.
Out of the four listed above A to C are critical. Most of the review process usually focuses on these three with the last one being given focus as and when time permits. There are times when you encounter ‘The Coding Evangelist’ (See: Types of Software Developers for explanation) who will make you miserable trying to perfect the code but that is usually a rare occurrence (at least in my experience over the past 27 years of coding).
But if you are optimizing for speed of production instead of legibility and maintainability that is a way to incur tech debt at scale. Which is a big problem for systems in production. People often fail to take into consideration the cost of “Keeping the Lights on”.
Sometimes people do argue in reviews about stupid stuff, one funny instance I remember is from a previous company where these two senior developers had an ongoing argument about how to format the code. Each one hated the other person’s preferred formatting and they had both actually created Macros in Emacs to change the formatting to their preferred style every time they edited the file. We could figure out who the last person to work on the file was by looking at the formatting.
Long story short, (good) Code reviews are absolutely required and essential for an organization to ensure that the code in production is as stable and bug free as possible. It doesn’t matter how quickly you are pushing code if the code doesn’t work the way it is supposed to or/and has bugs in it.
– Suramya