The Pragmatic Craftsman
:: Simplicity from complexity ::
The Pragmatic Craftsman
:: Simplicity from complexity ::
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
Design Patterns Explained
by Alan Shalloway and James R. Trott
ISBN 0321247140
Date Read 8/2009
My Rating
Excellent intro to Design Patterns. I really liked the authors’ focus on teaching not only design patterns but how they should be used and implemented. Really good job there. I think this is a great book to start learning design patterns. If you want to learn DP, start with this book before you dive into the GoF Design Patterns book. Much to learn from this book, with a slow, more thorough way.
Not really a reference book. I tried to read this one quickly so I can get a quick refresher. This book is not suitable for that. Long explanations, not that much source code for examples. Yes, the explanations are good, but not if you want to quickly scan and refresh your memory. For that reason, I think the classic GoF book is still the king.
Overall, I appreciate the authors focus on teaching the right way of programming; trying to instill the “correct” thinking about patterns; and the detailed explanations of the different design patterns. I am disappointed that only a subset of patterns were explained and that this book is not suitable for reference. But all in all, a decent book.
Software Architecture Design Patterns in Java
by Partha Kuchana
ISBN 0849321425
Date Read 7/2009
My Rating
Good concept, bad implementation. After reading a few books on Design Patterns, I wanted to check out something else. Title of this book and decent reviews drew me in. I’m disappointed. After reading 20 chapters, I’m going to stop. I just don’t feel the author is doing a good job. There is not enough explanation on the different design patterns. The author gives a quick overview and then gives you an example. There is nothing wrong with that. But it’s very light. Each pattern is not explained enough. No benefits/drawbacks. No counter examples. Nothing really that will make the pattern “stick.” I just can’t learn anything from this book.
If you’re looking for a GoF book in Java, I would check out Design Patterns in Java or Design Patterns Explained. Not great, but I think they do a better job of explaining each pattern.
I have to admit, my regex skills are not that sharp. I read a book on Regular Expressions before, but still, regex expressions just don’t stick in my mind. Too cryptic.
Can you read the following?
/^[a-z0-9_-]{3,16}$/
The following explanation might help.
DescriptionWe begin by telling the parser to find the beginning of the string (^), followed by any lowercase letter (a-z), number (0-9), an underscore, or a hyphen. Next, {3,16} makes sure that are at least 3 of those characters, but no more than 16. Finally, we want the end of the string ($).
String that matches: my-us3r_n4m3String that doesn’t match: wayt00_l0ngt0beausername (too long)
Clear, right? I love the description. It makes sense! This is an excerpt from an article 8 Regular Expressions You Should Know.
This one is a bit more complicated.
/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
DescriptionWe begin by telling the parser to find the beginning of the string (^). Inside the first group, we match one or more lowercase letters, numbers, underscores, dots, or hyphens. I have escaped the dot because a non-escaped dot means any character. Directly after that, there must be an at sign. Next is the domain name which must be: one or more lowercase letters, numbers, underscores, dots, or hyphens. Then another (escaped) dot, with the extension being two to six letters or dots. I have 2 to 6 because of the country specific TLD’s (.ny.us or .co.uk). Finally, we want the end of the string ($).
String that matches: john@doe.comString that doesn’t match: john@doe.something (TLD is too long)
Reference8 Regular Expressions You Should Know, nettuts (very good resource, btw)
