Here are 99 books that 201 Principles of Software Development fans have personally recommended if you like
201 Principles of Software Development.
Book DNA is a community of 13,000+ authors and super readers sharing their favorite books with the world.
I’ve spent most of my life writing code—and too much of that life teaching new programmers how to write code like a professional. If it’s true that you only truly understand something after teaching it to someone else, then at this point I must really understand programming! Unfortunately, that understanding has not led to an endless stream of bug-free code, but it has led to some informed opinions on programming and books about programming.
A thoroughly fascinating (and fascinatingly thorough) look at engineering practices at Google.
It’s an encyclopedia written by a bunch of authors, so some of the chapters are a little dry, but for those of us who aren’t on teams with 25,000 engineers it’s spell-binding to see what programming at that sort of scale looks like. Some of the chapters prompted us to think really hard about the way we do things at Sucker Punch.
Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their codebase sustainable and healthy. This book emphasizes this difference between programming and software engineering.
How can software engineers manage a living codebase that evolves and responds to changing requirements and demands over the length of its life? Based on their experience at Google, software engineers Titus Winters and Hyrum Wright, along with technical writer Tom Manshreck, present a candid and insightful look at how some of the world's leading practitioners construct and maintain software. This book covers…
Magical realism meets the magic of Christmas in this mix of Jewish, New Testament, and Santa stories–all reenacted in an urban psychiatric hospital!
On locked ward 5C4, Josh, a patient with many similarities to Jesus, is hospitalized concurrently with Nick, a patient with many similarities to Santa. The two argue…
I first learned to program in college in 1970. Since then I’ve spent much time as a software developer, manager, tester, process improvement leader, consultant, trainer, author, and, of course, a user. I quickly learned that I didn’t have time to make all the mistakes that every software developer before me had already made. My training and writing career has involved sharing what I and others have learned with audiences to help them quickly become more effective software development team members, regardless of their project role. This book distills insights and observations both from my own experience and from what I’ve heard from thousands of students and consulting clients.
Robert Glass is one of the foundational leaders of the discipline of software engineering. He’s done it all and seen it all. This book includes 55 facts and 10 fallacies about many aspects of software engineering, grouped into the major categories of management, the life cycle, and quality. Based on my own experience, I can vouch for the validity of all the points Glass makes.
These timeless truths can help you avoid going down an ineffective path, wasting time only to rediscover the same facts on your own. There’s no need to retrace the missteps from the past. Books like this can keep your energies focused where they will provide the most value to your customers.
The practice of building software is a "new kid on the block" technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative "newbies."
In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about.
There's a problem with those facts-and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but…
I first learned to program in college in 1970. Since then I’ve spent much time as a software developer, manager, tester, process improvement leader, consultant, trainer, author, and, of course, a user. I quickly learned that I didn’t have time to make all the mistakes that every software developer before me had already made. My training and writing career has involved sharing what I and others have learned with audiences to help them quickly become more effective software development team members, regardless of their project role. This book distills insights and observations both from my own experience and from what I’ve heard from thousands of students and consulting clients.
Most books about lessons learned and good practices tell you what you ought to be doing. AntiPatterns warns you about things you should not be doing. It points out a wide range of software project approaches that the authors believe are not advisable. The antipatterns have whimsical titles such as Poltergeists, Golden Hammer, Spaghetti Code, Stovepipe System, and Design by Committee. Each pattern describes the symptoms, causes, and consequences of that particular behavior, as well as offering a restructured approach that’s likely to yield better results. As with other lessons-learned books, this book lets you learn from the pain suffered by others to avoid stepping into the same traps on your own projects.
"The AntiPatterns authors have clearly been there and done that when it comes to managing software development efforts. I resonated with one insight after another, having witnessed too many wayward projects myself. The experience in this book is palpable." -John Vlissides, IBM Research "This book allows managers, architects, and developers to learn from the painful mistakes of others. The high-level AntiPatterns on software architecture are a particularly valuable contribution to software engineering. Highly recommended!" -Kyle Brown Author of The Design Patterns Smalltalk Companion "AntiPatterns continues the trend started in Design Patterns. The authors have discovered and named common problem situations…
A poisonous maiden, a Daoist sex cult, and a violent insurgency.
The polyandrous Yan family in China's rural Shaanxi Province takes in two carpenter brothers. When one brother is convicted of murder after killing their neighbor in a dispute, a constable threatens to expose the family's rumored polyandry and extorts…
I first learned to program in college in 1970. Since then I’ve spent much time as a software developer, manager, tester, process improvement leader, consultant, trainer, author, and, of course, a user. I quickly learned that I didn’t have time to make all the mistakes that every software developer before me had already made. My training and writing career has involved sharing what I and others have learned with audiences to help them quickly become more effective software development team members, regardless of their project role. This book distills insights and observations both from my own experience and from what I’ve heard from thousands of students and consulting clients.
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.
Corporate and commercial software-development teams all want solutions for one important problem-how to get their high-pressure development schedules under control. In RAPID DEVELOPMENT, author Steve McConnell addresses that concern head-on with overall strategies, specific best practices, and valuable tips that help shrink and control development schedules and keep projects moving. Inside, you'll find:
A rapid-development strategy that can be applied to any project and the best practices to make that strategy work Candid discussions of great and not-so-great rapid-development practices-estimation, prototyping, forced overtime, motivation, teamwork, rapid-development languages, risk management, and many others A list of classic mistakes…
I’m a software engineer because I’m a builder at heart. I have always had a profoundly curious mind, and always enjoyed tinkering. So at one point in my life, it became evident that I was going to be an engineer. I consider teaching the final step of learning, so whether this means writing an article or giving a talk, or simply sharing recommendations, I make a final effort to share with the community of like-minded people what I have learnt. For this reason, I hope you enjoy reading my book and the ones I recommended.
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.
Widely considered one of the best practical guides to programming, Steve McConnell's original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices-and hundreds of new code samples-illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking-and help you build…
I’m a software engineer because I’m a builder at heart. I have always had a profoundly curious mind, and always enjoyed tinkering. So at one point in my life, it became evident that I was going to be an engineer. I consider teaching the final step of learning, so whether this means writing an article or giving a talk, or simply sharing recommendations, I make a final effort to share with the community of like-minded people what I have learnt. For this reason, I hope you enjoy reading my book and the ones I recommended.
I've found this book to be instrumental in my career as a software engineer, especially because it's full of useful and practical advice on how to be effective and productive on a day-to-day basis, but it also includes actionable advice, and helped me a lot on thinking about my career long-term.
Straight from the programming trenches, The Pragmatic Programmer cuts through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users. It covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse. Read this book, and you'll learn how to
Fight software rot; Avoid the trap of duplicating knowledge; Write flexible, dynamic, and adaptable code; Avoid programming by coincidence; Bullet-proof your code with contracts, assertions, and exceptions; Capture real requirements; Test ruthlessly…
Big Ideas... For Small Businesses
by
John Lamerton,
Big Ideas… for Small Businesses is a straight-talking, no-nonsense guide to growing a small business without sacrificing your lifestyle. Written by a former civil servant turned entrepreneur, the book challenges hustle culture and instead champions the idea of an "ambitious lifestyle business" - one that provides freedom and financial stability,…
I’ve been a professional software engineer and maintaining open-source software for 16 years. My work on open source has been heavily informed by industry best practises and my work on proprietary software has been heavily informed by open source best practises. Without these books, I’d be a worse engineer on many dimensions. Some of them may feel antiquated but all are still full of relevant wisdom for every open-source (and proprietary) software engineer today.
I was lucky enough to read an early draft of this book and it’s simply the best analysis of the open-source software ecosystem around today.
The writing style is friendly and not formal despite the academic-level research that went into this book. It made me think differently about the open-source projects I maintain and how I interact and chose those I use.
An inside look at modern open source software development and its influence on our online social world.
Open source software, in which developers publish code that anyone can use, has long served as a bellwether for other online behavior. In the late 1990s, it provided an optimistic model for public collaboration, but in the last 20 years it’s shifted to solo operators who write and publish code that's consumed by millions.
In Working in Public, Nadia Eghbal takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet…
I’ve been doing large-scale software development at great US businesses from the introduction of the PC to the cloud explosion. From my earliest successes (online banking at US Bank in 1985!) to my biggest failures (Wells Fargo “Core” disaster in 2006), I’ve always sought better ways of doing things. These five books all were important to my learning and remain highly relevant, and I hope you find them useful as well.
This book helped me set my initial approach to software development and I still periodically return to it for grounding.
An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.
Drawing on observation, interviews, and confidential data, the authors reveal Microsoft's product development, marketing, and organizational strategies.
I’m a software engineer because I’m a builder at heart. I have always had a profoundly curious mind, and always enjoyed tinkering. So at one point in my life, it became evident that I was going to be an engineer. I consider teaching the final step of learning, so whether this means writing an article or giving a talk, or simply sharing recommendations, I make a final effort to share with the community of like-minded people what I have learnt. For this reason, I hope you enjoy reading my book and the ones I recommended.
I’ve found in this book many useful topics about low-level design which connected with my first recommendation (Code Complete). For instance, about creating functions not only as a tactic for reusing code, but more as a way to give clear meaning to parts of the code, and make it more readable. I was happy to find in these authors ideas I have been agreeing with for a long time.
Then there’s also the fact that this book provides several examples with code on how to make the design simpler to maintain, and clearly illustrates the S.O.L.I.D. principles.
Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code "on the fly" into a book that will instill within you the values of a software craftsman and make you…
The problem is not with the actions young women take but with the toxic, sexist conditions they are responding to.
Tanenbaum found, based on six years of interviews with young people ages 14-30, that young women are navigating a culture littered with gendered dress codes, revenge porn, and sexually explicit…
I've been in the software engineering profession for over 40 years, working at companies as diverse as Bank Leumi, Jet Propulsion Laboratory, Graftek (a CAD startup), Silicon Graphics, Boeing, and Microsoft. As an architect, lead, manager, director, writer, and now career coach, I've been obsessed with finding practical ways to make my work easier, my staff and clients more productive, and our products more delightful. These five books (along with my book and blog) provide proven, time-tested techniques. Each is written clearly with real-life examples, so it is easy to reap the benefits. Smile as you learn to avoid the missteps made by those who coded before you.
Not only does this book provide insight into the planning and development of one of the first visual IDEs, it’s overflowing with hilarious, profound, and pragmatic real-life lessons for how to manage a software team and deliver a complex project.
As a product of its time, the writing isn’t always politically correct. However, many of the lessons and memes are still part of our vernacular today: Don’t flip the bozo bit; If you build it, it will ship; and [Love] the customer.
Some of its lessons should be memes: Beware of [an engineer] in a room, Be an authority, not an authority figure, and Don’t trade a bad date for an equally bad date.
Some sections show their age in our current world of continuous delivery, but few current books have the humor and concise insight of this remarkable work.
Shipping great software can be done, insists McCarthy, and charts, in five sections, the progress from initial design to successful product. McCarthy is a software industry veteran and the director of the Microsoft Visual C++ development group.
