Beginner's guide to code review

Code review is all about dialogue

Do it the smart way

Simply start doing it. I wrote lately about it in soft side of peer reviews and code review works.

Remember to do it the smart way - reviewing 200 lines of code in 1-3 minutes means you are doing it wrong! If you try to simply mark doing a review - only for the sake of others not bothering you - 

don't waste everybody's time. Be honest and assign the review task to someone who cares for code quality and for others.

Code review is all about dialogue

Talk with the code author – listen and try to understand hers/his point of view and the decisions that was made behind some certain implementation solutions. Use this opportunity also for learning.

Try to use few simple rules while code reviewing:

• Spend no more than 2 hours a day reviewing - that's just enough for your brain.
• Do not be intimidated by senior developers - after all they are all people – if something they wrote in the code is not clear for you - ask them. Remember - code review is all about dialogue.

Pros

By reviewing others’ code

• You get a chance to learn from your more experience peers and vice versa.
• Programming skills quickly spread throughout the team.
• Best practices are shared and instilled in your team.
• You can ensure you will spend more time developing than looking at those ugly bugs.

By having your code reviewed by others

• You get help with uncovering your trivial, easy-to-eliminate mistakes.
• You spread your perfect coding skills throughout your team.
• You ensure your perfectly implemented algorithms are not broken by trivial changes.
• You can have productive discussions about the implementation choices made by you that may lead you to even better solutions.

® O'Reilly Head First Labs
If you are marking your code review - simply stop!

Cons

If you are a developer who does things the hard way, then doing anything else than coding is probably the worst nightmare for you. So you treat code review as freaky red tape. But hey – is bug fixing not as much fun as coding?

Less non-productive work means more fun

You can always say that spending time on code review means less time for coding... but look at it from a different angle - while making code review - you are just coding without touching your keyboard plus you get all the benefits (knowledge, experience, esteem...) 

Check also other code review posts:

• soft side of peer reviews 
• code review works.
• joe bloggs on code review
• joelonsoftware.com

Read more »

What skill should I focus on learning to become a coveted freelance programmer?

Communication skills
As a freelance programmer you need to talk the talk and walk the walk! 

The most basic skill are your personality and the way you can communicate. This can differentiate you from your competitors on freelance market. When customers would be able to recognize you, see something special in you - they are more likely to choose you for the job and more likely to return to you with more tasks to solve.

One of the crucial communication skill is the language - make sure you have a least basic knowledge of the language your clients uses and have a least one language you both know. Most commonly you would use English which is lingua franca of the web.

Studying up on it doesn't cut it. You also need some real experience to be able to arrive on a project and hit the ground running. 

Project skills

These skill would make your jobs done. You have to possess specific software development knowledge - like deep understanding and experience in software languages as well as databases experience. What would also be a plus is general knowledge of different software development cycles. You need to be able to arrive to a project and get your hands dirty as soon as possible. Ensure you choose a job which matches your level and field of expertise.

Business skills
You should be able to estimate and charge correctly for the work you do.
If there would be some cooperation with big organizations involved you also need to deal problems of delivering your work to much wider audience. Such customers cope with a lot more volume and so their designs must take that into account. So one must learn strategies for creating 24x7 systems that can handle large volumes of data as well as huge number of users. 

 

Some advises
As a spot of advice, start by looking at job postings for cities/places you would like to live for a longer time, and note what technologies are most often requested there. After you've accumulated a decent number, pick the top three most common and start studying them. 

If your current position doesn't present opportunities to practice them, create your own! (Make a simple application, or contribute to an open source project). In 6 to 12 months, if you've practiced enough, you should be able to command a decent price in the market of your choice. 

Good luck to you!

Related articles:

• Freelance Career Ideas: Writing, Webdesign & More
• Tips To Be A Successful Web Design Freelance

Read more »

Degree at Stanford? Harvard? MIT?... let's hook up into the net.

(Fot. NOAH BERGER NOAH BERGER/The New York Times/R)  
Sebastian Thrun and Peter Norvig are among world's
best AI specialists.They founded Know Labs.

Sebastian Thrun and Peter Norvig are among world's best artificial intelligence specialists. Both are connected to Silicon Valley's Stanford University. Thrun is known for creating the Google's self-driving car. Norvig is a Google's Distinguished Software Engineer and heads one of Google's R&D department.

They have made something incredible last autumn: invited users from all over the world to join free, web-based artificial intelligence classes. They were held like a standard university classes - lasted a whole semester, had home-works, deadlines, tests... Attendees had to show their activity and self-motivation in learning and solving puzzles prepared by the two teachers. At the end there was a difficult exam to pass. Sebastian Thrun often emphesized that is main goal is spreading knowledge.

Despite all these obstacles their class has been warmly welcomed. They has 160.000 enrollments! Those who made it to the final exam were given a statement of accomplishment signed by both scientists. It might be thought as not as prestigious as a Stanford's university diploma, however finishing the whole semester supervised by Thrun and Norvig is quite an accomplishment.

How they got the idea?

Sebastian Thrun gave a talk at TED talking about driverless car he helped to create in Google. 

During the same conference he saw a talk given by Salman Khan, the creator of Khan Academy. 

Khan Academy is a popular web page with hundreds of video lessons, explaining different school subjects. It's very popular not among pupils in the USA, but also worldwide.

Thrun was so excited about the idea that he began to think about creating a parallel educational center for adults. His idea was to create an open university where everyone could find free courses from best scientists.

Many universities record lectures and publish them on-line, however what Thrun imagined was far beyond only providing recordings. He wanted to include everything that you can find on a standard university: seminars, exercises, teamwork, deadlines, exams and diploma.

His ideas was put into action - while with Norvig - he started Know Labs (investing his own $300.000, on multimedia studio). Then he begun the enrollment for first test semester of Artificial Intelligence classes. What he was expecting was a about a thousand students...

What a class, tremendous response.

There were around 10 thousands volunteers a week after enrollment started, a month later the number grew to 50.000. Just before the beginning of the classes there were over 100.000 students enrolled. One in eight student finished that first semester - it was over 20 thousand people!

It was a great success - another two classes proposed by Know Labs attracted 68 thousands participants worldwide. Thrun named the project Udacity, which is a combination of audacity and university. This autumn there are eleven classes to choose from.

What is worth noticing Thrun thinks that normal universities are still not replaceable, mostly because they offer creative atmosphere - which is created by people interactions during classes and face-to-face contact with pedagogues. Both are not possible in a web-based Alma matter.

Other universities don't let grass grow under their feet

There are many other to follow the path... one of them is the Coursera page. They started around autumn 2012 with a couple of classes.

Harvard is another one to follow with their EdX project.

What they offer is a simillar portfolio of MIT and Harvard classes with additions of self-paced learning, online discussion groups, wiki-based collaborative learning, assessment of learning as a student progresses through a course, and online laboratories. 

Brave new world

There was a slang name created for such web-base university classes. They are called MOOC (massive online open course). MOOCs became possible with the advance of the web and lowering the entrance barrier to cloud computing power. Virtualization provided an easy way to scale a web-based services to being accessible for a varying number of participants - which can be uncommonly high - counted in hundreds thousands - who knows when they hit the first milion...

Update with new perspective - it's a platform!

Just recently I stumbled upon a very insightful post concerning the evolution of MOOCs. The main idea is that MOOCs are basically... a platform. They also cite Phil Hill, who they see as an early and constant  voice on the subject from his recent post:

When analyzing the disruption potential of MOOCs, it is easy to forget that the actual concept is just 4 or 5 years old. Furthermore, the actual definition of the concept has undergone a significant change in the past 12 months as an entirely new branch has emerged.

Phil gives a detailed diagram to show the evolution of different MOOCs:

Marc Bousquet gave a post about good vs. bad MOOCs:

Well, the good intentions and featured best practices of Siemens and Downes exist in political and institutional realities. If institutions really wanted to sustain participatory learning, they would already be doing so, for instance, by reducing lectures and high-stakes testing, investing in teaching-intensive faculty and the like. Instead, driven less by cost concerns than a desire to standardize and control both faculty and curriculum, administrations rely more than ever on lectures and tests.

These two posts gave a much more perspective towards MOOCs. We will see how these different approaches to this subject will evolve in the near future. 

Read more »

Choosing the right tool for the job... priceless.

Special type of buyer's remorse

We often have the feeling after buying something that it was not the right choice. There is a phenomenon called buyer's remorse over an expensive purchase, but it's not what we are talking about here. What I mean is that you have bought an expensive bicycle and somehow missed the fact that you most often go for a walk with a one year old son - who is too small to ride a bike. Well that's the way it is...

To no surprise, many people do such a think quite often with small purchase, like smartphone/tablet apps or candies in a cake shop. You have a certain need that need fulfillment, then you came across an add or description which sounds just right so you buy it. It might even pass you simple quick check just before you pay for it.

I had this happen to me recently when I bought an webcam, I wanted to use with my laptop. It worked quite well in Windows environment, however what I learned after buying was useless in any other operating system. I tried to use it under Ubuntu, without luck.

Take advises from other with a grain of salt

Such a scenario can often happen regarding choosing the right development tools. People often take advice from others who were using the tool (often in their private projects or some other constrained environment). When it comes to testing such a tool the proof-of-concept seems to be just fine. Piloting the project succeeds. The the troubles arise during deployment. Many configuration problems, trying to stretch the current process to include the new tool, missing required metrics, too many false positives... and so on, and so on... I think these issues are quite prosaic. 

We end up with a bitter pill to swallow when we agree that the selection process was unsatisfactory.

Most proofs-of-concept that can be seen are really just basic comparison of different tools. Then someone who work in isolation or at least it looks like he is, have an idea about what the needed tool or tools should do and so a good old features checklist is created. At times a single vendor often helps in creating such a bake-off.

Different products are put on such a list just looking at their features listed on some wiki or documentation (not often outdated?). What is missed here is the holistic view of what such a tool can offer within the whole process it is going to be put into. How is it going to fit? What are the output from such tool? Is it going to be easily integrated? Can it be easily replaced? It the tool easy to be adjusted to the needs of the environment it is place into?

Put anything new into current working environment perspective

In addition, this technique tries to take into account the biggest costs and most likely obstacles to success. In order to select the right tool for the job it is crucial to take into account the way in which you work, your team works and your process is described.

Let's assume that your team work in Eclipse on a daily basis and you have selected a tool without proper   Eclipse backup - you are forcing your teammates to spend time using a second tool, wasting time switching between two windows, having to configure another application to meet their needs. 

 Furthermore when they are given results, they are not placed in developers' work-environment - the Integrated development environment. It has to be further changed in order to be useful. Such small struggles tend to bracket together over time and people, carrying a significant burden withing the team. 

For example, some time ago people got inspired with the idea of batch checking for static analysis. What was most important was the ability to perform software analysis without actually executing the code (so called static code analysis).

Contriving techniques like pattern-based analysis - which were used by SCA (static code analysis) where patterns of wither good or bad code are used as rules or checkes and a comparison is made between them and the source code - no even compiling and executing it. That gave a way to pottentially easy find metrics, common errors, check code style, ensure there are no coding rules policy violations... and show the results to the developers to act as quickly as they can to fix the problems early in the releace cycle.

What is important here is to make sure developers are not given the results on e-mails or just some external tool, but as close to their daily working environment as possible - so make sure IDE support is a crucial feature on your list.

Read more »

Rational Team Concert migrating from Derby to DB2 under linux shell

IBM® Rational Team Concert™

Migrating to DB2 from Derby in Rational Team Concert was due to the fact that Derby allows to have only 10 users. It is enough for testing environment but for a university project it is too little. We need to be more scalable, as there can be much more potential users.
Fortunately DB2 has a free licence for academic use, so it was a natural choice.

The main problem was that DB2 has to be installed on a remote server and I had just ssh shell to connect to it.
Great opportunity to remind oneself how it was, when windows were not at all common.

1. download DB2 and the licence
Start herehttp://www-01.ibm.com/software/data/db2/9/download.html
and download the DB2 file and licence.

2. install under linux ssh shell
Unpack the file under a directory with enough free space. I took steps described here:
http://snippets.dzone.com/posts/show/3682
http://www.fduran.com/blog/db2-linux-installation-notes/
3. remember to enable TCP/IP connectivity
look at page 78:
www.redbooks.ibm.com/redbooks/pdfs/sg246899.pdf

4. make RTC aware of the new db it needs to connect to:
You have a very handy web UI wizard to do this task.
https://yourServersAddress.com/jazz/setup
and follow the steps.
You can also do it manually, by changing the teamserver.properties file, which can be found in /jazz/server/ directory.
The most tricky part is to give a proper db location properties set up correctly:

# Comment out above lines, uncomment the following three lines and customize example location to use DB2 com.ibm.team.repository.db.vendor = DB2 com.ibm.team.repository.db.jdbc.location=//localhost:50001/JAZZ:user=db2inst1;password={password}; com.ibm.team.repository.db.jdbc.password=put_your_password_here

These lines are the same in the webUI interface.
After fulfilling them in the UI wizard, you can choose to test your db connection. It should return green thick :-)

5. enjoy!
Now you can enjoy the new db running under your RTC. In case you would need to backup your data from Derby, check here: https://jazz.net/help/rational-team-concert/1.0/index.jsp?topic=/com.ibm.team.install.doc/topics/t_migrate_derby_db2.html

Read more »

The good side of making code review

A recent post Code review works just make it your daily routine talked about the best code review practices used in most successful code review teams. Today I would like to talk about the soft side of peer reviews.

In  The Soft Side of Peer Reviews, Karl Wiegers starts with a powerful pronouncement:

Peer review -- an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities -- is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them. The Soft Side of Peer Reviews

 Using code review in my work for a daily basis make me think that peer code reviews are the single most important thing you can do to improve your code. If you're not doing code reviews right now with another team member (programmer, architect), you're missing a lot of issues in your code (which will return in some nearest future) and cheating yourself out of some key professional development opportunities. Most of the biggest companies are using code review techniques on a daily basis. Take Google for example.

As MarkCC writes about code reviews in Silicon Valley company:

The biggest thing that makes Google's code so good is simple: code review. That's not specific to Google - it's widely recognized as a good idea, and a lot of people do it. But I've never seen another large company where it was such a universal. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

Everyone should do this. And I don't just mean informally: this should really be a universal rule of serious software development. Not just product code - everything. It's not that much work, and it makes a huge difference.

 As far as I'm concerned, my code isn't done until I've gone over it with a fellow developer. So just after you are about to make another commit - just ask someone to take a quick glimpse on your code.

In future post I will try to tell you more about What do you get out of code review?

Read more »