Why do Code Reviews Matter?

We build software together. Team sizes vary a lot but it’s usually not 2 or 3. Team members leave, new members join and in the end of the day codebases are shared among large numbers of  different and diverse people from development, testing and deployment.
Code reviewing process is what you take into action every time you make modifications to the code’s itself. Even though you change a single line, before committing the code to repository, a peer reviews it and confirms it can be submitted. Reviews can help to decrease the number of bugs, vulnerable code pieces, misuses of coding standards and etc. In an environment with no reviewing practices, actual code wont be directly visible to developers before an other member opens file(s) for editing. Without reviews, even though build passes QA tests,

1. Readability of the code,
2. Compatibility with coding standards,
3. Organization of the codebase,
4. Documentation inside the code /* comments */,

will stay as surprises. These may lead to a dirty and badly organized base after a few years of continuous development. Asking a peer before you integrate new code into your product is a better approach since you may most probably have more time to fix, reshape and enhance your code if you take the action earlier. Usually only one other team will have time to review your code. But reviewing should be done with two people. First one should be a master, the one that knows the existing system well and can see the big picture. He can guess the impacts of your certain changes among the codebase. Other peer should be ideally someone who is not very familiar with the code, so you can test how easy to get into your code if you have to assign a bug to a new member, how well it suits with patterns in software development, how simple and obvious your solution is.

Consequently, whatever you are working on is shared among people. Asking for a review is always better than not asking and keep your actual contribution as a secret until it needs to be changed.

Why Do I See Software Development Job Titles as Nothing but Virtual Positions?

There are so various areas and people involved with software that “software development” phrase alone doesn’t give you enough perception about what the real job is. I proclaim that there are stereotypes in this field: code monkeys, every job developers, developers specialized in an area, revolutionary brains, problem solvers etc. They all share some characteristics, some behaviours, some little common knowledge. The mutual attribute is only the names. We all know that they can code. But they implement coding behaviour entirely in different ways.

I started to code with a fundamental function to find roots of a 2nd order equation and easily understood how programming can reduce the amount of time I’m spending on trivial calculations. The Internet was becoming widely available (at least in the community I was living). There was a technology boom, the access rate to the “new” were increasing wildly. I decided to learn as far as I can and in the end I became a giant language and framework addict, although I had no deep knowledge in anything. But it was driving me because, the particular technology I was interested in was helping me to turn my fancy ideas into concrete products. So, not for doing all for learning the technology’s itself doesn’t make me a software developer now? How dramatic.

Being a software developer with no purpose

It’d really taken me far too long to get aware of the ecosystem of a software-dominated system without formal education. However, before  I had reasons to learn, I had never dreamt of being a professional software developer – cause all alone it was meaningless, especially in a situation when software you’re bringing out doesn’t have any purpose other than making profit. Nobody does have dreams like being the greatest developer in this or that field. People like me usually tend to be remembered with

1. a groundbreaking product, a method changes the concepts, a more efficient way of doing things.
2. being a leader in a specific area to influence other people.

They put meaning into every single duty they are working. I personally don’t look programming jobs as jobs. It’s a great opportunity to access a company’s tools and existing audience to make differences quicker than forming a new start-up, gain respect and deal with financial stuff. But again with purpose, you always have the “If you’re not hiring me, I’ll be doing the same on my own” advantage under the belt obviously.