As a developer, there are days when you pat yourself on the back for the cool, innovative code you wrote, and smile at how clever you are.
Then there are times when you wonder how you can walk and chew gum at the same time. I had one of those “Duh!” moments yesterday.
I am working on a project for our admissions office. They used to get boxes and boxes of paper Advanced Placement(AP) test scores from high school students who are considering applying to Temple. AP tests are exams that high school students can take, usually in a subject they excel in, such as math, history or biology, and if they score high enough on the exam, they can obtain college credit for a course they normally would have had to take.It can shave 3 or more credits off of their academic program of study once in college.
The admissions staff were known to have manually entered over 2,000 scores during any one admissions cycle. As of this past summer, those test scores are now arriving electronically and loading into Banner – our student information system. However, there is a third party system we are using to evaluate those test scores and how the AP credit can be applied towards Temple programs. That system is where the admissions staff used to key in the test scores, and that is my part of what is now a two-step automated process- I have to take the scores out of Banner, and massage the data and get it into the third party solution, where the actual evaluation of AP credit to Temple credit occurs.
My team and I have made good progress so far and I was testing my part yesterday. The university has dozens of types of tests that come in for students such as entrance exams (SATs, ACTs, MCATS, LSATS, etc) and placement tests. The AP scores are designated in such a manner that the first two characters of the test code are “AP”. So for example, “AP20” is a biology test, “AP25” Chemistry, etc.
In my querying of the database, I was grabbing all AP tests that had been added to students’ records , with a score of at least three, and that had no “DR” code in another column. However, in my result set I was getting tests that did not start with AP. Where were those EETK, MP1, MP2, MP3, EESS scores coming from ?
After scratching my head a bit and a few expletives mumbled under my breath, the “Ah ha” moment arrived. Lines 7 and 8. The lack of properly placed parens (parenthesis) with the ANDs and OR was doing me in. Once I got them right, my result set looked much better.
Moral of the story – you can never be too careful, even when you “think” you have this SQL thing nailed down. Take the time to check yourself!
One day in the Twitterverse, a young colleague, Justin Biard, posted a quote regarding professional’s abhorrence to “messes”. That really resonated with me. As one who has frequently had to “put out fires” and had to clean up bad data caused by others’ (and sometimes her own) erroneous code, nothing instills more fear and frustration than those four little words: “We have a problem”. I fear job aborts, Oracle ORA- errors, endless loops… the list goes on and on. Just writing the words gives me a pit in my stomach.
I asked Justin what the source of the quote was from and he told me about a book he was reading called The Clean Coder. We chatted a bit more about the gist of the book, and if he thought it was a good read, and then inquired as to whether he’d consider posting a review of the book here, as a guest blogger. He happily agreed! So without further ado, I give you Justin Biard:
Reading The Clean Coder
Do you have forty-plus years of experience in technology or programming and consider yourself to be a professional? Do you have a pretty good sense of what it means to be a professional programmer? Do you actively mentor and share that knowledge with others around you? Yes, or no, I’m humbled that you would take the time to stop by and read these words. Thank you.
What are we doing here and why is Helen letting this guy ramble on her blog?
As someone who loves learning how technology works, I *could* be called a nerd, a geek, a techy, or maybe just… a slightly introverted person with Internet access and a penchant for computers. Whatever you call it, I love what I do. I also hang out with other people who love what they do. And because everything sounds better with an “Ugh” at the end, we form a group and call it ODTUG (pronounced Oh Dee Tug). This is not a shameless plug for the user group, this is how Helen and I were introduced, through a fellow “nerd”. (We are looking at you Chet @oraclenerd)
” …you will drive the system into a swamp from which it may never escape. Professionals fear messes far more than they fear blind alleys.”
This got Helen and I talking about the book and mentorship. Helen asked if I’d be willing to share my thoughts on the book. So here we are.
Note: On the topic of mentorship, Helen started a great series here on her blog. (Stop reading this post, read her posts if you haven’t yet, and then come back here to finish up!)
Is this book about programmers with good personal hygiene?
No (well… maybe?) This book is about professional hygiene. Its about the mindset, the habits and attitudes that a programmer should pursue to achieve professionalism. It is also full of what seem to be pragmatic opinions, grounded in truth.
If you are a professional programmer or mentor of programmers already then you should expect to read this book for enjoyment, rather than education.
Is this book a technical reference with lots of code samples and recipes for solutions?
No, this book is definitely not a technical reference. It does not contain many, if any, code samples. However, it is an insightful look into the history and thought process of someone with over four decades of experience making mistakes as a developer and learning from them.
I work in (or with) IT, maybe even manage a team of developers, but my career is not focused on full-time programming, will I get any value from reading this book?
It depends. To tell you the value of reading a book without first understanding your own needs could be like trying to give fish to a fisherman or it could be like giving delicious bread to the famished. Are you the fisherman (professional programmer or mentor) or the famished (early career developer) possibly starving for mentorship?
Assuming we care about your opinion……. What did you think about this book?
Of my own opinion… Personally, I really enjoyed the book. It is well written. Martin uses plain English and tells plenty of interesting stories. For me, it was a lot like watching an old friend or mentor teach a class of up and coming developers and getting to take notes on technique and style.
On mentorship, I would use this book as a conversation starter to help define professionalism as a programmer and to understand the development philosophy of a team. Martin touches on a wide range of topics including things like:
* When to say “No” and how to say “Yes”
* Various levels of testing
* Time management
I am not a full-time “programmer” (in the traditional sense) and I don’t need to agree with all of Martin’s choices or tool selections, but even then, the spirit of his advice was still relevant. The breadth of topics he covers is a thoughtful roadmap to professionalism as a programmer. Don’t buy this book because I thought it was good. Research it for yourself. Read some reviews on Amazon (or wherever you buy books). Ask around and get other opinions.
Whether or not anyone else reads the book, I hope you all aspire to be (or to continue being) professionals and that you love what you do.
Thank you Helen, for the opportunity to share my thoughts with your readers.
Follow Justin on Twitter @icodealot