The Best Programming Books on my Bookshelf. None are language specific.

I was one of the many people crying out for More Delphi Books, and I am glad to see that recently we have seen new books from Nick Hodges, and from others.  Today I'd like to cover the top five non-language-specific general books on programming that I think every developer should read.


1.  The Pragmatic Programmer - Andrew Hunt, David Thomas

This collection of snippets of advice is how I came to call myself a "Pragmatic" programmer.  I believe there are good principles in the "Agile" movement, but I hesitate to call myself "Agile".   I believe the practices in "Scrum" and "XP" can be done, and done well.  When I'm part of a team that takes those principles to heart and follows them, I'm happy to follow along too, when it works. But I don't take those monikers for myself, because I see "pragmatic" as the over-arching principle I follow. I do what works, and when it doesn't work, I change it up.  This book is chock full of fantastic advice. Some of the "get out there on the Internet and discover new stuff" sounds dated, as the last edition I have of this was updated around 2000, but the principles are timeless.   Incidentally my "change it up when it doesn't work" dictum is probably original to XP, and was borrowed by Scrum, and then by agile, so we're all cribbing from XP.  Nevertheless, of all the books I have read, there is no book that expresses more about how developers who do great work, and do it with reasonable efficiency work, in my opinion than this book.*



2. Clean Code - Robert C. Martin

Nobody, I mean nobody has written a book that cuts to the heart of modern professional Best Practices than Uncle Bob. Nobody.  Uncle Bob first hit my radar when he passionately and carefully expounded the principles of object oriented programming with the SOLID mnemonic. This book goes on to explain what it means to be a real software professional.  Yes, you have to unit test. But there's more.


3. Working Effectively with Legacy Code - Michael Feathers

How do I unit test that giant ball of mud that I can't rewrite?  This book answers that, and many other burning questions. I have not read any other book that gave me more hope that you can dig out of the holes of technical debt left for you to solve, than this book. Fine, now that you understand the benefits of cohesion and the single-responsibility-principle, the dangers of coupling, and the necessity of proving that your code works by writing code that proves the assertions you wish to believe about your code.  Now, how do you work with the code that you have right now, that does not now, and may not ever meet your ideals about Clean Code? This book can help.

4. The Mythical Man Month (and other essays) by Fred Brooks

No better book about the work that programmers do, the way we run software projects, and the sad blindness to historical lessons learned that seems to occur in our field, has ever been written than this book.   It contains a series of essays, each as good as the last.  Fred Brooks is my mentor, my hero, and my model of a software engineer, a craftsperson, a pragmatic programmer, a technical communicator, and an innovator in computing.   A must read.


5. The Secrets of Consulting by Gerald M Weinberg

This is a book about giving and receiving advice.  It is not pointed out nearly enough how much of a senior developer, or architect, or team leader's role consists in giving and receiving advice. Whether it is to someone who is your boss, or to someone you are being paid only temporarily (as in the title, Consulting), you are going to be better off if you read this book, and understand the lessons inside it.   This book tells you how to give your advice in a way that will be listened to.   If you want to be an effective technical communicator you must know how to deal with people, not just with machines. This book is a must-read for that reason.

What are your favorite programming books that don't cover any language, library, or specific tool, but rather cover the practice of being a programmer?

______

* I should point out that I haven't read Extreme Programming Explained, by Kent Beck, but I hear a lot of people say the same thing about the XP book. I did read the Agile Software Development With Scrum book, and was underwhelmed.    I do, however, agree with all the practices it mentions, but I feel that Agile often becomes, as Fred Brooks would call it, a "Silver Bullet", something we hope will save us.

Zombie Apocalypse Survival Toolkit Part 37: The Self Contained Software Environment

The following is an example of my weird sense of humor.  If you don't get it, or you aren't interested in Gedankenexperiment,  my regular Delphi-themed blog content will resume tomorrow. 

Imagine you knew three weeks, or three months ahead of time, that there was going to be a major Zombie Apocalypse, or something else that would basically take the internet offline for the rest of your (possibly short) life.  Imagine, furthermore, that after some months you are able to get your basic human needs taken care of, such as a place to live, clean air, clean water, food, plumbing, electricity, and get back to life at, say, a 1950s level.   You still have your computer, but it's disconnected from the internet, and it's unlikely that anything like the internet will re-emerge in  less than, say 20 years.  You wish to be a computer guy, but you now find that the world in which you might do some computing requires you to be a bit of a rugged individualist. 

Windows is a non-starter in my self-contained post-disaster scenario.   For example, one fine day, due to some glitch in Windows activation, all your Microsoft windows operating systems cease to boot.  You don't have the source code to Windows, and you can't fix it yourself.  You are now out of the computing business.   Fine, you say, the world's over, I don't care.  But wait, it's not over...


I sometimes think about this idea of having a "self contained programming environment".   It basically has the following attributes:

1.  I have the source code to the whole thing, from the metal upwards.

2.  I can boot it up to a command prompt (live CD or Usb stick) or a full graphical desktop, without any installation, on any PC-compatible.   I can also do an operating system install onto a new system, after such a boot-up, either using an automated installer, or by hand, if necessary.

3.  I can repair anything that goes wrong with it, because it's constructed according to rational principles, and because I'm a smart person.


So let's think about how you would build this.  I can think of a number of ways to build it.    I thought about Linux but most of the Linux distributions are not designed in a way that makes them easy to use in my post-apocalyptic world.  Debian and Ubuntu have apt-build for source code rebuilding, including an apt-build world capability.   Some Source-Based Linuxes out there are pretty powerful, but I find them hard to use, there's stuff like Arch Linux, and Gentoo.

Personally, I think FreeBSD,  and DragonFly BSD have a lot to recommend them for my "zombie apocalypse" deployment scenario.  These systems are uniquely suited to my Zombie Apocalypse scenario, because they are far simpler to deploy, modify, understand and thus, repair than any Linux system, and the "ports" tree for them is much smaller, and represents a natural curated set of "stuff you would want on a desert island".    Remember that when they break you can no longer google any error messages.  A simpler system, with fewer lines of code, that is functional, will be easier to maintain than one that is larger.    The BSD kernel for example is several orders of magnitude simpler to understand than the Linux kernel.   The BSD user space layout is much simpler than the Linux distribution's layout, closer to classical Unix systems practices, and has a certain Zen to it that you have to experience to understand.

If you had a large amount of disk space to reserve for a Debian Network Mirror, say one terabyte,
and you could figure out how to keep it all working, and free of bit-rot, you could probably keep a Debian system going on your local area network.    By comparison, a complete mirror of FreeBSD or DragonFly BSD, because it contains a lot less software, would be much smaller and more portable.  It contains a lot higher percentage of the stuff you might wish you had (compilers, and such) and a lot less of the end-user stuff.  So, if you wanted to say, have a reasonable set of open source games, then I would go with Linux,  but if you wanted a more general purpose Hacking system, in the classic and noble Unix meaning of the term Hacker, not a cracker, but a wizard of software, then I would go with the BSD variants.

That zen of BSD thing makes it fun to plan with. For example, FreeBSD, and DragonFly BSD have this cool thing called the "ports tree", which is basically the ancient Unix Hacker way of getting software onto a Unix system.  Originally they used CVS (that ancient version control tool), but FreeBSD has switched to Subversion, and DragonFly BSD has switched to Git.    Because of Git's DVCS capabilities, I think it's ideal for a self-replicating deploy scenario that I think we would need while rebuilding after the zombie apocalypse.

Anyways, if the recent ice storm has you thinking about being a Survivalist, and your weird mind also wanders towards "Software Survivalism", check out Dragonfly BSD.   One USB portable drive of about 1 TB in size, and you've got a pretty amazing "self contained software survival kit" for PC compatible hardware.   Batteries included.  And source code too.  

Now if you'll excuse me, I'm off to plan a bit more about the water, the food, and the electricity parts of my survival plan.  Those might be a bit harder to figure out than the software side of my plans.
Also, I think I need a USB Geiger Counter, in case of Radioactive Zombie Apocalypse.