Anyway, back to the point that I’m trying to make here. The only way I can learn is by actually doing development work, whether its as big as a two year project or as small as a Code Kata. In order to become a software craftsman someday, I need to practice. Lots and lots of practice.

I also learn a lot from reading books, articles, blog posts, watching screencasts or video recordings from conferences and last but not least by reading code from respectful open-source projects. But in the end, they only sharpen my theoretical skills. In order to really challenge my thoughts, I need to be practicing.

Practice is what makes people craftsmen in other fields as well like surgeons, plumbers, repairmen, etc.. But for some reason, developers think that they can sit back, write code from nine to five and muddle on. While there is a time and place for everything in our lives, this particular attitude makes that the state of our profession can be much compared to the dark ages. We need to become better at what we do and who we are.

Somehow related, I completely agree with this blog post from Uncle Bob where he talks about being responsible for your own career.

YOU, and NO    ONE ELSE, is responsible for your career. Your employer is not responsible for it. You should not depend on your employer to advance your career. You should not depend on your employer to buy you books, it’s great if they do, but it’s not really their responsibility. If they won’t buy them, YOU buy them! It’s not your employers responsibility to teach you a new language. It’s great if they send you to a training course, but if they don’t YOU teach the language to your self!

Every book I’ve ever read about software development is a book that I bought myself from my own money. All the magazines I’m subscribed to, I pay from my own pocket. I’m responsible for my own learning, and I’m willing to invest whatever it takes to accomplish that. Whenever I want to learn something new, I’m not waiting for my employer to give me an opportunity. I make my own opportunities!

I realize I’m a bit late for the previous Butter’s Monthly Bone. I can only hope that Butters won’t eat me alive .

Books

I can’t go to sleep unless I have read for 30 minutes or so first, but I typically don’t read technical books during this time.

I have been carrying technical books to my kid’s wrestling practice, though and I do a LOT of reading on meet days where I wait 6 hours for 4 matches to occur while sitting in the bleachers. Books are important and choosing them carefully is a big deal because our technical books are so darn expensive. Anyone want to form a book exchange club?

Books are great, but they typically convey ideas without complete understanding. Understanding for me comes only through practice. For me, creating software is just like playing an instrument.

Reading about a technique doesn’t give it to you. You must actually practice and fail before earning it.

Blogs

I use blogs as filler in my day. I read on the train (no train in Boise) and while waiting at the airport, etc. I probably spend 30 minutes a day reading blogs on my iPhone via the Feeds application tied to my Google Reader. It’s great.

It can get overwhelming quickly, though. So I have backed off to a manageable number of blogs that resonate with me.

Blogs hold a wealth of information, though. I often find new ideas in blogs where books offer only well presented rehashing of existing ideas. Blogs also tend to be very context specific, so I have a better chance of finding someone who shares my pain than to read about it in a book.

Katas

I firmly believe in coding katas. From Wikipedia:

Kata (? or ?, literally: "form") is a Japanese word describing detailed choreographed patterns of movements practiced either solo or in pairs.

Note “practiced either solo or in pairs”. Wildly appropriate for learning a new technology isn’t it?

Katas are prescribed movements, like following a detailed Hands on Lab. They don’t get you to mastery and they aren’t intended to. Practiced over and over, katas and labs are powerful tools to introduce muscle memory so that when the time comes for sparing or writing the actual application, the technique is in your head.

It is also my experience that like katas, repeated passes through technology tutorials will produce deeper understanding with each successive pass.

Learning by Doing

The thing about any craft is that it is not enough to understand it. This is the difference between the academic and the practitioner. One must have both a fundamental understanding as well as the muscle memory of execution to be considered a master of any craft. I can read until I am blue in the face about carpentry, but if I try to cut a straight line, the first 10 will be crooked.

For me, the motion of performing the exercise may take a repetition or two until it sticks, but once it does I am able to proceed to the next level of understanding: The ability to intelligently question the technique. I don’t dare open my big mouth like this, until I have worked with the system enough to understand what I am questioning.

The repetition in the motion of doing is required for fundamental understanding beyond unapplied theory. That’s why “non-coding architect” is a derogatory term.

First up: what the heck is Apologetics?  (note: it isn’t the same as apologize)

Apologists are authors, writers, editors of scientific logs or academic journals, and leaders known for taking on the points in arguments, conflicts or positions that are either placed under popular scrutinies or viewed under persecutory examinations. The term comes from the Greek word apologia (????????), meaning a speaking in defense.

Wikipedia (http://en.wikipedia.org/wiki/Apologetics)

As for Evangelizing, it is similar but different.  There are many definitions, but I’m going with the Prinston definition:

evangelism (zealous preaching and advocacy of the gospel) (reference)

In my definition, an Apologist is sitting down with someone and have a discussion.  An evangelist is up on a pulpit proclaiming the good news to any within hearing distance.  The difference between the two is key, because both are trying to achieve the same results.  But I find the apologetic version much less grating.

Apologetics does not imply always apologizing.  Apologetics are not apologizing for bad software, bad practice, or bad code.  Apologetics does not imply rationalizing or defending bad code.  Apologists are trying to gently guide to betters methods of software development. 

This is to counter many of the evangelists that I’ve seen, who start of by looking shocked, then angry.  And if at first you don’t succeed, add volume.

My introduction to Apologetics comes from my Christian faith and the works of John Calvin and Francis Shafer, but the notion of the idea goes back much farther — biblically speaking.

“Come now, let us reason together, …” (Isaiah 1:18, ESV)

“…, always being prepared to make a defense to anyone who asks you for a reason for the hope that is in you; yet do it with gentleness and respect. (1 Peter 3:15)

There is nothing bombastic about apologetics.  It is inviting and striving to bring others in, but also not shying away from hard topics.  What I see far too often programming circles cutting, degrading, and bombastic.  There is too much “my way or the highway” in the approach. For me the key fraise is from 1 Peter (above), “yet do it with gentleness and respect”.

Truth is, I want to be proven wrong.  If someone can come to me and tell me that I could be doing something better, how to do it better, and why it is better — that makes for a great day.  After all, In programming there should be no dogma and no sacred cows.

This is essentially what I do every single time I blog.  I propose an idea, I ask people to tell me I’m how I’m wrong.  My blog is kind of like a personal testing ground.  I do not deliberately try to be wrong, I do not play devils advocate in print.  But I fully believe there are people out there with better ideas than mine.  My problem is that I rarely come to them on my own.  All of my best software was written with a group of people.

See, this is also not just a blog ethic.  This is a work ethic as well.  I try to encourage people that I work with to question what I say.  I do not want to work with a bunch of yes men, blind faith belongs somewhere else.

Now, to flip the request around to everyone else, that mean you dear reader.  Encourage people to do the same to you — and appreciate it when someone does just that.  Being proven wrong is not a sign of weakness, it should not be seen as an insult (correction should also not be delivered as an insult either, but that is another topic), it is a learning opportunity.

So best case, you might learn something new.  But also a good case, you might be able to help teach someone else something new.   If you reach an impasse — just learn to disagree.  But hopefully you both learn about each others position, making you both better off.  If need be, both think about it for a day.

Really, what we do is about ideas.  And we should be prepared to defend those idea.  But we should also be ready to drop them at a moments notice in favor of better ones.  This shouldn’t be personal, it should be improvement.

Programming is all about what you know, and all of us are limited by experience.  No one can know everything, we all have holes in our knowledge and experience.  We have to rely on others to help fill in our gaps.  And experience is the key, that is often what drives knowledge in the first place.  Please keep that in mind. 

Experience is the type of projects someone has been on, the people they have worked with, the books they have read, the problems they have faced.  All of those factors will lead a person down a particular path.  Sometimes good, sometimes bad.

So please, if you think I’m full of it, let me know.  

A software developer’s primary goal should be to create value for the users of a system. Value can mean a lot of things here. First and foremost, it should be about things that users actually experience. Features, ease of use, performance, etc. You can get all of those with crappy code, but that leads to a situation where you won’t be able to sustain that value in the long term. A system can be very useful to its users, but if the code is in such bad shape that it can’t easily be maintained and extended with new features over time, the value of the system will slowly reduce. New features will introduce new bugs. Bug fixes will introduce new bugs. Eventually, the system starts to collapse under its own rot and the dreaded rewrite commences. Nobody really wants this, do they? If you write good, clean code from the beginning, you can usually avoid these problems.

A lot of opinionated developers claim that a true craftsman developer will never write a piece of bad code. In an ideal world, i would agree. These same developers also look down on people who implement a quick fix instead of looking for the proper solution. Again, in an ideal world i would agree with that. In the real world however, i’m not so sure if that’s always the best thing to do.

Those of you who’ve been reading my posts for a while know how important clean code is to me. I generally hate crappy code and i generally hate quick fixes that don’t fix the real problem. Then again, i do realize that we sometimes need to put our principles aside in order to be able to deliver value to our users.

Allow me to use an example to defend my position on this. I recently had to fix a nasty bug in NHibernate. Once i found the true reason for the bug’s existence i had two options to fix it. The correct solution would have required me to modify some crucial parts in NHibernate. The easiest fix required me to modify one non-essential class in a manner that couldn’t impact anything else.

Certainly, a true craftsman would go for the best solution, right? Well, let me tell you something about the NHibernate code base… it’s pretty big, it’s quite complex, and it’s been worked on by a lot of people over the years. There are parts of the code where you really don’t feel comfortable making drastic changes. Sure, we have our test-suite, but it unfortunately doesn’t cover every possible thing that could go wrong.

I chose to implement the easier fix. The bug was fixed, which means that the fix created value for everyone who’s using the trunk (which is more people than you’d think) and it means that this bug (which was a show-stopper IMO) won’t delay our 2.1 release. The correct fix would’ve meant making a risky change at this point, which could’ve led to more bugs that we don’t have tests for yet. The correct fix will be implemented right after the 2.1 release, when we have more room to make drastic changes to core parts of the code.

Was i wrong to implement the easier fix? I don’t think so… although i’m still not happy about that fix. But we have a responsibility to release software. If we would always stick to our principles, that could sometimes lead to having to delay or postpone a release. While there are many valid reasons for delaying or postponing a release, i don’t think merely sticking to your principles about a piece of code is always the best thing to do.

Of course, you do have to have the discipline to pay back the technical debt you’ve incurred when you do this, but sometimes the cost of that technical debt is less than that of having users losing faith in your product. And that, in general, is something we as software developers need to keep in mind as well. Writing good, clean code is great. We should all strive to do that. But we first and foremost need to create value for our users.

Besides writing clean code, we as software professionals should also adhere to a number of qualities as well:

• We shall act in the best interest of our client/employer, not losing sight of the greater good.
• We shall deliver products that meet the highest standards possible. We must always do what’s right, under all circumstances.
• We shall remain independent in our professional judgement. We must never loose our professional integrity.
• We shall be supportive for the members of our team and encourage them to adhere to the same principles.
• And last but certainly not least, we shall dedicate our professional lives to continuously improve ourselves and be open to share the knowledge we already gathered. We shall accept that this journey of continuous improvement will never end so that we remain humble and open in order to continue that journey.

Earlier this week, I received my green wristband from Object Mentor.

Whenever I look at that wristband, it reminds me of my commitment to the principles of clean code and ethics of a true software craftsman. Its like physicians who make the Hippocratic Oath. It also reminds me that if I don’t follow these principles, Yoda will kick my @ss .

I don’t know about your dog, but here at Elegant Code our dog, Butters, will worry a bone until there is no meat left at all. When she is done, the bone is a mere husk of dried calcium with nothing left to offer.

That is the idea behind this new site feature is simple. All Elegant Code writers will add at least one post to a common theme for the month, thereby leaving nothing but a dried husk with nothing left to ponder. This should be fun because we all have different takes on these things.

Please drop us a line to suggest Butters’ Bone topics for the month. Note the better topics will not be 100% technical because strictly technical topics don’t always lend themselves to various perspectives.

So, watch for the first topics of the feature for January, “Ethics in Software Development.”