'''Introduction'''<br>The two talks I decided to write about which I attended in the FS0SS 2007 gathering were Benjamin Smedberg’s Open source code review and Mike Beltzner’s talk on Designing for and with a community. <br> <br>

*And the last and according to Mr.Smedberg the most hardest part of it all; keeping track of the patches or understanding what patches have been done on the software by other people in the community<br><br>All of the above points in my opinion are very valid points; which will play key roles in a person’s life as a programmer in some way or another. Identifying bugs is one of the main reasons for reading code; and this is why Benjamin agreed that every school in the country teaching computer programming related courses should teach students how to read code and get them involved in some sort of code reading before they leave school and are released into the business field. In his second point of implementing or identifying features Benjamin pointed out the need for properly placing a feature or finding a necessary spot to implement a piece of code in order for it to enhance the user experience requires code reading and code understanding; putting a feature or a piece of code anywhere is not going to produce the most desirable results, in many cases or almost all cases this would just mean inefficient processing time or the system crashing as a whole.<br><br>Creating documentation for today’s world of complex and never ending lines of code is key for other programmers who later wish to add to or enhance the already existing code base. This can only be accomplished through code reading and understanding of the correct points at which the documentation should be placed. This documentation could also be later revised as the code is changed or enhanced.<br><br>Not so surprising to me was the last point where Mr. Smedberg pointed one of the hardest parts of code reading was to understand what other people’s patches did to the software the original programmer created. To Mr. Smedberg this was one of the hardest or if not the hardest and most frustrating part of code reading, decrypting other people’s code and coding styles.<br><br>Mr. Smedberg also pointed out the importance of LXR/MXR as shown to us and stressed on many times by professor David Humphries in our DPS909 class. Mr. Smedberg also talked about tools such as Eclipse, and grep which are useful in finding code parts which are necessary for code reading and understanding. Benjamin regarded himself as the “Guru” of code review, and coding in it self. Mr. Smedberg’s views of the open source world was beginning to sound more and more like the cathedral and the bazaar literature I read back at the beginning of the course. Although he did not quite come out and mention this himself; I got the impression, maybe it was my misunderstanding, especially during his talk about reading other peoples code and patches to bring a consistency to the code base felt like he was drawing parallels to bringing order to chaos and finally producing a product that can help people all through out the world.<br> <br>Mr. Smedberg also gave some good tips on finding a bug’s source. But before he got into those three points he mentioned one key thing that stood out to me, he (Benjamin) said “You do not always have to understand all the bugs or know how to fix it all”. This drew parallels to something Albert Einstein once said and it seemed to stick in my mind always “Why should I remember something that I can just look up?” That being said the three tips he gave for identifying bugs location are<br>*Look for common bad patters*Look for uncommented code bits*Look for code which was changed recently or something that has being undergoing consistent change<br><br>