- •Act with Prudence
- •Apply Functional Programming Principles
- •Ask "What Would the User Do?" (You Are not the User)
- •Automate Your Coding Standard
- •Beauty Is in Simplicity
- •Before You Refactor
- •Beware the Share
- •The Boy Scout Rule
- •Check Your Code First before Looking to Blame Others
- •Choose Your Tools with Care
- •Code in the Language of the Domain
- •Code Is Design
- •Code Layout Matters
- •Code Reviews
- •Coding with Reason
- •A Comment on Comments
- •Comment Only What the Code Cannot Say
- •Continuous Learning
- •Convenience Is not an -ility
- •Deploy Early and Often
- •Distinguish Business Exceptions from Technical
- •Do Lots of Deliberate Practice
- •Domain-Specific Languages
- •Don't Be Afraid to Break Things
- •Don't Be Cute with Your Test Data
- •Don't Ignore that Error!
- •Don't Just Learn the Language, Understand its Culture
- •Don't Nail Your Program into the Upright Position
- •Don't Rely on "Magic Happens Here"
- •Don't Repeat Yourself
- •Don't Touch that Code!
- •Encapsulate Behavior, not Just State
- •Floating-point Numbers Aren't Real
- •Fulfill Your Ambitions with Open Source
- •The Golden Rule of API Design
- •The Guru Myth
- •Hard Work Does not Pay Off
- •How to Use a Bug Tracker
- •Improve Code by Removing It
- •Install Me
- •Keep the Build Clean
- •Know How to Use Command-line Tools
- •Know Well More than Two Programming Languages
- •Know Your IDE
- •Know Your Limits
- •Know Your Next Commit
- •Large Interconnected Data Belongs to a Database
- •Learn Foreign Languages
- •Learn to Estimate
- •Learn to Say "Hello, World"
- •Let Your Project Speak for Itself
- •The Linker Is not a Magical Program
- •The Longevity of Interim Solutions
- •Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
- •Make the Invisible More Visible
- •Message Passing Leads to Better Scalability in Parallel Systems
- •A Message to the Future
- •Missing Opportunities for Polymorphism
- •News of the Weird: Testers Are Your Friends
- •One Binary
- •Only the Code Tells the Truth
- •Own (and Refactor) the Build
- •Pair Program and Feel the Flow
- •Prefer Domain-Specific Types to Primitive Types
- •Prevent Errors
- •The Professional Programmer
- •Put Everything Under Version Control
- •Put the Mouse Down and Step Away from the Keyboard
- •Read Code
- •Read the Humanities
- •Reinvent the Wheel Often
- •Resist the Temptation of the Singleton Pattern
- •The Road to Performance Is Littered with Dirty Code Bombs
- •Simplicity Comes from Reduction
- •The Single Responsibility Principle
- •Start from Yes
- •Step Back and Automate, Automate, Automate
- •Take Advantage of Code Analysis Tools
- •Test for Required Behavior, not Incidental Behavior
- •Test Precisely and Concretely
- •Test While You Sleep (and over Weekends)
- •Thinking in States
- •Two Heads Are Often Better than One
- •Two Wrongs Can Make a Right (and Are Difficult to Fix)
- •Ubuntu Coding for Your Friends
- •The Unix Tools Are Your Friends
- •Use the Right Algorithm and Data Structure
- •Verbose Logging Will Disturb Your Sleep
- •WET Dilutes Performance Bottlenecks
- •When Programmers and Testers Collaborate
- •Write Code as If You Had to Support It for the Rest of Your Life
- •Write Small Functions Using Examples
- •Write Tests for People
- •You Gotta Care about the Code
- •Your Customers Do not Mean What They Say
Your Customers Do not Mean What They Say
I've never met a customer yet that wasn't all too happy to tell me what they wanted — usually in great detail. The problem is that customers don't always tell you the whole truth. They generally don't lie, but they speak in customer speak, not developer speak. They use their terms and their contexts. They leave out significant details. They make assumptions that you've been at their company for 20 years, just like they have. This is compounded by the fact that many customers don't actually know what they want in the first place! Some may have a grasp of the "big picture," but they are rarely able to communicate the details of their vision effectively. Others might be a little lighter on the complete vision, but they know what they don't want. So, how can you possibly deliver a software project to someone who isn't telling you the whole truth about what they want? It's fairly simple. Just interact with them more.
Challenge your customers early and challenge them often. Don't simply restate what they told you they wanted in their words. Remember: They didn't mean what they told you. I often do this by swapping out words in conversation with them and judging their reaction. You'd be amazed how many times the term customer has a completely different meaning to the term client. Yet the guy telling you what he wants in his software project will use the terms interchangeably and expect you to keep track as to which one he's talking about. You'll get confused and the software you write will suffer.
Discuss topics numerous times with your customers before you decide that you understand what they need. Try restating the problem two or three times with them. Talk to them about the things that happen just before or just after the topic you're talking about to get better context. If at all possible, have multiple people tell you about the same topic in separate conversations. They will almost always tell you different stories, which will uncover separate yet related facts. Two people telling you about the same topic will often contradict each other. Your best chance for success is to hash out the differences before you start your ultra-complex software crafting.
Use visual aids in your conversations. This could be as simple as using a whiteboard in a meeting, as easy as creating a visual mock-up early in the design phase, or as complex as crafting a functional prototype. It is generally known that using visual aids during a conversation helps lengthen our attention span and increases the retention rate of the information. Take advantage of this fact and set your project up for success.
In a past life, I was a "multimedia programmer" on a team who produced glitzy projects. A client of ours described their thoughts on the look and feel of the project in great detail. The general color scheme discussed in the design meetings indicated a black background for the presentation. We thought we had it nailed. Teams of graphic designers began churning out hundreds of layered graphics files. Loads of time was spent molding the end product. A startling revelation was made on the day we showed the client the fruits of our labor. When she saw the product, her exact words about the background color were "When I said black, I meant white." So, you see, it is never as clear as black and white.
By Nate Jackson