The Software Craftsman
by Sandro Mancuso
Date Read 1/2015
I just finished a book on software craftsmanship: The Software Craftsman – Professionalism, Pragmatism, Pride. It’s a good intro to what a craftsman does and what he should do.
I enjoyed reading it. Throughout the book I kept nodding, saying “yes,” or “agreed.”
It’s a good book for junior programmers. It can help you get on a right path. It can give you motivation to do things right. I would have enjoyed the book a lot more earlier in my career.
For more experienced people, for people that consider themselves a craftsman (like myself), it’s a quick and enjoyable read. I did not learn much, though. So in a sense, I could have spent my time elsewhere. But I think it’s good to find out that people think “like me” are out there. It’s good to read about their experiences. Plus, it’s a quick read.
I did learn a few things.
The author gave me an idea to try in our daily standups. I will introduce “What have you learned yesterday?” question. The team I manage has learning as one of our principles. It’s a good idea to raise the importance of of, and be reminded on a daily basis. I will do that.
The 2nd motivation I got from the book is about Community of Practice. I am thinking of starting one at my company. It will be based on best practices, new technologies, things worth checking out, etc. I think it’s a great idea that will allow me and other seasoned developers to step up and share some of the things we’ve learned.
Those learnings seem small but I consider them big. They’re leadership activities, IMO. And having learned that from this book makes it totally worth reading for existing craftsman. You will probably learn a few things from it as well.
“One of the differences between a great programmer and a bad programmer is that a great programmer adds logging and tools that make it easy to debug the program when things fail.” [reference below]
I’m sure you’ve experienced a good share of mystery/quiet/business-as-usual failures.
Wouldn’t it be nice to have code that is smart to detect error conditions and make it obvious?
There are many ways of doing the communication. Some are trivial and easy to do. Some require extra thinking. Some require that extra step — step which is not in acceptance criteria.
Logging is one. It falls under the “trivial and easy to do” category. I feel we’re not utilizing it to its full potential. I’ve seen many instances where error conditions are not visible in logs. When we debug issues everything works as expected. So it seems… Then what? We need to keep digging. We’ve got to turn into code and look for clues. It’s time consuming. It’s frustrating. Wouldn’t it be better if we got a clue from the log?
“When the program works as expected, there is often no difference in the quality of the logging. However, as soon as the program fails, or you get the wrong result, you can almost immediately tell the good programmers from the bad.” [same reference]
Exactly. Logging gets a bad rap. But it’s invaluable in situations like those. It’s a great lead in finding the underlying cause of the issue.
So think about those error conditions. Check that the object you’re working on is in a “correct” state and if not add a warning message. Those warning and debug statements serve as an excellent documentation tool! Think of them as live comments.
Most of our loggers are accessible via JMX. That means no restart is required to change a log level. Very convenient!
There is really no reason why all of us should not be utilizing logging.
Logging is just one way. There are other ways. Think of stats/counters/jmx/dashboards. These require that extra effort and thought but are critical in communicating the health of the system. And there are cases where logging might be excessive when we expect an error to happen frequently. It’d be better to 1) output a message about a fail rate once a minute or so and 2) have stats accessible via jmx/dashboard. That allows us to see if the feature we built is working as expected, but also monitor performance/usage/etc.
I’m sure there are other ways.
But the bottom line is that we shouldn’t just be asking “does it work?” but how am I going to debug it things don’t work? How is it going to respond to error conditions? How am I going to validate that it actually does work?
If you learn to write debuggable code there are a few things that will happen.
1) You will become a better programmer
You’ll start thinking of the end result. You’ll cover the edge cases and “share” those unexpected values/conditions. You’ll be delivering smarter and friendlier code.
2) You’ll reap the benefits when debugging issues
It’ll happen. It’ll happen sooner than you think. And you’ll be thankful that you or somebody else took the extra care and added those debug statements/stats/etc.
Writing debuggable code takes effort and skill. But those extra steps, that extra effort is what distinguishes the good from the best.
Great Programmers Write Debuggable Code
Do you feel like your RSS reader is becoming overloaded? Noise-to-value ratio is too high? Then you are ready for this exercise! Read on.
If you’re like me, you follow this cycle: I find somebody new (via Hacker News, Twitter, dzone, etc) and I add the blog to a RSS reader (Google Reader, in my case).
However, if you’re like me, again, , you find it hard to remove people. So the list grows…
Up to the point where you feel overwhelmed, overloaded…
Not a good feeling.
Want a simple solution that works?
This technique utilizes folders. So if you don’t have any, create one and put all RSS feeds into it.
At the beginning of the year, you append a year to the folder and create a new folder with the same name as before. So if I have a “New” folder, or a “Good Stuff” folder, I rename it to “Good Stuff – 2012.” I create a new “Good Stuff” folder. New blogs go to the “Good Stuff” folder. If I see something interesting in the “Good Stuff – 2012″ folder, I move it to “Good Stuff.” After a few months, you’ve essentially filtered the old folder and extracted the feeds that are of interest to you. You then drop the folder and all it’s feeds.
I just went through the exercise and removed all folders with a “2011″ tag on it. I feel much lighter now. With room to grow. It’s a much better feeling than being overloaded.
Effective Programming: More Than Writing Code
by Jeff Atwood
Date Read 9/2012
I’ve been following The Coding Horror blog for at least a few years. When I heard that the author released a book, via a blog post on the blog, , I felt both excited and unexcited. Excited because I like author. Unexcited because I discovered that it’s mostly reprints from the blog. However, the price of $2.99 for the book pulled me in. And I’m glad it did.
You might have read a few posts from the blog, but most likely not all. When put together as a book, I was inclined to read it from cover to cover. My success rate on reading blog posts, especially longer ones, is low. So most of the material was new to me.
Excellent topics! Let’s take an overview of the sections:
Those are sections and they each contain a few chapters.
Easy to read. And fun! Most of the chapters are short. I love books like that. I can easily read one or two chapters on a train. This was a perfect book for that. The author can write. Sometimes he made me laugh. But I really enjoyed the easy to read, conversational style.
Filled with lots of tips. I’m not a newbie to programming, but I’ve learned a few things: few things about chairs, lighting, application pricing, ui, code reviews, testing, and lots more. Along the way, I kept saying to myself: I couldn’t say it better; I can’t agree more. Nothing really ground braking, but still…
Not all chapters were interesting. A few I decided to skip after reading a few paragraphs. But there were only a few, I think two or three.
A great book to pick up and read casually. You will enjoy it. I can almost guarantee that you will learn something new and find a few facts fascinating. And if you think books are too expensive, then is $2.99 too much? Now I get the chapter on pricing!
Almost all of us know the GoF patterns. Perhaps not all of the patterns. I forget them from time to time, but with more experience, I remember more and more. (I keep forgetting what a Memento is. )
As important as they are, I think there are other, perhaps more important patterns and principles that I follow. Some of them are “in my head” when I code. Some of them are there and I just follow them without naming.
They are fundamental theorems/patterns/principles of programming.
Good idea to review them.
Good idea to write about them.
Good idea to revisit them.
Don’t you think?
Languages and trends pass by. Principles and how we approach our programming tasks stays with us. Forever.
Once we have solid principles in place, we’re able to reuse it from language to language. Deepening and improving that knowlege has the highest return, I feel.
So I’d like to revisit SOLID principles; GRASP patterns. They’re at the heart of programming. Close to my programming heart, at least. More to follow.
focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.
–Steve Jobs in [BusinessWeek, May 25, 1998]
I am a TDD fan. I’ve been one for a long time.
But I’m not a TDD practitioner. I don’t follow the TDD methodology of writing the test first, implementation second.
Uncle Bob convinced me to try. Again.
Time to become a TDD developer! Time to step up my code quality.
I have said it many times, Robert Martin, Uncle Bob, is someone who has had a big influence on my career (you can find other references on this site). I usually buy all his books. His latest one, The Clean Coder, is not only a joy to read, it’s filled with great advice. It’s like reading The Pragmatic Programmers again. Who doesn’t want that?
Let’s get to the point, though. Why would I ever want to follow TDD? Isn’t that counterproductive, and… silly!
Do I want to write higher quality code? Faster? Less buggy? And get more fun out of it?
But I’ve tried before. And reverted to old ways of doing it.
This time, I want to infect myself with it.
How? By trying harder. By making this “my way” of doing things. And by actually writing the tests first.
It’s going to take more effort than that!
Today I got an opportunity to do just that. And I am surprised how I was able to kill a few bugs. Bugs that would have “bugged” me later.
But why write the tests first?
So I develop good coverage. So I design better. So I get instant feedback. Those are 3 very good reasons. Not only that, but by first thinking about the tests, I will cover more corner cases; I will make my code testable.
Do I really need more convincing?
Not really. Benefits are clear. It’s just a matter of “doing” it.
Lastly, to give some direction and insight on how to proceed, here are the three laws of TDD as per Bob.
The Three Laws of TDD
1) You are not allowed to write any production code until you have first written a failing unit test.
2) You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3) You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
Martin, Robert C. (2011). The Clean Coder
Ready to join the TDD camp?
While looking at the top weekly links on dzone (good way to see what are the important things that happened), I came across a very intriguing entry: The Top 10 Attributes of a Great Programmer by Steve Riley.
These always “get me,” but a lot of times they end up being just a quick browse. This one is different. Though the attributes are similar to what I”ve seen before (see entries in Craftsmanship category), they’re good. And it’s always good to re-read them.
Here are the top 10 form the blog. Read the whole post as the author gives his own explanations. My thoughts are below.
- Being a great problem solver.
- Being driven and lazy at the same time.
- Ability to understand other people’s code
- Having a passion for programming
- Loving learning for the sake of learning
- Being good at math
- Having good communications skills
- Strong debating skills
- Extreme optimism
- Extreme pessimism
Being a good problem solver? Of course! Great programmers are great problem solvers. Agreed!
Being driven and lazy. I keep telling my wife that being lazy is a good think. She doesn’t get it! But I agree that being lazy is a good quality to have in programming.
Ability to understand other people’s code. Somewhat agree. Is it just me, though, but I see a ton of code that I’m having very hard time following! I would say it differently: great programmers write code that others can understand; great programmers write code for humans to read.
If you don’t have a passion for programming… can you excel in any other profession if you don’t have passion!?
Everybody needs to learn and work hard to get better. That’s why great programmers go the less traveled road.
Being good at math? Debatable. I think there is a connection, but wouldn’t pay that much attention to it. But yeah, I was good in math.
All in all, a good post by Steve.
Uncle Bob in Clean Code states, “the Boy Scout Rule tells us we should leave the code cleaner than we found it.” Another words, when we make changes to the code base, we should make sure we are leaving it (checking in to repository) cleaner.
The original rule of the Boy Scouts states: “Leave the campground cleaner than you found it.”
This is very relevant to the way we code!
Following this rule is not easy. In some cases it might not even be possible (most likely not a good sign).
Why isn’t it easy?
When I code, I try to follow similar, but fundamentally different rule: don’t make the code base worse than you found it. Worse, not necessarily better. Following this rule is not easy either. It means I have to get a good understanding of the code before I make a change. It means I don’t try to put in a quick fix or a hack, add special exceptions (wouldn’t it be easy to just add a simple “if” statement).
It all starts with one broken window, as the theory of a broken window tells us.
The Boy Scout rule takes it a step forward. It requires you to not only understand the code, but improve it before you check your code in. Just the other day, I saw something that smelled. It had a lot of duplication. My task was to add something similar. Since code was already written, somewhat complicated, I went with the easy route. I followed the same route: I added more duplication! I didn’t necessarily make the code base worse, as it’s already been like that. But I didn’t make it better either.
I did not follow the Boy Scout rule.
If I did, I would have taken the time to refactor the code, generalize it, and make it reusable. I would have removed the duplication and made it easier to modify later on. Read: I would leave it better than I found it.
I’m already feeling resistance. I’m thinking about situations where it might not be possible to follow the Boy Scout rule.
Resistance is good. It means that I have some growing to do. It means that following this rule is…
Yes, it’s going to be a challenge. But the reward is there. Making improvements to the system you’re working on is a reward on its own. Talking about this in an interview should also get me extra points. But most of all, following the Boy Scout rule will make me work harder. It will make me a better programmer.
–The poeple who are best at programming are the people who realize how small their brains are. They are humble. The people who are worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.
in Code Complete
Do you agree with Steve?