A friend of mine recently asked me if I had a list of books I would recommend. A key part of his criteria was: “What books you have read to let you work in peace in SpringSource?”

I have been giving this question some serious thought. It’s a challenging prospect: identify a recommended set of books that helped you build your skill set. The person with the question listed a few books he assumed I would consider valuable:

• Effective Java (2nd edition)
• Head First Design Patterns
• Practical API Designs

I had to tell him that I haven’t actually read any of these, but I’ve heard others speak good words about them.

Well, I have managed to put together a list, but I’m not sure exactly how effective it is today. But there might be equivalents. First of all, for the record, I haven’t read the ones you listed up above, though they might be of incredible value to others.

1. Mastering SunOS

Auburn University had SunOS workstations in all the engineering labs. A colleague of my dad (both engineering professors) highly recommened I get this book. Since I had the jump start and had already learned C programming in high school, I was able to focus on learning UNIX with this book. While my fellow computer engineering students were learning C, I was learning SunOS (predecessor to Solaris). I cannot stress how valuable a skill UNIX is to any developer. I have hired many people to work directly for me throughout my career, and those that already knew UNIX were much easier to ramp up to full duty. Those that had learned programming on Windows had an inherent delay. We used Windows desktop computers for development, but our production servers were Solaris. I currently use a Mac, which is based on the OpenBSD kernel, a cousin to UNIX.

Heck I know people stuck with a Windows-based computer at their job that install Cygwin to give them some leg up.

I think I also had some variant of “A C/UNIX Programmer’s Guide” but I’m not 100% certain on this title.

2. Design Patterns by the Gang of Four

This book is commonly known as the “Gang of Four” book, referencing the four authors who are considered experts at software architecture. Whereas it’s a valuable book, the lesson I learned was rather strange. You see, as soon as I read it and embraced it, I tried to use every pattern I could in my next app. The app turned out over designed and downright unmanageable.

This is when I started learning that sometimes less is more. The simpler something could be, the better. Over time, I have learned that it isn’t “sometimes” but “most of the time” simpler is better. Of course the patterns are solid, but what’s hard to capture in the book is when it’s best to use a given pattern. They tried in the book, but I couldn’t see that subtle aspect. I was too caught up in the marvel of a given pattern.

3. Spring: A Developer’s Notebook

This nice little book introduced me to the magic of Spring. It was thin and easy to read over the weekend. But it was riddled with errors in the code. Today, I would suggest someone not familar with Spring pick up Just Spring if you want a quick intro.

4. Professional Java Development with Spring

This is a solid book. It introduces all the core pieces you need to really use Spring in a real world application. It’s more detailed than Just Spring, but after getting warmed up, it’s a go to. Pay it mind, it’s a bit dated, written against Spring 2.5 (of which Spring 4.0.M3 is currently out right now).

5. Exploring Expect / Practical Programming in Tcl & Tk

My career has always a had a pseudo-devops style. I would often build apps and then have to create tools to further support them. There is nothing like Expect out there. It lets you automate other command line tools. Of course, you must learn Tcl to do that, but given it’s power, I often used it to overcome shortcomings in other command line tools. Combined with cron (thanks Mastering SunOS), I easily built tools that could detect server issues, sometimes fix them, and either page me or send me a morning report.

6. A SQL book specific to your database

I happened to have an Oracle SQL book that included all the details of how to write SQL. For starters, SQL isn’t rocket science. But some of the more complex concepts don’t sink in until you need to write a certain type of query. The last mission critical app I managed had over 200 SQL queries. I looked up stuff all the time in that book. And I also learned the gaps between ANSI SQL and Oracle SQL. When I hired one person, I told him to buy a SQL book, and he got an ANSI-only one. It was next to useless because it wasn’t detailed enough to our platform.

7. Compilers: Principles, Techniques, and Tools
This is commonly referred to as “The Dragon Book” because it’s cover had a dragon and a knight on the cover. This book introduces you to the core concepts needed to build your own compiler. I had a college course “Compiler Construction” that used this as a text book. If there was one class in college that was rough, this was it (though “Theory of Formal Languages” was no picnic). Each week we had to add to our compiler. Didn’t keep up, you were sunk. I had to drop it quickly and then re-take it again because it was required material.

By the time I got to grad school, they made it optional in that you could take one other alternative. That kind of saddened me. Nonetheless, the first class I had to run a lab for in grad school was this one. It was sort of a double whammy. Only this time, I couldn’t drop it. I spent extra hours at night getting back up-to-speed on this subject.

Bottom line: If you can get your head around lexers, grammar parsers, symbol tables, and abstract syntax trees, there are many other hacking concepts that will come easily to you. This isn’t exactly stuff you use on a daily basis, but it forms a strong foundational concept you might need. I once coded a parser for a proprietary language using Python Lex Yacc (PLY) so I could transpile parts of the app into Java and migrate to something more sustainable. My manager didn’t buy my solution, but nonetheless, the “Dragon Book” made this an opportunity.

What about UI? 

Frankly, my career was never angled towards user interfaces. I had a systems engineer that was trained in all kinds of user interface do’s & don’ts. There is an entire field of research in this arena. I actually found it boring. Instead, I would ask her to lay out visual displays and basically implement what she showed me.

But you might be different. You might be more like Joe Nuxoll, past member of the Java Posse. He is all about user interfaces, which explains his incredibly love for Apple devices and general dislike of Android ones. That’s not me. But it summarily means there is an entire universe of UI oriented books out there I just can’t suggest. It’s not my forte.

What books can’t cover
There is an underlying message to understand. Books can’t teach you everything. Instead, they can provides, tips, tricks, and introduce you to material. But there is NO substitute for being put in the crucible of build a 24x7x365 mission critical app. I was the lead developer of an Ops center application like that for ten years.

The Ops center managed 8000 sites across the country, monitoring over 300,000 devices and 25,000 telecom services. When we started we had 26 sites, and grew fast. Some things we built at one stage didn’t work three months later. So we had to rewrite our solutions to scale. And then that wouldn’t work a year later. But we had a strict schedule such that nothing was allowed to delay the schedule. We dropped nice-to-have features if we couldn’t do it in time.

I came in many times late at night to deal with outages. Once I came in three times in the same night. Whew! There was also a situation where the servers were crashing every few hours. When the Ops team asked if we had something…anything to release, and we had to tell them “no…but we will in 48 hours.” We had rushed an untested patch in the past under similar duress, and learned a bitter lesson.

In that type of high pressure environment you will try everything you can think of. You learn the cost of making risky choices. I sure did. And I feel that that Ops center work taught more than anything I ever knew. So don’t pin too much hope on books, but instead seek opportunities to put your skills to the test. And be ready for mistakes. They are the greatest teachers of all.