Dear Uncle Bob,
Like many other developers around the world, I got my hands on “The Clean Coder” a few years ago. I stumbled upon it almost by chance: I think it was referenced by the book “Essential Skills for the Agile Developer” (Shalloway, Bain, Pugh and Kolsky)…
Anyway, it was a shock. Not only did the book describe all the situations and issues I had encountered so far as an IT employee, it also proposed solutions for handling those situations. And since the argumentation seemed sound to me I decided to… try those solutions myself.
Many of those I tried at work: I learned to say no, I learned to say yes and take responsibility for it. I would also practice skills at home, like test-driven development or applying SOLID principles. I would read blogs (DZone is my friend!) and watch webcasts: technical, non-technical, about Java, Ruby, BDD, testing, Scrum, Kanban, functional programming, anything I would find interesting.
I challenged every approach related to code writing: how to organize a team’s work, how to write clean code, how to name classes and methods so that code reads great, how to write clear tests, etc.
Every new piece of acquired knowledge would bring one more answer to the question… THE question. The one that every caring developer is trying to answer, that every professional programmer is asking himself every single day:
“How to make working, maintainable, scalable software?”
We all know that, year after year, the programming craftsmanship evolves. And not only from a technical point of view: the methodology, the philosophy of coding evolves. We all question our work and the way we do it and we all want to tend towards excellence and professionalism…
Of course as soon as I would have a “revelation”, or when I tested something at home that would bring me to a certain conclusion, I would go at work and wait for the right moment to share it. I would try and tell it to anybody that would listen because I thought that would motivate them in fixing our work, in solving the issues we were having delivering a stable, trusted application.
The feedback I got back was… sad, really.
“TDD is useless”
“Have you tried it”
“No, don’t have time for this”
(okay, right… )
“We have stabilized and covered the crappy, unstable legacy code we received”
“What? After one year you haven’t implemented a single new feature?” said the IT Director
(I should mention that legacy code we received, a 3 years work performed by external people, would not compile, deploy or run… )
“We don’t do versioning, we just zip the various versions on a shared folder”
And my favorite one, after sending a few links about TDD to my Team Lead:
“Everybody can write anything on the Internet. Don’t believe everything you read”
(okay, sorry about trying to share knowledge. I guess Kent Beck or Robert C. Martin are just a bunch of theorists unable to write some decent code, right? Who’s heard of the Agile Manifesto anyway?)
So here I am today: an unprofessional developer during the day, but a wannabe-professional coder at night.
On one hand I’m unable to provide quality work to the persons who pay me because hey, I’m just a developer and I’m told to do it their way.
But on the other I am certain that there are better ways to program, for I have tried them myself and saw the results. There are ways to write clean, risk-controlled, maintainable applications.
It’s uncanny how people rejects change. Einstein once gave his definition of insanity:
“Doing the same thing over and over again and expecting different results.”
And yet I am invited at work to do the same things I did before, yet expect that somehow, this time, it’s going to be a success.
It IS insane, I agree. So I’ve decided to do something about it.
As a starter, I’m going to run a blog where I’ll share my experience, no matter how little or naive it is. Every observation, every trick, every opinion I have will end up in there.
And the first post I’ll write will expose the exact reasons why I decided to start that blog.
It’ll be an open letter… to Robert C. Martin, because for me that book of his was a catalyst for continuous questioning and improvement.
It’ll start with something like:
Dear Uncle Bob,
Like many other developers around the world, I got my hands on…
(Oops, a recursive post!)
Wish me luck!