best practices

First make it work (get tests to pass). Then make it right (clean it). Then make it fast. (if it needs it). Uncle Bob (via How to convince ‘performance guys’ to Clean Code – Google Groups )

The User is Drunk (by squareweave ) Blurry vision Attention-poor (Guide them) Say it twice Emotional (Do over the shoulder testing) Drunk, not dumb ( Source: https://www.youtube.com/ )

(via The 5 Rules of Storytelling Every Teacher Should Know about ~ Educational Technology and Mobile Learning )

All well-drawn characters have a spine. And the idea is that the character has an inner motor, a dominant, unconscious goal that they’re striving for, an itch that they can’t scratch. Judith Weston (via Andrew Stanton: The clues to a great story | TED.com )

All good stories (…) should give you a promise. [to be fulfilled] Make the audience put things together. Don’t give them four, give them two plus two. [“The Unifying Theory of 2 + 2”] Storytelling has guidelines, not hard, fast rules. A strong theme is always running through well told story. The best stories infuse wonder. (via Andrew Stanton: The clues to a great story | Video on TED.com)

Drama is anticipation mingled with uncertainty William Archer (via Andrew Stanton: The clues to a great story | TED.com )

Support Guidelines « Vesper Dave Wiskus ’ guidelines for handling @vesperapp support emails: Use Names Everyone Gets a Reply No Arguments Keep Records Be Honest Sooner is Better Ask for a Favor Say ‘Thank You’

iOS Design Patterns The tutorial is divided into sections, one section per design pattern. In each section, you’ll read an explanation of the following: What the design pattern is. Why you should use it. How to use it and, where appropriate, common pitfalls to watch for when using the pattern. (…) In the process of developing this app, you’ll become acquainted with the most common Cocoa design patterns: Creational : Singleton and Abstract Factory. Structural : MVC, Decorator, Adapter, Facade and Composite. Behavioral : Observer, Memento, Chain of Responsibility and Command.

newfoo: Good Practices for Big iPhone Projects Developing a high-quality iPhone app can be tricky stuff for new and veteran developers alike – especially on larger projects. In this article, I’ll discuss several tools & techniques that have helped my teams and me to produce high quality work and helped save a lot of time. Use Multiple Build Configurations Use an Enhanced UIColor Use isEmpty Instead of Nil and Length Checks Use Logging Treat Compile Warnings as Errors Use Static Analysis Frequently Learn Apple’s Rules for Memory Management

Warnings I turn on, and why » Idle Time I’ve started turning on most of Xcode’s warning options and one warning-related build setting in all of my personal projects. I suggest you do the same. (…) The rest of the warnings, I turn on because either they make something clearer or they tell me about either real or potential (i.e., future real) bugs. See also boredzo/Warnings-xcconfig repo at GitHub.

High Scalability – Expandability: Steve Wozniak’s Biggest Success and Nolan Bushnell’s Biggest Regret Lesson: Think Geek The lesson: when your grownup self compels you to be lean and create something minimally viable – think geek. It may not make your accountants happy, but your “just because it seems like a great thing” idea might be exactly what you need to become more successful than you can possibly imagine.

Typography in ten minutes — Butterick’s Practical Typography This is a bold claim, but i stand behind it: if you learn and follow these five typography rules, you will be a better typographer than 95% of professional writers and 70% of professional designers. (The rest of this book will raise you to the 99th percentile in both categories.) All it takes is ten minutes—five minutes to read these rules once, then five minutes to read them again. ...

97 Things Every Programmer Should Know – Contributions Appearing in the Book Act with Prudence by Seb Rose Apply Functional Programming Principles by Edward Garson Ask “What Would the User Do?” (You Are not the User) by Giles Colborne Automate Your Coding Standard by Filip van Laenen Beauty Is in Simplicity by Jørn Ølmheim Before You Refactor by Rajith Attapattu Beware the Share by Udi Dahan The Boy Scout Rule by Uncle Bob Check Your Code First before Looking to Blame Others by Allan Kelly Choose Your Tools with Care by Giovanni Asproni Code in the Language of the Domain by Dan North Code Is Design by Ryan Brush Code Layout Matters by Steve Freeman Code Reviews by Mattias Karlsson Coding with Reason by Yechiel Kimchi A Comment on Comments by Cal Evans Comment Only What the Code Cannot Say by Kevlin Henney Continuous Learning by Clint Shank Convenience Is not an -ility by Gregor Hohpe Deploy Early and Often by Steve Berczuk Distinguish Business Exceptions from Technical by Dan Bergh Johnsson Do Lots of Deliberate Practice by Jon Jagger Domain-Specific Languages by Michael Hunger Don’t Be Afraid to Break Things by Mike Lewis Don’t Be Cute with Your Test Data by Rod Begbie Don’t Ignore that Error! by Pete Goodliffe Don’t Just Learn the Language, Understand its Culture by Anders Norås Don’t Nail Your Program into the Upright Position by Verity Stob Don’t Rely on “Magic Happens Here” by AlanGriffiths Don’t Repeat Yourself by Steve Smith Don’t Touch that Code! by Cal Evans Encapsulate Behavior, not Just State by Einar Landre Floating-point Numbers Aren’t Real by Chuck Allison Fulfill Your Ambitions with Open Source by Richard Monson-Haefel The Golden Rule of API Design by Michael Feathers The Guru Myth by Ryan Brush Hard Work Does not Pay Off by Olve Maudal How to Use a Bug Tracker by Matt Doar Improve Code by Removing It by Pete Goodliffe Install Me by Marcus Baker Inter-Process Communication Affects Application Response Time by Randy Stafford Keep the Build Clean by Johannes Brodwall Know How to Use Command-line Tools by Carroll Robinson Know Well More than Two Programming Languages by Russel Winder Know Your IDE by Heinz Kabutz Know Your Limits by Greg Colvin Know Your Next Commit by Dan Bergh Johnsson Large Interconnected Data Belongs to a Database by Diomidis Spinellis Learn Foreign Languages by Klaus Marquardt Learn to Estimate by Giovanni Asproni Learn to Say “Hello, World” by Thomas Guest Let Your Project Speak for Itself by Daniel Lindner The Linker Is not a Magical Program by Walter Bright The Longevity of Interim Solutions by Klaus Marquardt Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers Make the Invisible More Visible by Jon Jagger Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder A Message to the Future by Linda Rising Missing Opportunities for Polymorphism by Kirk Pepperdine News of the Weird: Testers Are Your Friends by Burk Hufnagel One Binary by Steve Freeman Only the Code Tells the Truth by Peter Sommerlad Own (and Refactor) the Build by Steve Berczuk Pair Program and Feel the Flow by Gudny Hauknes , Ann Katrin Gagnat , and Kari Røssland Prefer Domain-Specific Types to Primitive Types by Einar Landre Prevent Errors by Giles Colborne The Professional Programmer by Uncle Bob Put Everything Under Version Control by Diomidis Spinellis Put the Mouse Down and Step Away from the Keyboard by Burk Hufnagel Read Code by Karianne Berg Read the Humanities by Keith Braithwaite Reinvent the Wheel Often by Jason P Sage Resist the Temptation of the Singleton Pattern by Sam Saariste The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine Simplicity Comes from Reduction by Paul W. Homer The Single Responsibility Principle by Uncle Bob Start from Yes by Alex Miller Step Back and Automate, Automate, Automate by Cay Horstmann Take Advantage of Code Analysis Tools by Sarah Mount Test for Required Behavior, not Incidental Behavior by Kevlin Henney Test Precisely and Concretely by Kevlin Henney Test While You Sleep (and over Weekends) by Rajith Attapattu Testing Is the Engineering Rigor of Software Development by Neal Ford Thinking in States by Niclas Nilsson Two Heads Are Often Better than One by Adrian Wible Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly Ubuntu Coding for Your Friends by Aslam Khan The Unix Tools Are Your Friends by Diomidis Spinellis Use the Right Algorithm and Data Structure by JC van Winkel Verbose Logging Will Disturb Your Sleep by Johannes Brodwall WET Dilutes Performance Bottlenecks by Kirk Pepperdine When Programmers and Testers Collaborate by Janet Gregory Write Code as If You Had to Support It for the Rest of Your Life by Yuriy Zubarev Write Small Functions Using Examples by Keith Braithwaite Write Tests for People by Gerard Meszaros You Gotta Care about the Code by Pete Goodliffe Your Customers Do not Mean What They Say by Nate Jackson \

People like us do stuff like this Seth’s Blog “There is no more powerful tribal marketing connection than this.”

Dan Shapiro » How to read a patent in 60 seconds Step 1: Skip the title Step 2: Skip the drawings Step 3: Skip the abstract Step 4: Skip the specification Step 5: Find the independent claims, and read them Step 6: Back to skipping – toss the dependent claims [unless the independent ones are bogus/obvious] Useful for checking “requests for prior art” in Ask Patents

Le mieux est l’ennemi du bien. Voltaire (via Wikiquote ) (en) *The best is the enemy of the good.\ (pt) O óptimo é inimigo do bom.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Donald Knuth (via When optimal matters ) ...

When optimal matters | Playing with Objects The rules of optimization (…) When you are thinking on making an optimization: First time: Don’t do it! Second time: Don’t do it yet! Third time: Ok, but you first profile and measure, and then optimize

And here’s how to do it in your own presentations: Craft the Beginning Develop the Middle Make the Ending Powerful (via Structure Your Presentation Like a Story – Nancy Duarte – Harvard Business Review ) See also the related TED presentation: Nancy Duarte: The secret structure of great talks | Video on TED.com

The 7 Habits of Highly Effective People by Stephen Covey (1932-2012) Be proactive Begin with the end in mind Put first things first Think win-win Seek first to understand and the to be understood Synergize Sharpen the saw … and the eighth habit is to: Find your voice and inspire others to find theirs Old, but timeless!