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.
That is my role here in my codeshop, I’m looking for better ways to make things, I explain it to teams, we experiment and try to understand the pros and cons together.
Programming by numbers never give good result in the end… and I have hard work taking everybody to the next level.
Nice analogy…well said!
Nice analogy and nice post.
Nice analogy, but you have to be a little more specific than just saying, "[i]And that means training and sharing the knowledge of your craft with others…either a direct or indirect apprenticeship[/i]"
Time is always a precious commodity in a software development project. What are the effective ways in which you can get developers to think and screw up for themselves, without causing major risks within the project? I think without addressing this issue in the context of actual project execution is not useful, even though you raise a very good point.
@Krishna Well, when I said indirect, I was speaking mostly about sharing knowledge in general. People who give talks, write books, write blogs, etc… are indirectly mentoring.
On the other hand, people who are in a position to directly mentor someone else needs to guide a person, but also needs to let them try their hand at design and then correct them when they are wrong. This *should* be happening in all projects through code reviews, but the amount of guidance during the design should be scaled depending on the experience level of the person.
As a side note, I enjoy your blog.
hey, that’s my drawing! thanks for using it, i got a giant boost on my flickr page 🙂 i enjoyed your article, it’s cool when worlds collide like that.
@julp It is a great picture! Thanks for sharing it under a CC license!
Justin, I like your point about code reviews. I would be interested in reading about other practices (perhaps in a longer post) that you have seen work at companies.
On a tangential note, with the advent of powerful frameworks for web applications and so on, sometimes there is less need for design in certain areas. I wonder what the long-term trend would be: the scope of design reducing as frameworks and common best practices gain more adherents.
([i]Thanks for your comments about my blog[/i])
@Krishna I honestly wish I could say that I have seen other practices that worked in other companies. I’m not sure that there is a good formula for how to do it, but it all comes from creating a culture where the more experienced developers want the junior developers to be better. I have a few ideas about this, and maybe I’ll write up a post about it.