An investment in knowledge always pays the best interest.
– Benjamin Franklin
Give someone a program, you frustrate them for a day; teach them how to program, you frustrate them for a lifetime.
– David Leinweber
- Code Review
- Communication
- Documentation
- Git
- Naming Things
- Philosophy
- Python
- Refactoring
- Technical Debt
- Testing
- Wisdom
- "Constructive Code Review" by Erik Rose
- "How to Do Code Reviews Like a Human" by Michael Lynch
- "How to Make Your Code Reviewer Fall in Love with You" by Michael Lynch
- "All About Code Review" by Michaela Greiler
- "The Art of Good Code Review" by Phil Booth
- "Writing Sensible Email Messages" by Merlin Mann
- "The 37signals Guide to Internal Communication"
- "How to Send Progress Updates" by Slava Akhmechet
- "My Favorite Teacher" by Thorsten Ball
- "5 Non-Verbal Behaviors Killing Team Health" by Raviraj Achar
- "How to Share Your Point of View (Even If You're Afraid of Being Wrong)" by Wes Kao
- "An Engineer's Guide to Talking to Users" by Ian Vanagas
- "Communicate Like a Senior: Use Clear Deltas" by Jordan Cutler
- "How I Give the Right Amount of Context (In Any Situation)" by Wes Kao
Documentation is a love letter that you write to your future self.
– Damian Conway
- "The Art of Documentation" by Chelsea Troy
- "Writing Great Documentation" by Jacob Kaplan-Moss
- "Teach, Don't Tell" by Steve Losh
- "Becoming a Better Writer as a Software Engineer" by Gergely Orosz
- "Explain Like I'm Five" by Andrew Bosworth
- "What Makes Documentation Good" by Ted Sanders
- "How to Write a Good Design Document" by Grant Slatton
- "Summarizing Our Recommendations For Software Documentation" by Nicole Tietz-Sokolskaya
- "Basic Things" by Alex Kladov
- "The Documentation Tradeoff" by Kent Beck
- "Building Docs Like Code: Continuous Integration for Documentation" by Mason Egger
- "How to Write a Git Commit" by Chris Beams
- "A Useful Template for Commit Messages" by David Winterbottom
- "Git Commit Messages for the Bold and the Daring" by Carmen Popoviciu
- "My Favorite Git Commit" by David Thompson
- "Inside .git" by Julia Evans
- "Git Tips and Tricks" by Scott Chacon
There are only two hard things in computer science: cache invalidation and naming things.
– Phil Karlton
- "Naming Conventions in Programming - A Review of Scientific Literature" by Iwo Herka
- "On the Importance of Naming in Programming" by Martin Sosic
- "What's in a Name?" by Adam Raider
- "When to Use Cute Names or Descriptive Names" by Nicole Tietz-Sokolskaya
- "Improve Readability With Positive Booleans" by Max Kanat-Alexander
- "isBooleanTooLongAndComplex" by Yiming Sun
- "A Philosophy of Software Design" by John Ousterhout
- "7 Code Virtues Explained" by Tim Ottinger
- "Cognitive Load in Software Development" by Artem Zakirullin
- "Hacker Laws" by Dave Kerr
- "Lessons Learned" by Paul Homer
- "Mastering Programming" by Kent Beck
- "Good Software Development Habits" by Zarar Siddiqi
- "Developer Philosophy" by qntm
- "4 Software Design Principles I Learned the Hard Way" by Leonardo Creed
- "The DRY Principle: Benefits and Costs with Examples" by Matthieu Cneude
- "Null Hell and How to Get Out of It" by Anna Filina
- "Lessons from Debugging" by Matt Rickard
- "Use Abstraction to Improve Function Readability" by Palak Bansal and Mark Manley
- "Programming Mantras are Proverbs" by Luke Plant
- "We are Destroying Software" by Salvatore Sanfilippo
- "Beyond PEP8: Best Practices for Beautiful Intelligble Code" by Raymond Hettinger
- "Readability Counts" by Trey Hunner
- "The Zen of Python" by Tim Peters
- "The Clean Architecture in Python" by Brandon Rhodes
- "Notes from 'Python Best Practice Patterns'" by Steven Loria
- "The Best of the Best Practices (BOBP) Guide for Python" by Steven Loria
- "Align the Happy Path to the Left Edge" by Mat Ryer
- "If Statements are a Code Smell" by Aly Sivji
- "Push Ifs Up And Fors Down" by Alex Kladov
- PEP8, the general Python style guide
- PEP257, the Python docstring style guide
- "A Guide to Python's Magic Methods" by Rafe Kettler
- "Python Design Patterns" by Brandon Rhodes
- pyformat.info
- strftime.org
- "Pyambic Pentameter: Generating Rhyming and Metered Poems" by Kathryn Lingel (source)
- "Deliberate Functional Practice in Python" by Michał Moroz
If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring.
– Martin Fowler, Refactoring
- "Catalog of Refactorings" from Refactoring by Martin Fowler
- "Unraveling the Spaghetti: Tips for Refactoring Your Code" by Nicholas Del Grosso
- "Technical Debt" by Martin Fowler
- "Quantifying Technical Debt" by Chelsea Troy
- "Technical Debt: An Analytical Approach" by Chelsea Troy
- "Technical Debt != Bad Coding" by Joshua Arnold
Code without tests is broken as designed.
– Jacob Kaplan-Moss
A program that has not been tested does not work.
– Bjarne Stroustrup
Testing shows the presence, not the absence, of bugs.
– Edsger W. Dijkstra
When faced with a particularly gnarly problem, stop trying to solve the problem. Start figuring out how to not have it.
– Sophie Haskins (source)
I hate code, and I want as little of it as possible in our product. We ship features; we do not ship code.
– Jack Diederich (source)
Simplicity is prerequisite for reliability.
– Edsger W. Dijkstra
Debugging is twice as hard as writing code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition, not smart enough to debug it.
– Brian Kernighan
Programs must be written for people to read and only incidentally for machines to execute.
– Harold Abelson, Structure and Interpretation of Computer Programs
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
– Martin Fowler
Don't fight forces, use them.
– R. Buckminster Fuller
Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.
– Fred Brooks, The Mythical Man-Month
Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.
– Eric Raymond, The Cathedral and the Bazaar
There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.
– Tony Hoare
If you try to trade off quality for speed, you'll end up with neither.
– Allen Holub (source)
The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
– Edsger W. Dijkstra
If you wait until you can make a complete justification for a change, you've waited too long.
– Eric Evans, Domain-Driven Design, Chapter 13: "Refactoring Toward Deeper Insight"
The purpose of software engineering is to control complexity, not to create it.
– Pamela Zave
If all else is equal, more code is bad – but rarely is all else equal. The extra code breaks up the logic into identifiable parts, separating the calculations of the statements from the layout. This modularity makes it easier for me to understand the parts of the code and how they fit together. Brevity is the soul of wit, but clarity is the soul of evolvable software.
– Martin Fowler, Refactoring
When I first started at Resolver, I used to virtuously pepper my code with nice descriptive comments. My colleagues said to me: "Harry, we have a word for comments. We call them lies."
– Harry J.W. Percival, Test-Driven Development with Python
Code is like poetry; most of it shouldn't have been written.
– David Jacobs (source)
Debugging is like being the detective in a crime movie where you are also the murderer.
– Filipe Fortes (source)
Nothing is more dangerous than an idea if it's the only one you have.
– Emil-Auguste Chartier, Propos sur la religion, 1938
You cannot control an exponential process with a linear response.
– Dr. Duncan Robertson (source)
... there are few things that are less logical than business logic.
– Martin Fowler, Patterns of Enterprise Application Architecture
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.
– Edsger W. Dijkstra
Don't even start considering solutions until you understand the problem. Your goal should be to "solve" the problem mostly within the problem domain, not the solution domain.
– Oz Nova, "You Are Not Google"
You haven't mastered a tool until you understand when it should not be used.
– Kelsey Hightower (source)
In theory, there is no difference between theory and practice. In practice, there is.
– Yogi Berra
There is only one true requirement for any software: make your users/customers' lives better. Everything else is just implementation detail.
– Allen Holub (source)
Data is a precious thing and will last longer than the systems themselves.
– Tim Berners-Lee
It is foolish to answer a question that you do not understand. It is sad to work for an end that you do not desire.
– George Pólya, How to Solve It: A New Aspect of Mathematical Method
... familiarity masquerades as simplicity until you’re waist-deep in the implementation.
– Chelsea Troy, "Elevators in Python are Harder Than They Sound (Part 2)"
The first step of any project is to grossly underestimate its complexity and difficulty.
– Nicoll Hunt (source)
In preparing for battle I have always found that plans are useless but planning is indispensable.
– Dwight D. Eisenhower
My rule is a variation on the camping rule: Always leave the code base healthier than you found it.
– Martin Fowler, Refactoring
All problems in computer science can be solved by adding another level of indirection.
– David Wheeler
It is impossible for a man to learn what he thinks he already knows.
– Epictetus
It is a profoundly erroneous truism... that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them.
– Alfred North Whitehead
I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated.
– Poul Anderson
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
– Tom Cargill
In programming, if someone tells you "you're overcomplicating it," they're either ten steps behind you or ten steps ahead of you.
– Andrew Clark
Understand what problem you’re solving. Knowing why you’re doing something is a requirement to knowing whether you’re actually solving the problem.
– Thorsten Ball, "The Basics"
In our culture, innovation is revered, and maintenance is not. In IT there is a myopic attention to the latest tech and a failure to recognize and value that IT maintenance requires great skill and can be innovative (new processes, new fixes, etc.).
– Jeffrey Yost, "Where Dinosaurs Roam and Programmers Play: Reflections on Infrastructure, Maintenance, and Inequality"
Never confuse movement with action.
– Ernest Hemingway
Sometimes the problem is to discover what the problem is.
– Gordon Glegg, The Design of Design
The first principle is that you must not fool yourself – and you are the easiest person to fool.
– Richard Feynman
For each desired change, make the change easy (warning: this may be hard), then make the easy change.
– Kent Beck (source)
For every complex problem there is an answer that is clear, simple, and wrong.
– H.L. Mencken
The function of good software is to make the complex appear to be simple.
– Grady Booch
Changing random stuff until your program works is bad coding practice, but if you do it fast enough, it's machine learning.
– Unknown (source)