At the university you learn a lot of stuff about computers but nothing about programming. That old saying is very true and stems from the fact that you don’t really have to know the absolute details if you got the concept all right. When you evaluate an approach, what counts are the relative numbers and not the absolute. Therefore if you fall of the academic wagon, or more appropriately for me, decide to hop off, you have some catching up to do.
The usual way to catch up to your more practical colleagues is the simple method of learning by doing. Because I’m the bookish type I’ve started to look at some of the classic „programming craft“ books that you find as recommendations in the intertubes . One of the books almost everybody can agree on is “Code Complete” by Steve McConnell.
The book’s cover is bad enough featuring a big Microsoft logo and a photo of a desk with microsoft keyboard and mouse (although that’s one thing they’ve done right) and a copy of the previous edition of the book. The book sadly does not indulge much more in the topic of recursion though (only pages 393 to 396).
Contentwise though the book is really great. Programming in praxis as the science of software engineering is mostly a fuzzy thing and McConnell goes to length to introduce to tool kit of techniques for programming. Sometimes he can also give you really good advice on which tool would be the best for a job and other times telling you there’s inconclusive evidence pro or against. For much of his advice he cites sources ( probably more stringent than zu Guttenberg ) although I thinks it’s funny if he write to look sth. up from another book that he has written; ah ok kinda like recursion again. But beware the book is for the professional programmer which means that he does not really talk about functional programming. It mostly about structured c++/java style programming and of course much of that translates also to structures programming like in c.
How to read this book; it’s definitely not a book that contains eye-openers on every page. Many things you already know or would just explain as common sense. For these parts it’s still nice for somebody to verbalize it so you can ingrain it better in your brain and be able to explain it to others. At other times it’s nice to have somebody give you rough ball-park estimates of what constitutes a good program ™, or which natural forces of software you should fight against (code bloat mostly).