From the Inside: January/February 2013
Do you think you are a good coder? Have you been practicing your coding, or have you just been doing your job?
If you haven't been practicing your coding, then you are likely getting rusty in it. When you are a musician or a sports star, you have talent and practical demonstrations of what you can do, but you practice, practice, practice.
Most of us assume that our day to day software development is our practice. But this is not the case. Let's use basketball as our example. Your day to day software development is much like an NBA Game. This is where players make their money, but they spend most of their time reacting to the game and other players.
Players then spend time between games to practice their jump shots, layups, and passing in order to do better in the games. This is what you as developers need to do.
This is also where "Code Kata's" come into play. Code Kata was a term coined by Dave Thomas, co-author of the book The Pragmatic Programmer. A Code Kata is an exercise in programming which helps a programmer hone their skill.
I thought this was a novel concept, and decided it would be interesting to introduce the concept with MultiValue Developers.
Let's look at Dave's First Code Kata (pricing goods at supermarkets) (intl-spectrum/s1058). Kata One - Supermarket Pricing
Some things in supermarkets have simple prices: this can of beans costs $0.65. Other things have more complex prices. For example:
- Three for a dollar (so what's the price if I buy 4, or 5?)
- $1.99/pound (so what does 4 ounces cost?)
- Buy two, get one free (so does the third item have a price?)
This kata involves no coding. The exercise is to experiment with various models for representing money and prices that are flexible enough to deal with these (and other) pricing schemes, and at the same time are generally usable (at the checkout, for stock management, order entry, and so on). Spend time considering issues such as:
- Does fractional money exist?
- When (if ever) does rounding take place?
- How do you keep an audit trail of pricing decisions (and do you need to)?
- Are costs and prices the same class of thing?
- If a shelf of 100 cans is priced using "buy two, get one free", how do you value the stock?