Code reviews are - or they should be - an important part of any software creation process. They allow people get to know better the different code bases within their companies. Also, they learn from others and try to understand the reasoning, trade-offs and solutions about a somewhat complex problem. Moreover, people strive to improve each others’ code: “Hey, we should add some tests here”, “Shouldn’t we use a functional interface here? It would make the code more readable”, and a lot more comments like these are common in such process.
It’s 2:37am and you already lost 3000$ in the casino. “Just put 1000$ more in this blackjack round” - said no one, ever. This is the same feeling I have many times in software engineering projects. I mean, yeah, I get it, 2 years ago you needed to spent the minimum amount of time possible to get the work done. That’s fine. You delivered, you got customers, everything went well.
Bob: “Hey, what will we use to communicate with
Xin this project?”
Hi! This is my first post in this blog. Although it’s meant to be a tech blog, this post is the first part of a series where I mix software engineering, its practices and methodologies with a business background and why do software companies need to move towards continuous deployment. Stay tunned!
subscribe via RSS