Today I was charged with my first of three final challenges for my apprenticeship. The first one, which needs to be ready by this Friday, will be to deliver a lunch and learn to the 8th Light group. Though I already gave a lunch and learn on my testing design patterns, this lunch and learn will have to be pristine. I already know what I will be doing, and I will explain this further in a moment.
At the client site today Micah and I got to see the fruits of our labor. Our feature is not only out on the live site, but is now in full use. The feature was the ability to have, make, and use promotions in order to acquire more members. Today they sent out a massive batch of emails with a promotion code, and in just one day, the promotion dragged in over 2500 new users. They were quite pleased to say the least.
We also finished up another feature which sends out reminder emails to people who have subscribed using the promotion. We then picked up another story which we will work on tomorrow.
My plan for my first Apprenticeship Challenge:
This is actually something I had started talking about with Micah on Thursday last week, and we discussed it even more today. I had the idea when Micah was explaining to me how his talk went at the conference he recently spoke at. One of the activities he did was to show his audience a bunch of code snippets (this was originally done by Michael Feathers, and he actually gave the snippets to Micah) and have them rate each snippet on the quality of the code. After everyone voted on a snippet they compared everyone answers only to find that everyone had different opinions on which snippets were good and which were bad.
This got me thinking. Good code is a very subjective concept. There are certain things that people will agree help the code, or hurt the code, but for the most part... there is no one formula to write good code. In fact, great code to one person can be merely decent code to another. Likewise terrible code to one developer could look very readable and understandable to another. Such is the debacle. What is good code?
My dad recently wrote his Clean Code book which explained certain characteristics that help to define a process that could lead to good code, but at the same time it was clear that it takes years and years of practice to learn how to develop consistently good, clean code.
But does it have to? Maybe there are certain aspects of code that all people find pleasing and understandable. Maybe there exists certain naming conventions, or certain malleable themes that really help to explain intention. I don't know, but I am going to find out.
My plan is to go to conference after conference holding the same talk/workshop where I hold activities showing people code snippets and getting their feed back.
Here is how I, and this process is open to all suggestions, plan on doing this.
First, I need a way to get people to come to my talks. I need an incentive. Well, how about I offer expert advice on what 'Good Code' looks like! Damn... I am not qualified. Thank goodness I know a lot of people that are! I will collect a wide sample of code snippets and then ask several industry experts which snippets they think are good, and which they think are bad. Then I will offer to show this information at the end of my talk, after we see what my audience thought about the code.
Once I get people at my talks, we will proceed to look at a lot of code! In some fun manner I am yet to create, I will show the audience a code snippet and then ask the following questions:
How is this code? (possible answers = Awful[0] - Bad[1] - Ok[2] - Good[3] - Excellent[4])
(They have to answer this, and keep their answer no matter how they answer the rest of the questions. The point is to capture their 'Blink' estimation, or their first impression of the code)
How is the naming?
How is the use of the language?
How clear are the levels of abstraction?
How complicated?
How consistent and useful is the theme?
After we have rated a batch of maybe 5 snippets, we will go back an examine them. I am not to sure about this part because I want to keep the review until the end of the talk so I get mostly unbiased data, but I don't want people to get bored.
Finally when we are all done we will compare what we thought about the code to what Industry Experts thought of the code.
Throughout the talk I will be asking people for their thoughts on the code, on their reaction to everyone else's opinions, and especially for reactions of the expert's opinions of the code.
8th Light will be my first group and first experiment. This will be the trial run to work out the kinks in my future talks and presentations.
Let me know what you think and please offer suggestions!!!
Subscribe to:
Post Comments (Atom)
Having a rating scheme with an odd number of choices may result in everyone without a clear opinion to use the middle rate. This is a point my colleague often points out to me.
ReplyDeleteI like your (or Micah's) idea. Would be interesting to do the same thing not only for code, but also for unit tests and acceptance tests, maybe in combination with explaining the odds from xUnit Test Patterns, FIT for Developing Software, and even Clean Code, may raise a great presentation - and help you grow on this. But it could be too much for a single hour.
Thats an excellent point. Micah also made the point that asking this many questions for every code snippet could be too much of a burden on the audience, and they might get bored. Perhaps then just 2 choices, good or bad, would do the trick.
ReplyDeleteAnother good suggestion. Perhaps I this suggests that there should be multiple sessions or talks questioning the quality of code ranging from acceptance tests to low level code.
I will take this one step at a time, see how it goes, and expand from there.
Thanks again!