RhodeCode

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.

Read more…

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.

Read more…

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?

Read more…

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".

Read more…

Introducing version control early in your programming career is really important. It needs to become part of how you code, and using it correctly helps you learn faster, experiment easily, and collaboratively build knowledge. For a student, apart from partying and drinking too much, this is what you are supposed to be doing during your semester. So let me tell you my story of discovering version control and why it is indeed needed.

The Young Novice

Back in the day, shortly after the dot-com bubble, I entered college and discovered computing wasn't just Call of Duty. I ended up building a website in Dreamweaver with two other friends for a project. It even had flash components, most specifically a "math monkey" that would dance across the page and help users solve sums. Cutting edge stuff!

With 3 people working on the project we made out a very comprehensive plan, didn't follow it, and ended up putting in a 48 hour straight session in a computer lab in a mad panic to get it in on time. Just as the 3 separately built parts of the site came together and duly didn't work, one team member cried, one stormed out of the building, and the whole thing took on a surreal level of derangement.

Read more…