Walking to campus yesterday for my second day of classes, I was struck by an analogy that I decided to share with my students. I started the class by asking, "Who here plays an instrument?" A little less than half the class raised their hands. Then I asked, "Who is a musician?" Fewer raised their hands. "So, what's the difference?"
I received a great range of answers, which I acknowledged without judging. These included:
- Musicians can compose.
- Musicians can interpret compositions.
- Musicians perform for other people.
- Musicians are part of a culture of musicians.
- Musicians have more skill.
- Musicians spend more time on music.
Then, I posed this rhetorical response, "OK, so what is the difference between a programmer and software craftsman?"
The point was made, I think. We did not dwell on it, but I could see that it planted a potentially useful seed in the students' minds as we begin fifteen weeks of developing new attitudes and practices around software development.
(At the beginning of every semester, I explain to my students what it means to be on time: it means you are seated, attentive, with your laptop and notebook ready. More specifically, if you come in right before the "bell," you're late, because we start on the hour. I often contextualize this policy by explaining that I am a musician, and musicians know that if you're not early, you're late. This always gets some smiles and nods from students who know how this goes. I'm sure this was an inspiration for my coming up with the analogy.)
That's really neat to think about. Too often once I started work, I've realized that there's less chances to really be a "Software Craftsman". But I think trying to aspire to this is infinitely useful for programmers today. You never know when it will come in handy. I also have Clean Code sitting in my shelf at my desk and see it glaring at me all day while I work and don't follow the practices ;n;
ReplyDeleteEither way, I love it Dr. G, I hope this year, and these groups for this matter, really stick to these ideas and make it a good one! :)
I try to push myself to follow Clean Code, in part so that I can generate more insights and stories to tell my students. I've come to find it valuable, and I think students appreciate thinking about this kind of craftsmanship---the kind of skilled creativity that can set them apart from the crowd.
DeleteThe semester is off to a good start, so here's hoping we can keep it up!
That's something I really need to do. I'm thinking that at some point I'm going to have to work on a strategy rpg game as a personal project and really refresh myself on clean code. What most people don't understand about it is, is that it really sets you up to not have as many problems in the future, and I wish all of the code where I work had taken that into account. Unfortunately once code is dirty, it's almost impossible to clean it, unless you want to start from scratch, which isn't an option most times.
DeleteBut I'm really glad to hear that it's going well! I'm sure you'll be able to keep it up, I definitely felt the need to keep the environment in a good place in your class, and it was definitely my favorite!
I'd love sharing differences between the real world and what you teach in your class. Not in disrespect your values and lessons, but to add prospective.
ReplyDeleteI remember the shock when I was working on production code at my first job, and the code was absolutely awful. There were huge chunks of commented out code, irregular naming conventions, naming conventions leftover from legacy code that this stack happens to connect to, etc. One of the rules of Clean Code is the Boy Scout Principle of leaving code better than you found it. Unfortunately, your boss may not understand the implications of following such things, nor do your coworkers coding beside you, or the people who wrote the code however many years ago. Clean Code is not the bible of software production industry wide. Most people have no concept of code cleanliness, or have the discipline to follow it.
Strive for craftsmanship, perfection, intentional design, and clean, predictable code. However, realize that you may not always have the luxury of these pursuits. Sometimes (or most of the time) you have to work with the code that is already in place with whatever timeframe you have to get your job done.
If you're lucky enough to have a craftsman for a boss who is in charge of whatever project you're working on, then suggest Clean Code being a part of the team's ethos.
Also almost everything I compiled at my first job at at least 50 warnings in it, sometimes 300+ warnings. What did they mean? *Shrugs*
Delete(These were between one or multiple C# project files I'm talking about, not a single class)