The Pragmatic Programmer: From Journeyman to Master
I finally finished reading the Pragmatic Programmer last night before going to bed. It's a good book. I didn't know what it was about before reading it and was a bit surprised at the content; it was more of a "best practices" for programming as a methodical job rather than a how-to of programming tips and tricks. I am used to reading more how-to type books such as those about design patterns and general reference books (who says reference books are not meant to be read cover to cover???), so this was actually a really nice change of pace and a much faster read (despite the fact that I read insanely slow). It talks about debugging, source control, working in teams, effective development environments, writing dynamic code, not letting bad code persist, and basically about being a good programmer in general. A lot of the stuff is "common sense" type stuff, but a lot of it is stuff that you probably never formalized before. I would recommend it to any one who wants a swift kick-in-the-ass reminder that there are better ways of developing applications.
Note: None of it is ColdFusion specific. In fact, most of it is language agnostic. The teachings of this book can be applied to most any language, and in fact, much of it can be considered life-lessons, not just those meant for programming. Happy reading!
Reader Comments
My good friend Zach let me borrow his copy. I read it 3 times in a week just to make sure it sunk in.
You are right to distinguish this from the many How-To manuals out there. The lessons are applicable cross-domain and I am much better for having read it. Thanks for posting this and a big thanks to Zach for turning me on to The Pragmatic Programmer
dw
Yeah, this is a MUST read as the little tips and tricks just make you a better programmer all round. I suggest skimming it every few months as there is usually a good reminder of something - whether it is "no broken windows" or their stuff on writing generators.
Dan,
Three times in one week :) Nicely done.
One thing that I had a question about was that towards the end it stated that Hungarian type naming (where the data type is part of the name, ex. intNumber, arrValues) is hugely inappropriate of object oriented programming. I have heard Sean Corfield talk briefly about this and how it couples the code to its implementation... I was wondering if you could shed any more light on this.
As a naming convention, my stand-alone values use this naming convention (ex. intItemIndex, arrLines) but my scoped values do not (ex. REQUEST.ItemIndex, REQUEST.Lines).
Just trying to figure out the "best" mentality. Thanks.
Yeah, "No Broken Windows" is a great section! I find myself being very guilty of that, especially when I jump on someone else's application that has less-than-pretty code.
Hi Ben,
Reason to dump Hungarian (intItemIndex), notation is that it somewhat breaks encapsulation as should you wish to change the data type of the property you have to change the name everywhere. I know that much of the code working with it might also have to be changed, but it is one extra thing to mess with. The argument in Java is also that you already know the type (compiler helps with this) so you're duplicating the info.
Yeah, I gotcha (regarding the one extra thing to change)... but it almost seems like not enough of an argument. Along the same lines, couldn't you also say that you should never scope a variable (so long as ColdFusion will find it in the scope-chain) because you might want to switch from the URL to FORM to some manually defined Attributes scope?
Of course, I am not arguing with you, I know you were just explaining the rationale. But, in my opinion, the self-documenting nature of the variable name seems like a nice trade off to the slightly increased coupling.
Anyway, not sold in either direction.
Yeah, I'm not completely sold either, but as smarter people than me have a preference and I don't, I'll go with the crowd on this one (although some smart people love Hungarian - so I'm sure there is a healthy dose of preference in the choice).
As for scope, funnily enough, I NEVER reference URL or form scope directly - always use an IBO as an attribute facade containing both that even does nifty things like returning null or 0 based on data type if attribute doesn't exist and RegExing all form and URL attributes to make sure they are well formed for their data type. Saves a bunch of tedious coding!
Yeah, I tend to go with a unionned FORM/URL to REQUEST.Attributes object most of the time. I have not made the leap to IBO yet, but I have played around with it a bit.
As far as "smart people" go, I'm sure a lot of "smart" people would tell you not to eat buffalo wings that were left out on the table over the weekend... but I have proved that one wrong on many Monday mornings :) So the question becomes, is that not smart... or is that simply revolutionary ;)
Although, speaking of unnecessary coupling, one of the things that I did really like in the Pragmatic Programmer was the suggestion to never put the file name in the file comments (as it couples to the physical file name). If you ever look at any of the code that I write, you will see that all files have a header comment that includes the file name. I can now stop doing that and feel at ease that it is the "right" thing to do. It was always something that I did because I thought it was correct and not because I felt that it was necessary.
That is one of the best aspects of the book; I feel that it helps to distinguish a number of things that ARE right vs. I THOUGHT they were right.
Hmmm, in that case either revolutionary or simply gifted with a GI system with a resilience previously unknown to medical science :->
Yeah. I have file names in all my old script comments too. Always nice to learn what you've been doing wrong all these years!
If anybody is interested in concept programming books, I hear "Code Complete" is quite a good book.
So good that I bought it and now it collects dust on my bookshelf, he he. Of course that is typical for me since I hardly ever read any of the tech books I buy.
Yeah, I have heard good things about Code Complete, but cannot vouch for it personally. I will check it out on Amazon. Thanks.
I read it the other month. It starts off very good and then settles down to merely valuable. I would definitely recommend it. It is very thorough but it isn't as "fun" as a lot of the newer, shorter books which is why it is easy for it to end up on a bookshelf unread. The book is well written, but it isn't as tight as something like PP. Still, it is on most programmers "essential reading" list, so it is worth picking up a copy - even if you just skim it.
I'll see if I can find a used copy somewhere. Never know where the good deals are to be had.
If you're stuck, let me know. I'm flying out Saturday, but will be back late Jan and have a copy I'm not planning to read again for a while . . .
Joel on Software has an interesting article on Hungarian notation.
http://www.joelonsoftware.com/articles/Wrong.html
Some history, and some good use cases where the notation is used with different "types" that aren't necessarily datatypes like int.
Interesting article. I'd argue that this is a bit of a hack to solve an architectural problem, however. In this particular use case you can architect your business objects to have an HTML aware view decorator that takes care of all of this automatically. That said, I'm always open to cases where Hungarian notation works - I just think in this case it is a syntactic hack for something that should have been solved at an architectural level.
Very cool link though, thanks!
Nice review. I plan on buying this book but after reading your comments I may just opt for a used copy from Amazon.
Thanks,
-Duj