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 have worked in IT for over 25 years, creating and securing software. I am completely obsessed with ensuring that our software is more reliable, that its integrity can be trusted, and that it keeps our secrets safe. I am not only a computer scientist but an ethical hacker who works hard to create a dialogue between software developers and all of the people who work in our security industry. I am a teacher, a community leader, and a computer nerd who shares messages and lessons wherever she goes.
The DevOps Handbook is literally an instructional guide on how to do DevOps, properly.
It includes security, it includes how to run operations in a smooth and reliable manner, and of course, how to develop amazing software. It gets into all the nitty gritty, with every detail you would need in order to create a good DevOps system development lifecycle within your organization.
This award-winning and bestselling business handbook for digital transformation is now fully updated and expanded with the latest research and new case studies!
"[The DevOps Handbook] remains a must-read for any organization seeking to scale up its IT capability and expand DevOps practices across multiple departments or lines of business." -Mike Perrow, TechBeacon
For years, The DevOps Handbook has been the definitive guide for taking the successes laid out in the bestselling The Phoenix Project and applying them in any organization. Now, with this fully updated and expanded edition, it's time to take DevOps out of the IT department and…
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…
Markus Gärtner works as Organizational Design Consultant, Certified Scrum Trainer, and Agile Coach for it-agile GmbH, Hamburg, Germany. Markus, author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development, a student of the work of Jerry Weinberg, received the Most Influential Agile Testing Professional Person Award in 2013 and contributes to the Softwerkskammer, the German Software Craft movement. Markus regularly presents at Agile and testing conferences all over the globe, as well as dedicating himself to writing about agile software development, software craft, and software testing, foremost in an Agile context.
“Good agile testing is good context-driven testing applied in an agile context.”
The authors of this book summarize their decades of experience in software testing in over 100 lessons they learned. Follow them along different aspects of the tester’s job, as they re-tell various stories collected over the years with some clear guidance to surviving and testing project.
These software testing industry leaders have some timely contextual advice in here – whether you work as a tester on an agile team or in a more traditional fashion.
Decades of software testing experience condensed into the most important lessons learned.
The world's leading software testing experts lend you their wisdom and years of experience to help you avoid the most common mistakes in testing software. Each lesson is an assertion related to software testing, followed by an explanation or example that shows you the how, when, and why of the testing lesson. More than just tips, tricks, and pitfalls to avoid, Lessons Learned in Software Testing speeds you through the critical testing phase of the software development project without the extensive trial and error it normally takes to…
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.
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.
This text defines governing principles for software development, assumptions that work regardless of tools used, to keep software projects from costing too much, taking too long and disappointing users.
I have been coding for over 30 years. I’ve seen some miserable interfaces, and some large programs that collapse under their own weight. Software was, at one point, notorious for being late, over budget, and unreliable. These books have helped turn the corner on these failings, and I have found each of them very valuable in my day-to-day programming. While you can learn technique and even languages online, the kind of insight found in these books is rare and worth spending time and money on.
Many of us have fully embraced agile programming, but doing it well, really well, requires discipline. In Clean Agile a number of world-class programmers discuss what it takes to put Agile programming into practice with y our team. This book has made me a much more “agile” agile programmer, and the section on SCRUM is worth the price of the book.
Agile Values and Principles for a New Generation "In the journey to all things Agile, Uncle Bob has been there, done that, and has the both the t-shirt and the scars to show for it. This delightful book is part history, part personal stories, and all wisdom. If you want to understand what Agile is and how it came to be, this is the book for you." -Grady Booch "Bob's frustration colors every sentence of Clean Agile, but it's a justified frustration. What is in the world of Agile development is nothing compared to what could be. This book is…
There are many creative professions where the performers practice their skills more often compared to the actual time they do the actual work.
Software development is widely considered as a creative profession. Unfortunately, it doesn’t fall into the category of professions where its practitioners hone their skills. This book discusses a coaching strategy where software teams can periodically practice and improve their technical practices.
“Samman” is the Swedish word for “together”. Organisations that invest in technical coaching increase their business success. This book is a real eye-opener for anyone who likes to improve their approach to team coaching. It lays out the groundwork for improving the technical practices of software teams.
Samman Technical Coaching is an approach to Agile training that focuses on technical questions concerning how code is written. It is a highly effective way of increasing agility in your software development organization. The first part of the Samman method involves the coach working in an ensemble with development teams, programming in their production codebase. This hands-on mentoring is accompanied by daily “learning hour” sessions for mastering particular techniques. In this book you will discover how to put Samman into practice, improve your coding procedures and how you collaborate. It is a practical guide for aspiring and experienced coaches looking…
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’m a professional software developer for more than 22 years now. I’ve used many programming languages, platforms, frameworks, etc. throughout my career. However, the only constant for me personally was the practice of Test-Driven Development. I’ve never stopped learning about the principles and practices behind it, and it paid huge dividends throughout my career. I’m very humbled and grateful to be able to learn from all those amazing people over the years, that I decided to write a book on the topic. Giving back some of the knowledge that I gathered about TDD throughout 18+ years.
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.
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism. When programming teams buy into TDD, they immediately see positive results. They eliminate the fear involved in their jobs, and are better equipped to tackle the difficult challenges that face them. TDD eliminates tentative traits, it teaches programmers to communicate, and it encourages team members to seek out criticism However, even the…
Computers have fascinated me since my childhood, having fond memories of my dad's ZX81, but even so I played around I was never truly captured by the programming until I recognized it as a way of writing rather than raw engineering. Through my studies of media sciences I found my fascination with how language can shape perception, and through my work in developer advocacy, I found how communities are shaped as well. Now I am fascinated with how different programming languages can shape thinking, having had the opportunity to solve problems at large companies in nonmainstream languages.
Distributed systems are everywhere now, but long before there were telephony switches, and Erlang was built to make those work.
Reading this book gave me not only an understanding about Erlang, but the language and understanding to talk and think about systems which are distributed from the beginning, not as an afterthought. For me personally Erlang/OTP is the DSL for dystributed system and the patterns implemented have applications every time I think about distributed systems now.
