Worried you’ll miss us?
Subscribe to get our articles and updates in your inbox.
I don’t know about you, but I used to love those little painting by numbers kits when I was a kid. For those of you who have never used them, they had pictures that were broken down into different shapes, each with a number in it. Those numbers in turn corresponded to a particular color, and all you had to do was match a color with a number and fill in that shape with the correct color. Here is a pretty extreme example of what I am talking about:
When you were done, you had a wonderful picture, without all of that nagging art talent! In fact, the creator of the picture was the one with all of the talent, all you had to do was just keep your paint (or crayon, or maker) within the lines and in no time flat you looked like you were actually capable of something! The problem was that the process of filling shapes didn’t correlate at all to the process of actually painting something. It is a bit like your friend who plays the guitar on Rock-Band and decides that he should now take up guitar. You know him, we all have that friend.
With paint by numbers though you didn’t need to understand color theory, shadowing, perspective, etc… All of the things that you must understand, whether explicitly or implicitly, in order to be a good artist. And to top that all off, no matter how long you did this you never got any better at drawing a real picture. Since the skills didn’t translate, you could paint by numbers for the rest of your life and still produce paintings that looked like nothing other than Jackson Pollock knock-offs.
All of this may come as absolutely no surprise to you at all, but as developers we do this all of the time. Consciously we know that programming does not equate to application architecture, but how many times are designs handed down from ivory tower architects to their underlings in order for them to “Program by Numbers”? Being able to fill in a method, or put a method on a class will never allow that developer to understand the intricacies of object oriented design or the complexities of system design. Developers can write code day in and day out for years, and still end up being absolutely terrible at writing software because they have never been given the training they need in order to learn the skills of design.
But we, as developers, should know better. How often do we complain about sub-standard code? How often do we complain about code that we wrote two months ago? How often to we complain about horribly architected systems? If we want to keep acting like what we do is a craft, then we need to start treating it like one. And that means training and sharing the knowledge of your craft with others…either a direct or indirect apprenticeship. More experienced developers can’t just sit around and expect college grads to come into the job with all of the knowledge they need in order to write excellent software. Just think about how much knowledge you have garnered since your earliest days as a green developer! If we want these new developers (and many old ones) to get better then we need to get rid of the numbers and start letting them think (and screw up) for themselves.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.