The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Software Craftsman
by Sandro Mancuso
ISBN 0134052501
Date Read 1/2015
My Rating
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.
Reference
Great Programmers Write Debuggable Code
http://java.dzone.com/articles/great-programmers-write
Effective Programming: More Than Writing Code
by Jeff Atwood
ISBN B008HUMTO0
Date Read 9/2012
My Rating
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.
I’m currently deep into Python. Design patterns I learned earlier still apply. I learned JavaScript a while ago. Same thing.
I feel it’s not the languages we know count. It’s how we go about doing the tasks we have on hand. It’s how we craft software no matter what tools we use. Python is good for one thing; Java for other; and Javascript still for another, but we can apply “our learned way” to all of them.
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.
Not yet.
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?
Of course!
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…
A challenge!
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.
|
|
Steve McConnell
–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?
Effective Java (2nd Edition)
by Joshua Bloch
ISBN 0321356683
Date Read 1/2011
My Rating
I read the 1st edition (my recommended book) a few years back. I just re-read the 2nd edition. It’s one of the best Java books around (the other must read would be Java Concurrency in Practice).
Read it.
Re-read it.
The 2nd edition is a little harder to read. Some chapters are too long and are not as cohesive (not like they were in the 1st ed), but still, getting all these tips from a Java champion is very valuable. At the very least, you can use his tips to win your arguments and influence others on your team.
And that’s the reason I’m recommending this book: read it to become a better Java programmer. Isn’t that a good reason?
