97 Things Every Programmer Should Know - Extended cover page

97 Things Every Programmer Should Know - Extended

97 Things Every Programmer Should Know - Extended

97 Things Every Programmer Should Know - Extended Edit


About the Book

Welcome to the extended version of 97 Things Every Programmer Should Know - Collective Wisdom from the Experts.

97 Things Every Programmer Should Know (http://programmer.97things.oreilly.com) site contains amazing collection of essays about programming practices. Kevlin Henney has created a nice book "97 Things Every Programmer Should Know" of the selected 97 essays.

This books is a collection of additional 68 essays available at the site but doesn't appear in Kevlin's book.

The text in the book is taken from site **as is**. If you find any typographic error, please let us know and/or go ahead and update the original site.

Read more

Table of Contents

  • Preface
    • Permissions
    • About
    • Acknowledgement
  • Abstract Data Types
  • Acknowledge (and Learn from) Failures
  • Anomalies Should not Be Ignored
  • Avoid Programmer Churn and Bottlenecks
  • Balance Duplication, Disruption, and Paralysis
  • Be Stupid and Lazy
  • Become Effective with Reuse
  • Better Efficiency with Mini-Activities, Multi-Processing, and Interrupted Flow
  • Code Is Hard to Read
  • Consider the Hardware
  • Continuous Refactoring
  • Continuously Align Software to Be Reusable
  • Data Type Tips
  • Declarative over Imperative
  • Decouple that UI
  • Display Courage, Commitment, and Humility
  • Dive into Programming
  • Don’t Be a One Trick Pony
  • Don’t Be too Sophisticated
  • Don’t Reinvent the Wheel
  • Don’t Use too Much Magic
  • Done Means Value
  • Execution Speed versus Maintenance Effort
  • Expect the Unexpected
  • First Write, Second Copy, Third Refactor
  • From Requirements to Tables to Code and Tests
  • How to Access Patterns
  • Implicit Dependencies Are also Dependencies
  • Improved Testability Leads to Better Design
  • In the End, It’s All Communication
  • Integrate Early and Often
  • Interfaces Should Reveal Intention
  • Isolate to Eliminate
  • Keep Your Architect Busy
  • Know When to Fail
  • Know Your Language
  • Learn the Platform
  • Learn to Use a Real Editor
  • Leave It in a Better State
  • Methods Matter
  • The Programmer’s New Clothes
  • Programmers Are Mini-Project Managers
  • Programmers Who Write Tests Get More Time to Program
  • Push Your Limits
  • QA Team Member as an Equal
  • Reap What You Sow
  • Respect the Software Release Process
  • Restrict Mutability of State
  • Reuse Implies Coupling
  • Scoping Methods
  • Simple Is not Simplistic
  • Small!
  • Soft Skills Matter
  • Speed Kills
  • Structure over Function
  • Talk about the Trade-offs
  • There Is Always Something More to Learn
  • There Is No Right or Wrong
  • There Is No Such Thing as Self-Documenting Code
  • The Three Laws of Test-Driven Development
  • Understand Principles behind Practices
  • Use Aggregate Objects to Reduce Coupling
  • Use the Same Tools in a Team
  • Using Design Patterns to Build Reusable Software
  • Who Will Test the Tests Themselves?
  • Work with a Star and Get Rid of the Truck Factor
  • Write a Test that Prints PASSED
  • Write Code for Humans not Machines

Read More

About the Editor

The Leanpub Unconditional, No Risk, 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks. We process the refunds manually, so they may take a few days to show up.
See full terms