Writing for the future

I’m a big fan of folks like Robert C. Martin and Martin Fowler. I think they have very interesting things to say and I stand by all of what I’ve read from them. Even if you disagree with their particular ideas, the concepts they put forward should make you, as a professional programmer, think.

Writing programming code can be really hard, but once you’ve got the hang of the platform you don’t usually run into that many problems. I haven’t really been clueless about how to solve a particular problem in years. I’ve always had some idea or some possible solution to work with. Even learning the Procurios codebase is not hard in the sense that I’m having difficulties coping – it just costs time to comprehend code you haven’t seen before.

To make a bad analogy: cooking can be daunting when you have to make your first dinner meal, but once you’ve made dinner a couple times it’s not so bad. Even while things may not pan (lol) out as you’d hoped when you started, the results are usually consistent and pleasurable enough. But that doesn’t make you a chef.

And so does writing code not make you a professional programmer. Even if you produce a consistent quality of code, if that consistent quality is mediocre or if your quality consists of consistent inconsistence, you’re just not a professional programmer.

Robert Martin speaks of being a software craftsman. I love that term. It makes me enthusiastic about what I do, because I’ve always experienced a passion in writing software that engineer just doesn’t completely convey.

Being a craftsman is about having talent and working very hard. I’m not so big on talent; to me talent is a collaboration of some affinity for math and structure, and actually liking the subject. If you like programming and computers and the whole what not, you probably won’t have so much trouble putting in the time. You may not become a true godlike programming genius, but like me you will be happy being the best ungenius that you can. It’s the working hard part, the constantly striving to be better than we are, that matters.

And like a great chef, a key component of our trade is our presentation. Sure, food has to taste great and be healthy for people – but it’s not great food if it looks like it was just splattered all over the plate. If some other chef came in a minute later to put the rest of the food on the plate, he’d have to clean up after you before he can do his work. Or, he’d have to accept the mediocrity of the plate and work with what he has, accepting that he has no chance to produce a fantastic product right from the start.

I’m not saying that clean code, because that’s what I’m talking about, is more important than working, efficient code. It’s not. It doesn’t even come close. But writing clean code is what distinguishes the programmers and the craftsmen, the boys and the men, the strangely feminine and the awkwardly Canadian.

Clean code means cleaning up after yourself. It means leaving the code base in a state that others can continue working with. It’s not just about conventions, it’s about making sure that the code base is readable, understandable and testable. How that exactly looks is always an interesting point of discussion – a discussion you need to have with your team.

Whatever you think about it, the important part is to keep thinking about it, to keep improving, to keep what works and to discard what doesn’t work. To keep striving to be an excelling software craftsman.

What do you think about clean code?