Here are 82 books that Working in Public fans have personally recommended if you like
Working in Public.
Book DNA is a community of 12,000+ authors and super readers sharing their favorite books with the world.
The art of computer programming is a lot like the art of writing: It's not just about what your program says but about how it says it. One of the reasons I like the C and C++ languagesâwhich I picked up in the late 1990s and haven't put down sinceâis that, as compiled, non-sandboxed languages, they promise total control over the machine. Show me where you want each byte of data to go in memory; show me the machine instructions you want; and I can make C++ do that for you.Â
This book greatly influenced my philosophy around style. Norman's ostensible subject is the design of physical objects, like emergency exits, shower faucets, and refrigerators, but most of what he says is directly applicable to software design and API design, too.
For example: Whatever you expose or document about your interface, the user will take that and form a mental model of the implementationâand he'll program against that mental model, not against your documentation. So you'd better make sure that your interfaceâby exposing certain details and deemphasizing others, appropriate naming, and so onâsuggests a mental model that will be useful to the user (even if it is not correct in every particular).
For example, a horizontal rod mounted on a door affords pushing (a bit of jargon that's entered my technical vocabulary), while a vertical rod affords pulling. If you use the design language of a horizontal rod, people willâŠ
Even the smartest among us can feel inept as we fail to figure out which light switch or oven burner to turn on, or whether to push, pull, or slide a door. The fault, argues this ingenious,even liberating,book, lies not in ourselves, but in product design that ignores the needs of users and the principles of cognitive psychology. The problems range from ambiguous and hidden controls to arbitrary relationships between controls and functions, coupled with a lack of feedback or other assistance and unreasonable demands on memorization. The Design of Everyday Things shows that good, usable design is possible. TheâŠ
It is April 1st, 2038. Day 60 of China's blockade of the rebel island of Taiwan.
The US government has agreed to provide Taiwan with a weapons system so advanced that it can disrupt the balance of power in the region. But what pilot would be crazy enough to runâŠ
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.
This is the oldest book on my list and is the most underrated. It describes, with serious rigour and detail, how to run more effective software projects and teams.
Most of this advice has been ignored by most of the industry for most of the time but itâs a big part of the reason Iâve worked from home for 14 years and am as productive as I am today.
Demarco and Lister demonstrate that the major issues of software development are human, not technical. Their answers aren't easy--just incredibly successful. New second edition features eight all-new chapters. Softcover. Previous edition: c1987. DLC: Management.
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.
This is from an older generation of open source development, pre-GitHub, but much of the advice here is still incredibly relevant and astute today, helping provide advice on the interpersonal as well as technical sides to open source development.
Many of the underlying principles from this book are what form my grounding as an open-source maintainer for the last 15 years.
The corporate market is now embracing free, "open source" software like never before, as evidenced by the recent success of the technologies underlying LAMP (Linux, Apache, MySQL, and PHP). Each is the result of a publicly collaborative process among numerous developers who volunteer their time and energy to create better software. The truth is, however, that the overwhelming majority of free software projects fail. To help you beat the odds, O'Reilly has put together Producing Open Source Software, a guide that recommends tried and true steps to help free software developers work together toward a common goal. Not just forâŠ
The Year Mrs. Cooper Got Out More
by
Meredith Marple,
The coastal tourist town of Great Wharf, Maine, boasts a crime rate so low you might suspect someoneâs lying.
Nevertheless, jobless empty nester Mallory Cooper has become increasingly reclusive and fearful. Careful to keep the red wine handy and loath to leave the house, Mallory misses her happier selfâand soâŠ
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.
Another book that predates GitHub but provides a lot of actionable advice today thatâs been mostly ignored across much of our industry.
Hard problems like âwhy isnât my software project reliable?â are tackled head-on and addressed here. It was an early nudge for me to automate as much as possible in software projects and not ignore difficult problems with project organisation in favour of âfunâ technical tasks.
"Ship It!" is a collection of tips that show the tools and techniques a successful project team has to use, and how to use them well. You'll get quick, easy-to-follow advice on modern practices: which to use, and when they should be applied. This book avoids current fashion trends and marketing hype; instead, readers find page after page of solid advice, all tried and tested in the real world. Aimed at beginning to intermediate programmers, "Ship It!" will show you: which tools help, and which don't, how to keep a project moving, approaches to scheduling that work, how to buildâŠ
My first computer was an early IBM PC back when all my friends had Commodores they used for gaming. Not being able to share their games meant I had to do something else, so I read the Introduction to Basic book that came in the box. Iâve been coding, reading about coding, writing about coding, teaching about coding, and talking about coding ever since. The world of technology moves so fast that it is hard to keep up. If youâve taken one of my courses or listened to The Real Python Podcast, I hope youâve heard about my passion for the topic.
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.
"I have studied Rosen's book in detail and am impressed with its scope and content. I strongly recommend it to anybody interested in the current controversies surrounding open source licensing." -John Terpstra, Samba.org; cofounder, Samba-Team"Linux and open source software have forever altered the computing landscape. The important conversations no longer revolve around the technology but rather the business and legal issues. Rosen's book is must reading for anyone using or providing open source solutions." -Stuart Open Source Development LabsA Complete Guide to the Law of Open Source for Developers, Managers, and Lawyers
Now that open source software is blossoming aroundâŠ
I boast a two-decade-long career in the software industry. Over the years, I have diligently honed my programming skills across a multitude of languages, including JavaScript, C++, Java, Ruby, and Clojure. Throughout my career, I have taken on various management roles, from Team Leader to VP of Engineering. No matter the role, the thing I have enjoyed the most is to make complex topics easy to understand.
This book profoundly changed how I approach functional programming. I found its deep dive into core concepts like recursion, abstraction, and modularity incredibly insightful. The exercises pushed me to think critically and refine my problem-solving process.
Despite being an older book, its content remains relevant and valuable to me. I consider it the best pragmatic introduction to functional programming.
As others have gone into, this is a great programming book for many reasons, and is a must-read for anyone who is interested in software design. Rather than waste time reaffirming the excellent positive reviews of this book, I wanted to cover something that I have not seen in the reviews: namely that there are multiple publishers for this book (as it is an "open source" book). At the time of writing, there is this McGraw-Hill publication, and, for 40% less, an MIT press edition. While I have not seen the McGraw-Hill version in person to see what quality benefitsâŠ
Donât mess with the hotheadâor he might just mess with you. Slater Ibåñez is only interested in two kinds of guys: the ones he wants to punch, and the ones he sleeps with. Things get interesting when they start to overlap. A freelance investigator, Slater trolls the dark side ofâŠ
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â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â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âŠ
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 andâŠ
