Monthly Archives: February 2014

A little less JavaScript, a little more Java please …

OK I’m not actually saying I like Java more than JavaScript, I just thought it would be a catchy title to talk about task switching and to recommend a book that was recently recommended to me.

So at work I’ve been doing some task switching from working on an internal JavaScript project to a maintenance task for an external Java product. Usually I find task switching more of a disruption but for some reason this time I welcomed the change of pace and mental scenery if you will.

Interestingly enough while working in Java again after some time and a product that I haven’t worked with in well over a year, I also received a book recommendation during a great conversation. The particulars of that conversation, I will hold off on for another post perhaps. The book recommendation was Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.

Until this book I’d have to say that one of the best books on Java development I’ve read would be Effective Java by Joshua Bloch. Clean Code discusses many concepts about what makes clean code, if you didn’t gather that from the title. Some of these concepts are things that I felt intuitively or have gathered from other resources but this book describes in some detail what it is that makes clean code, from formatting, to coding standards, to code structure, and beyond. The author has a great writing style that’s very conversational and makes it an easy read. I don’t think I can recommend this book more.

I am also simultaneously reading another book by the same author, The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin. This book is shorter and less technical that Clean Code. In it the author talks about his career as a software developer, the mistakes he’s made, the successes he’s had and what behaviors or habits constitute a professional software developer. This book also discusses topics that I have felt intuitively but goes even further.

One of the concepts that I really relate to from this book is the idea that as professional software developers, we have the responsibility to stay current in our field, and to regularly practice continuing education in some form. For me I try to read on topics of software development as often as I can. The author makes a comparison that software developers, like any other professional, say a doctor or lawyer, have a responsibility to stay current on best practices, methodologies, and new technology. Here is one of my favorite quotes from the book.

Would you visit a doctor who did not keep current with medical journals? Would you hire a tax lawyer who didn’t keep current with the tax laws or precedents? Why should employers hire developers who don’t keep current?

So with that, I hope others find these books as inspirational and helpful as I have. I think that others who share a passion for software development and really care about improving their craft will enjoy these two books.

Cheers,
Tim