66 Books Like Refactoring Databases

When I work with students new to programming I often find they struggle with translating the toy problems in exercises to actually doing something in the real world.

I love this book and frequently recommend it to new programmers because it is centered around problems. Coding should be about making your life easier. At the beginning, the problems are small, but by the end, you’re learning about email, PDFs, and GUIs.

Sweigart has a great voice, and reading this feels like being guided by a friend rather than yet another coding textbook.

I have to be honest here: when I was reading this book on a trip to New York, I found myself quite surprised because I had seen so many praises for this book, yet I did not particularly agree with most of the topics I was reading about. In particular, I found several points that contradicted those in Clean Code and Code Complete.

I know there’s a debate going on between the authors on a distribution list, but besides some of these points on which I respectfully disagree with the author, I can see is a book of immense value, and there are tons of other great points made about great software design (for example, ”modules should be deep”). And the explanations are crystal clear.

A final reason for recommending this book is that it’s always enriching to expose oneself to a different viewpoint.

Most of the code I write and use is open source. As a programmer, it is easy to think “open source means free.” I didn’t think much about it until one of the companies I worked at got acquired, and we had to audit our licenses.

The big company that bought us was very particular about which licenses were compatible with their needs. That was when I realized I needed to understand this stuff better. Rosen does a great job of teaching what is otherwise legalese in plain-spoken, easy-to-understand language. This book taught me why I choose the licenses I do rather than picking blindly.

Next to Fred Brooks' The Mythical Man-Month, this is perhaps the most classic of all classic programming books.

The authors write: "Besides showing how to make effective use of the language, we have also tried where possible to illustrate useful algorithms and principles of good style and sound design."

The book is astoundingly practical as a tutorial, which is itself a testament to the Unix "pipe" model of programming: By page 13, they've introduced getchar and putchar, and by the end of Chapter 1, twenty pages later, you've implemented a host of useful utilities including cat, wc, and detab. In Chapter 5 you implement a function recognizable as the now-standard qsort; in Chapter 8 you implement malloc itself.

Now, I recommend "K&R1," not the more popular "K&R2." The first edition was issued in 1978 at a slim 225 pages; the second edition, a decade later, added conformance with ANSI… show more.

During the early years of my career as a software developer, I regularly developed very small programs that would exercise parts of the system that I was working on back then. I realized very quickly that those small programs would save me a lot of time figuring out whether the changes that I made would actually work or not. Until at some point a colleague mentioned the concept of Test-Driven Development. I first did some experimentation, dipping a toe into the water to feel the temperature. It wasn’t until the first time I picked up this book that I jumped right in. From then moment on, it all made sense. Although this book was published back in 2002, for me it still is the book when it comes to the subject of Test-Driven Development.      

One way to craft lessons learned is in the form of recommended best practices (or, as I prefer, “good practices”). Best practices represent collected and distilled wisdom from many observers, many projects, and many years of experience. Rapid Development includes 27 best practices for software development, with one chapter devoted to each. Although the book was published more than 25 years ago, most of these are still relevant. Indeed, several of them have been incorporated into routine contemporary practices: evolutionary delivery, designing for change, timebox development, and requirements scrubbing. Techniques such as inspections, miniature milestones, principled negotiation, and reuse are perennially pertinent.

I've found this book enlightening in many key areas of software development, and as I was reading it, I felt connected with the author (even though I've never met him, I could imagine us having a conversation about software engineering, and agreeing on pretty much everything).

It was a revealing book for me, in the sense that it gave a formal framework to several ideas I've noticed as a practitioner over the years. In that regard, I wish I'd come across this work way earlier in my career.

Many agile projects employ user stories as a way to represent requirements rather than a more traditional approach combining use cases and functional requirements. I favor the latter approach for several reasons. Nonetheless, user stories are well established in the agile development world, and if you wish to learn about them, there’s no better author to read than Mike Cohn. Cohn describes how to craft user stories well and how they fit into the agile development process.

Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. The descriptions of each principle are concise, whereas my 60 lessons in Software Development Pearls go into a great deal more detail and offer many practical techniques.

There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.

In addition to Java, you need to know about the Java ecosystem.

Each chapter covers a type of tool like version control, securing binaries, or mobile. Some chapters cover a variety of tools. I particularly liked the overview of Quarkus and Micronaut. I also liked the emphasis of tools vs a role. The analogies were great such as comparing identify/fix/deploy to an oil spill.

The book is 300 pages and easy to carry around. Despite having four authors, the book is very cohesive and reads well.