Additional profile information on Alfred Thompson at Google+
I found and Twittered a number of links over the weekend. I guess I should figure out and use some sort of tagging service/site but I just don’t want to. I have too much to track now. But I thought that perhaps for some of you who don’t twitter I should post some of these links. Plus it give them a little link love for the search engines. Hopefully you’ll find something of use/interest here.
First, although I found it last, is a Blog post by Mark @guzdial called The Responsibility for the Image of Computing Mark who was the conference chair for this year’s SIGCSE talks about the responsibility for teaching about the role of computing in society and how he sees that as an important role for high school computer science education.
Got girls? Live in Texas? UT Austin has a girls tech camp called FirstBytes that is a summer outreach program for girls. This program is designed to dispel myths and interest young women about computer science. There is a great video on the program at this first bytes video link.
Then there is this web site that gives your age in terms of years on other planets. Oh and your age in days. If you want to show students about the different lengths of time other planets take to circle the sun or rotate this is the place. There are some other good planet related links there as well.
Steve Clayton had an interesting post about presenting while people are Twittering. It is a follow up on a great post form about How to Present While People are Twittering by Pistachio recently. Industry is being forced to learn to accept and adapt to Twitter, IM, IRC and other forms of “back channel” discussion during presentations and meetings. There is good and bad to back channels and I think educators need to learn about this.
Know any college/university students (18 and older but world-wide on this one) who are photographers? They may be interested in the Microsoft Future Pro Photographer contest.
For Microsoft Surface in Education fans there is a new video interview/demo on using Surface in Education out on the Microsoft Surface blog.
If you are on Twitter please think about following me at http://twitter.com/alfredtwo and send me an @ reply to let me know if you found any of these links useful or interesting.
Back in the day when I was a full-time software developer code reviews were an important part of my life. One group I was part of us sent the whole team for serious training in doing code reviews. We took them quite seriously and I thought there were good two ways. 1) they made the code we produces much better – more reliable, more maintainable, more efficient. In fact better by any metric you want to use. 2) they made everyone on the team a better developer – we learned a lot from each other and from our discussions.
And they also made sure that we all understood each other’s projects which was often a huge help.
So how did we run code reviews?
Each review had three people at least. Someone to read the code out loud, someone to take notes on what was found, and the author of the code. More people was fine but three is the minimum. No people can’t take several roles. No the author of the code can’t take notes or read the code. Three roles – three people. Deal with it.
Everyone on the review gets the code in advance and reads it at least once before the review. No really you do. You are either concerned about quality enough to do this or you are not. At the review the reader starts reading – stopping at the end of each statement in case of comments or concerns. If a concern is raised there is a discussion. The code author explains what the code does and why it was written that way. People give pros and cons and a decision is made if the code stays the same or is changed. The person taking notes makes notes of any decisions involving a change.
There are lots of reasons that code might be changed BTW. I once wrote an absolutely elegant recursive solution to a minor problem and the code review hated it. Not that it didn’t work – it did. Not that the solution had bad performance – performance was fine. But rather that the code was “tricky” and hard to understand. Perfectly clear to me but not so much for the rest of the team. This code had to be maintained and perhaps one day modified so being clear was important. I re-wrote the code.
Changes may not be major either. It maybe a variable name change or perhaps some better comments for more internal documentation. Or it might be as major as a refactoring of repeated code into a new method. or more. The point is that changes are discussed and agreed to.
Which brings up another issue in code reviews. Ego. You really have to check your ego at the door before a code review. And I don’t just mean the author of the code being reviewed though that is important. Everyone has to remember that the code is being reviewed and not the person. This is not about being a good person or even a good developer – it is about making the code good!
No one should “pull rank” by saying “I’m the senior person and I say this” or “I know more about this than you” or anything of the sort. Cases for change must be made based on the merit of the idea not the person who pushes it. The author of the code has to avoid taking criticism personally. The reviewers have to avoid making the criticism personal. It’s about the code – never lose sight of that.
Code reviews can only go on for so long BTW. A marathon all day code review is pretty much as useless as no code review at all. People get tired. The author of the code starts to feel beat up and overwhelmed no matter how things go. Two hours is probably the maximum amount of time. They gave us a time limit when I was in training but after all these years (yeah I’m old) I forget the exact amount of time. Two hours feels right though.
Regardless set a limit based on time not on lines of code reviewed and stick to it. Code reviews can take time. Often mangers don’t want to spend the time and often developers just want to write code and let someone else test it and call it done. But for me there is nothing like a code review for when you want to ship the very best code.
Edit: karen Wells left the following in the comments:
"If you want more data on code review best practices, you can request a free book - Best Kept Secrets of Peer Code Review - at www.CodeReviewBook.com."
I am often asked to look at other people’s programming projects these days. I really enjoy this most of the time. Sometimes this is part of evaluating an entry into a programming or software development contest. Sometimes it is to give feedback or debugging help on student or sample teacher produced code. Either way I have learned a few things about problems with sending code and would like to share some of what I have learned. So a few guidelines.
Send enough of the project – What is enough? That depends on a lot of things. But if you want someone to actually compile and run your project you probably need at least the whole project folder. My advice is to package things up and test them before you send it. Take the package to a clean system – one that you haven’t been working on this project and unpack your package. Does what you moved compile and run there? If not, what is needed to make it run? Is it just standard libraries or a special SDK or some specific set up – SQL server perhaps? If the person you are sending things to can not be expected to have to easily get (with your warning and instruction) something for their system you need to send it. This all brings us to the next guideline.
Send directions – What sort of directions? Well for starters how to unpack and or install what you are sending. Also any prerequisite software. What version of relevant software (compiler, IDE, OS, SDK, etc) you using for example. This will help determine if an older or newer versions fix or cause things to work or not work. Chances are that people will not spend a lot of time trying to make things work without instructions. If you are entering a contest a judge is very likely to decide the code just does not work and allocate no points at all. Trust me on this – I speak as a judge. In fact if you are submitting something for judging you may want to ask a friend to do a dry run with your package and instructions. You really want to make things simple for the judges.
Make sure the tester/evaluator/debugger/advisor has enough information to run the program. If you have a login screen make sure you tell them what information will get them in. You don’t want them to have to read the code or worse still hack the code to run your software. Provide sample data for them to use. Sure they will try to come up with some data that may break things but you want to make sure they have data that shows off the best of your code.
Use good coding practices – No matter if your code is being judged/graded or debugged it is helpful if names make sense, comments are provided and and other standard practices are maintained. Actually those things help avoid needing help debugging in the first place. A word to the wise about code that is being graded – if you have five forms named Form1, Form2, Form3, Form4 and Form5 it will reflect poorly on you and your project. Sure you may know which one is the login form, the report form, the help form, the data input form and the really impressive super duper sure to impress form but no one else does. You can make life a lot easier for someone debugging the code to start with good form names. Variable, object, method and property names are just as important. Don’t make people work if you want something good in return for their time.
For debugging help clearly explain the problem - “This code doesn’t work” is not a helpful statement. Why? Because in all likelihood the person you are sending it to has no idea what “working” looks like! Explain what is happening, what should be happening and what assumptions you are making in the process. Outline the steps that can be taken to reproduce the problem – in detail! You should also explain some of the things you have already done to try and track down the problem. But at a minimum don’t make the person guess as to what the problem is.
Now you may think the problem is obvious but if there is the slightest thing different on the other person’s set up (see earlier guidelines) that may mask your problem. You want someone to look at the right problem and not one you have already solved.
Bringing in a second set of eyes to look at a programming problem or review it for improvement is often a great idea. But you want to make sure you maximize the value of the process by minimizing the work the other person has to do. Take your time, think about what you are doing and test before you send and everyone will be happier in the long run.