The Pragmatic Craftsman
:: Simplicity from complexity ::
The Pragmatic Craftsman
:: Simplicity from complexity ::
|
No matter who. No matter what. No matter when. Short term.Long term. Any term. Writing good code is ALWAYS faster than writing bad code.
—Robert Martin (@UncleBob)
|
Is it because of pressure?
Is it because you want to be faster than others?
Or is it just because that’s the way you’ve been doing things and it has worked for you?
I hope it’s not the case. I hope you take the time to do it right. Because if not, as the saying goes, will you have the time to do it over? Or how will you look at it when you see the project codebase turning into spaghetti. Because it will.
I wish it was so clear cut. It’s usually not.
But I do believe in the theory of broken windows. One little “slack,” one not needed “if” statement starts this process. And then it goes downhill. It’s just a matter of time before somebody else puts another if. And another. Soon enough, you start searching where things have broken. It’s no longer easy to fix stuff. So you put another conditional.
That’s how things degenerate.
I’ve seen it many times in my career.
But I try to do it right. I think about consequences of my actions. Consequences of putting one line of code that will make things worse for others, worse for the codebase.
I take pride and always try to leave things in no worse condition when I found it. If I can, I try to make it better. I don’t always succeed. But I try to adjust. Learn. And always have “do it right” attitude. I think it matters.
If we had more people that cared about the quality, our dev world would be a better place.
Related
Write Your Good Code First – blog post by James Sugrue and Uncle Bob’s quote that I found there that gave me motivation to write this post.
Nicholas Zakas, the author of what I consider the best JavaScript book out there, is becoming one of my favorite bloggers! (I should let him know about that. 
) In his recent blog post, he talks about qualities of great software developers. It’s a great post. I highly recommend reading the whole post.
Here’s my take on the qualities from the post.
Always do it the right wayI cannot agree more. There are always people that will say that they’ll improve it later; that this is special and it needs a special condition. It’s a big bull… You do it the right way ALL THE TIME. Really no exceptions.
Good engineers know that the right way applies to all situations and circumstances. If there’s not enough time to do something the right way, then there’s really not enough time to do it. Don’t make compromises, the quality of your work is what ultimately defines you as an engineer. Make sure that all of the code you write is done the right way 100% of the time. Expect excellence from yourself.
Be willing to sufferI never considered this as an asset before. On the contrary, I thought that it must be something wrong with me. I like to develop solutions in my head, thinking hard about them, then implementing. And later find a better solution. I rarely ask others for help. And I usually come up with good solutions. Hmm, maybe there’s hope in my software engineering skills.
Great engineers first and foremost want to solve the problem on their own. Problem solving is a skill, a skill that great engineers take seriously.
Never stop learningIf you have been reading what I write on this blog, I don’t need to say anything else. This is an absolute must if you want to be considered a great software engineer.
In order to be a great engineer you must first admit that you don’t know everything, and then you must seek out more knowledge in every way you can.
Share your knowledgeI believe that’s what makes you valuable to the company you work for. That’s how you distinguish yourself from others. This is how you think “big picture”.
Great engineers want others to know what they know. They aren’t afraid of losing their position because someone else can do the same thing. Great engineers want to see their peers succeed and grow.
Lend a helping hand
Great engineers are team-focused and therefore are willing to do whatever it takes to help the team.
Do I need to argue with that?
Take your timeIt takes time to develop and improve on your skills. The only way to do that is by learning iteratively, practicing. It probably will take 5 to 10 years, or even more, for you to acquire great skills. To acquire that craftsman’s touch.
ReferenceWhat makes a great software engineer?, Nicholas C. Zakas
As programmers, we want to finish things fast. We want to impress our boss. We want to be better and always finish before others.
So we do. We finish things as fast as possible. Because the requirement was to complete the things that were on the list.
Just make it work.
What’s the end result? Code that is hard to read by others. Code that is rigid. Code that is fragile. Code that is over complicated. Basically, code that has the characteristic of “fast food” — it does what is supposed to, right?
Wouldn’t things be different if one of the requirements was “high quality.”
The statement is ambiguous. Sure. It means different things to different people. It could be more specific: “code should be easy to read, easy to extend, and easy to modify.”
High Quality. Enough said.
You could argue what quality really means. That’s not the point. Just stating that it has to be of high quality puts everyone on the same page: it communicates the expectation to the team.
“Why don’t we just add a special exception here.” No, you would say. That’s going to lower the quality of the code. That’s going to make the code more fragile and harder to extend. It does not meet the quality requirement.
I personally don’t need to be told that — quality is always on my list. I always try to make the code that I write be of high quality. I put focus on that. I don’t always get the results I want, especially after I look at my code after a period of time. But I learn. I improve.
There is just too much of low-quality code around. Too much pressure to finish fast and no pressure on quality.
Having quality a requirement would make a huge difference. I strongly believe that.
Even if your manager does not require it, “High Quality” should be one of the most important requirements when you write code. It’s not easy to write high quality code. That’s for sure. You learn with experience, by trying things out. Patterns develop after a while. Then you study a bit more. But having that focus we’ll make you a better coder and distinguish you from the others.
Related
Code quality and the fat developer, very good post by Consulting jiujitsu
Uncle Bob wrote an excellent post, Speed Kills. Is there a tradeoff between speed and quality, he asks.
If by “speed” you mean delivering working softwarequickly and repeatably release after release after release; thenmaintaining high quality is your only option.
I couldn’t agree more. In the long run, the only way you can move fast at high speed is if you have quality. Time and time again, I come across projects that were finished fast, with the thinking that they will never be modified again. (I’m not even sure if that’s always the case, but rather that quality was not a requirement.) After a few months, things change. They often do. And the project needs to be modified. What is your speed then?
It would actually make more sense to rewrite the project. But that’s almost impossible. Too many dependencies. Too much coupling. Who can read that and understand? Too risky. At that point, the easiest thing is to do is just add a special exception, an “if” statement that would make the thing work.
And the project quality degrades.
And the speed decreases.
Frustrating? You bet. Especially if you are not the original coder.
Wouldn’t it be easier if it was written with quality in mind in the first place?
Reference
Speed Kills by Uncle Bob
If you consider yourself a good programmer, great! But is this going to hold true, two years, five years from now? If you are not going to learn new things, I can safely say that you’re going to be “out of date.”
If you want to stay still, you have to continue moving: being a good programmer means learning new things constantly.
Here are 10 Ways to Learn New Things by Philosophical Geek. Follow at least some of these and I think you’ll be covered.
1. Read books.2. Read Code.3. Write Code – Lots of it.4. Talk to other developers.5. Teach others.6. Listen to podcasts7. Read blogs8. Learn a new language9. Learn the anti-patterns10. Be Humble
Reference10 Ways to Learn New Things in Development | Philosophical Geek
Ben Watson, whose blog I just came across, lists the following Top 5 Attributes…
I think this is a very good list. I think effective programmers are humble. Why? Because you have to be able to work well with others. Just from my experience, it’s hard to work with people with a lot of ego.
You just have to love to learn. Effective programmers constantly improve. How do you improve? By finding new ways of doing the things you’re used to… better. You have to be exposed to new ways in order to do that. Being able to adopt and having a passion for the profession are essential.
Reference Top 5 Attributes of Highly Effective Programmers” href=”http://www.philosophicalgeek.com/2008/01/20/5-attributes-of-highly-effective-programmers/”>Philosophical Geek -> Top 5 Attributes of Highly Effective Programmers, Philosophical Geek blog
Here’s what Ben Rady, who calls himself software craftsman, states under his Statement of Values. I value similar things: I can sign my name under this statement. Excellent summary.
As a technical leader, I value:* Talented People* Rapid Feedback* Individual Relationships* Facilitation over command and control* Continuous Improvement* Frequent Delivery
As a programmer, I value:
* Working Software* Clean Code* Rich Communication* Flexibility over efficiency* Sustainable Pace* Simplicity* Failing Fast over hiding errors
As a human being, I value:
* Courage, not cowardice* Humility, not hubris* Compassion, not callousness* Curiosity, not apathy* Discipline, not carelessness* Honesty, not deceit* Patience, not intolerance
ReferenceStatement of Values, Ben Rady
Here’s a great definition of what a software craftsman is. It’s also similar to the way I think. And this is also part of the Introduction in the book Agile Java.
I am a software craftsman. I have spent much of my software development career trying to quickly build solutions to problems. At the same time I have tried to ensure that my solutions demonstrate carefully crafted code. I strive for perfection in code, yet I know that it is unattainable, particularly with the constant pressure from business to get product out the door. I take modest pride in the code I build daily, yet when I look at the code I wrote the day before, I wonder, “What the heck was I thinking?” This is what keeps the craft challenging to me—the constant desire to figure out how to do things a little better the next time, and with a little less pain than this time.
ReferenceSafari eBooks – ACM – 0131482394 – Agile Java™: Crafting Code with Test-Driven Development
I found a great, pragmatic, and simple to understand definition of what a craftsman is from Dean Wampler, read below.
Am I a craftsman? No. Not yet. But I work hard in that regard. Besides the first quality — being widely recognized — I think I can get good marks in the other characteristics. I strive to deliver quality; I am passionate about coding; and I continuously learn.
A craftsman is widely recognized by peersRino recently won an international competition in Italy, one of many times he’s been recognized nationally and internationally.A craftsman is passionate about the craftRino says that if you are passionate about food, you will work on the presentation of even humble dishes. Pasta, as well as lobster, deserves an attractive presentation.
A craftsman delivers value to the customer while meeting business objectivesRino keeps the kitchen lean and efficient. He keeps costs low by relying on high-quality ingredients, keeping waste to a minimum, and constantly improving the skills of his staff, all without ever compromising quality. In the year Rino has been at Pazzaluna, costs have dropped, while business and profits have increased.
A craftsman knows that quality is the number one priorityRino knows that cutting quality today means less business tomorrow. He keeps quality high by keeping morale high. Morale is high because his staff is constantly learning new and better recipes. Also, as you watch him interact with his staff, you can see that he treats all of them, from his sous chefs to the dishwashers, with dignity and respect, while always holding them to high standards.
A craftsman never stops learningYou would think that he knows it all, by now. Yet, he has never forgotten a lesson his own mentor taught him, “you can learn something from even the worst cook, because he always knows something you don’t!” How many gurus do you know that think they have nothing left to learn?
Dean Wampler on Craftsmanship
What does all this have to do with software? Pretty much everything. Like cuisine, clean code is part art, part science. Clean code is created by passionate craftsman who are fanatical and fastidious about every detail. Clean code is the product of years of accumulated experience. The decisions a master makes moment-by-moment, whether test-driving the next feature or fighting a fire, reflect the wisdom and breadth of knowledge that produce high-quality results quickly and efficiently. Finally, a master leads by example, bringing the rest of the team up to his or her standards.So, if you’re young and ambitious, latch onto the mentors around you. If you can’t find any, find another job. (Your organization is doomed anyway; so you might as well move on now.) If you’re older and wiser, seek out the promising junior people, teach them what you know, and learn from them as well! Oh, and if you want to taste real Italian food, make a pilgrimage to St. Paul. Tell Rino I sent you.
ReferenceWhat I’ve Learned from Master Chef Rino Baglio, Dean Wampler
Practice makes perfect.
I think you can agree with me on that. To become a craftsman, you not only need to acquire new knowledge and new skills, you need to be able to apply that knowledge, be able to polish your skills, and improve the output every time. I don’t remember who said it, Mozart I think, that every time he played the same piece, he did it differently. He was always looking to improve it. That’s the type of mentality of a true craftsman. And that’s what I need to develop to become a true craftsman.
Practice new technologies: put your knowledge to the testOver the last few years, I must have read 20-30 software books. I learn a lot, no doubt. But rarely do I actually put that knowledge to test. I just read, make notes (sometimes), and move on to another book. Doing it this way, I think my knowledge is not deep enough. I really cannot do anything with it, and I easily forget it.
I need to read a little and be able to put that knowledge to practice: I need to apply it. How do I do that? By writing a project based on that technology. By practicing — playing — with the new technology.
For instance, I want to learn Ruby (and Rails). Before I can say that I learned it, I should build a website or another project in Ruby. Only then I can say that I learned Ruby.
Same with any new technology. To really learn it, I should create my own project based on it. Anything new, whether it is a pattern or a technique, before you really learn it, you need to be able to put it into context. Ask yourself, how can I put that technology to use?
Practice to polish your skillsIn an ideal work environment, we would get to work on new and different technologies fairly often. That does not happen in the real world too often (or you’re lucky). As a result, we stagnate and get used to our working environment. I don’t think that’s a good situation. As a craftsman, you can never let your skills stagnate — lose freshness. You have to stay abreast with new technologies, acquire new skills constantly. But how? On your own!
Use your down time at work to freshen up on your skills. Once again, practice comes into play. Think the project you’re working on could benefit from migration to a newer, better technology. Do it! On your own. Start a new project, and migrate the old project to the new technology. Doing this keeps your skills fresh. You’re gaining new skills.
Playing with new technologies is very important. If you cannot do it at work, you need to find time for it, whether at work or at home.
Practice to polish — improve — the productEvery time you build a product, always strive to make it better. Better than your previous one. That’s the mentality of Mozart. I think that’s a mentality of a craftsman. And that’s what you want to become, right? Then you have to have that mentality! In design meetings, suggest a better way; when designing on your own, reflect and see what could be improved from your last project.
By practicing continuously, you’ll be able to see how things can improve. You’ll be able to build on your skills. You’ll be able to keep your skills up to date. This is key to getting better, improving your skills, and becoming a better developer, a craftsman. And remember: you can never stop practicing!
Once again, and that’s the bottom line, to move into architecture, to move up, to become a craftsman, you need a lot of practice. You need to continue practicing or you will not be “crafting” but “hacking.” Practicing takes time, but that’s the only way to make sure that you “got it.” BTW, as a craftsman, you should be loving it!
