The RhodeCode infographic charts how we got to where we are today. From Marcin’s initial idea to a rapidly growing software development company creating the world’s best software development solutions.
The RhodeCode infographic charts how we got to where we are today. From Marcin’s initial idea to a rapidly growing software development company creating the world’s best software development solutions.
Team work is not a skill, it is a philosophy that you develop and it becomes part of who you become. Depending on how you decide to bring your team player mentality to work, you will either be a great benefit to your colleagues, engendering a situation where both you and others can perform to their best and create a positive and productive work place, or you will be a myopic, probably narcissistic, ego-centric person lacking the self-awareness to make a positive difference. You are on this imaginary scale of extremes, every single day, if you work with other people.
This week I cover for the third and final time - code review. The direction of this weeks blog comes from our very own coder supreme Sebastian Kreft who pointed me in the direction of a case study done on NASA best practices used to develop the code that landed the Curiosity Rover on Mars.
Last weeks blog covered code review, how it makes your programming better, your products more stable, and accelerates your learning. But all that is a little wishy washy when facing a skeptic focussed on numbers and who wants to know why it's not full steam ahead. This excel sheet mentality tends to run headlong into the bigger picture vision and steamrolls right over it with it's reliance on numbers, however subjective the measurement criteria might be. In the world of business numbers triumph over logic every time. Writing 1,200 lines of code this week looks better on paper than 800 lines of code. But, done right, 800 lines of code may be 150% better, more stable, and more secure than the 1,200 lines.
But, how do you put quantifiable numbers behind your argument, and build a strong case for using a code review process in your development environment?
Code review is one of the most important aspects of developing yet it is so often jettisoned in favour of, well, in favour of not reviewing code. As writers of code, developers are just like every other poet, blogger, or journalist. They write their script, tweak it, rewrite it, agonize over syntax, and eventually push it out into the world. The difference between developers and all other writers though is that editing of what you have written is not automatically accepted as part of the creative process. In all other forms, it's not done until it's reviewed, and it is accepted that you need your peers to review, catch typos, tighten up phrases, and to point out oversights.
Developers are sensitive souls though and after getting something to work, often overcoming many obstacles in the process, they proudly point to the software and exclaim "look, it works". In their moment of triumph, the last thing they want to hear is, "the code quality has to be improved, you need to refactor it".