Computers are useless. They can only give you answers.
Pablo Picasso
When writing code for a class, it can be a temptation to write code as quickly as possible so that you can get the job done and move on to something else. I get it. I’ve been there. While this inclination is understandable, you are doing yourself a disservice. You will immediately regret your decision if you ever have to go back and fix a bug in your code. You are also building a habit of writing sub-par code. As you prepare for the workforce, you will want to start writing code that you are proud of—code that is clean, concise, and easy to understand. In this class, I encourage craftsmanship of code: code that is carefully crafted. This does not mean that your code gets written perfectly and cleanly the first time.
Development is messy, and as you try out new ideas and algorithms, your code can get pretty rough around the edges. The craftsmanship of code involves taking the extra step after you have come up with a good solution to refine your code. Refactor and reorganize your code if needed. Add comments if needed. Change variable names so they are more meaningful. In summary, write code that you would be proud to show others. As you get practice at this, you will find your code will come out cleaner the first time without refining it. Good craftsmanship is vital when your code will live beyond a contrived lab (i.e., a job), with others (included your future self) working on the code later on. Spending some time now to make sure your code is well crafted will save you a lot of time later.
To help facilitate this philosophy, you will have a few opportunities to meet with a group of students to share your code. I will generate random groups of students that will meet together to discuss their code. Here are some guidelines and discussion points for these meetings.
Lab Craftsmanship Meeting
First and foremost, these meetings should be done in a spirit of love and acceptance. You are not there to bring others down or show how clever you are. Be constructive in your feedback and thoughts. And always remember, code is an art, and we all don’t like the same art. If I get feedback that your meeting was not constructive, I will subtract points from your craftsmanship grade.
Your meetings should go something like this. Someone will display their code for the lab. They will talk about the general approach they took to solving the lab. They will describe roughly each block of code and its intended purpose. Others will ask questions, such as why did you do it this way? If someone implemented the lab differently, you could discuss the different methods. This discussion is an opportunity to learn from others and hear other’s viewpoints. These meetings should range from 30 minutes to 1 hour.
As you show your code or view someone else code, here are some things you might want to discuss:
-
What was challenging about the lab, and what did you do to deal with this challenge?
-
What bugs did you face, and how did you handle them?
-
How did you deal with the complexity of the lab?