"HOW TO STOP SUCKING AND BE AWESOME INSTEAD" by Jeff Atwood

• Lists don't actually make you more organized long term.
• The hoarder thinks he has a storage problem when he really has a 'throwing things away problem'.
• You have to figure out what's important to you and what motivates you; ask yourself why that stuff isn't gnawing at you enough to make you get it done.
• In his seminal book about open source software, The Cathedral and the Bazaar, Eric Raymond wrote: ‘Every good work of software starts by scratching a developer’s personal itch.’
• I think there's enough of a track record of documented success that it's worth lobbying for something like Hack Days or 20 percent time wherever you work.
• To have any hope of influencing others, you must be able to persuade them.
• Nobody ever changed anything by remaining quiet, idly standing by, or blending into the faceless, voiceless masses. If you ever want to effect change, in your work, in your life, you must learn to persuade others.
• I believe it's impossible to succeed without failing.
• Failure is a wonderful teacher. But there's no need to seek out failure. It will find you.
• The only truly failed project is the one where you didn't learn anything along the way.
• I proved that a very average instructor could get exceptional results by putting the focus ENTIRELY on the students.
• You, as the instructor, have to design and enable situations that cause things to happen.
• Don't be cowed by the existence of thousands of developers far more talented than you are. Who needs talent when you have intensity?
• Being an expert isn't telling other people what you know. It's understanding what questions to ask, and flexibly applying your knowledge to the specific situation at hand.
• Don't confuse experience with expertise.
• That's not to say that all software project management books are crap. Just most of them. One of the few that I've found compelling enough to finish is Johanna Rothman's “Behind Closed Doors: Secrets of Great Management.”
• Every time someone asks you what your schedule is, you should be able to point to a list of everything you need to do. And if you can't—the first item on your task list should be to create that list.
• Speed of iteration, Boyd suggested, beats quality of iteration.
• Boyd's Law of Iteration: speed of iteration beats quality of iteration.
• When in doubt, iterate faster.
• “This notion of overnight success is very misleading, and rather harmful. If you're starting something new, expect a long journey.
• Success takes years.
• The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes.
• There's a vast divide between good developers and mediocre developers.
• From what I've seen, there's just no crossing the skill chasm as a software developer. You've either got it, or you don't.
• To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming.
• The greatest missing skill is somebody who's both good at understanding the engineering and who has good relationships with the hard-core engineers, and bridges that to working with the customers and the marketing and things like that.
• The Evolution of Forth, which outlines Charles Moore's guiding principles in creating and implementing the FORTH language, is an excellent illustration of the timelessness of ancient computer wisdom:
• Keep it simple: As the number of capabilities you add to a program increases, the complexity of the program increases exponentially.
• Do not speculate: Do not put code in your program that might be used.
• You have to make your own mistakes to truly learn.
• In particular, most people can't learn to program: between 30 percent and 60 percent of every university computer science department's intake fail the first programming course. Experienced
• The single most common mistake in any project is failure to read and follow manufacturer's instructions for tools and materials being used.
• Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing?
• Don't repeat yourself is important if you want flexible and maintainable software.
• Any time you see duplicate code, that's a danger sign. Complexity is a cost; don't pay it twice.
• Each variable, each line of code, each function, each class, each project should Do One Thing.
• Effortful study means constantly tackling problems at the very edge of your ability.
• Unless you're failing some of the time, you're probably not growing professionally. You have to seek out those challenges and push yourself beyond your comfort limit.
• Make a list of your 10 favorite programming tools: the ones you feel you use the most, the ones you almost couldn't live without.
• What I learned from judging the Rails Rumble most of all is that your website's front page needs to be kind of awesome.
• The first challenge you have is not coding your app. It is explaining what problem your app solves, and why anyone in the world would possibly care about that.
• Embrace your audience, even if it means excluding other audiences.
• There's already too much ‘more’—what we need are simple solutions to simple, common problems, not huger solutions to huger problems.
• We should always be in pursuit of simplicity, in whatever form it takes.
• Having a limited, fixed palette of UI controls and screen space is a strength.
• Design simple things that scale up; not complicated things you need to scale down.
• Websites are as close to universal as we may ever get in the world of software.
• Always favor consistency over cleverness.
• We should, as much as possible, try to do things the same way everyone else does them. Why? Because you won't be the only person to work on this code.
• If you don't have people that care about usability on your project, your project is doomed.
• One of the holy grails of usability testing is eyetracking—measuring where people's eyes look as they use software and web pages.
• You should certainly try to put the most important information at the top of whatever it is you're writing, be it a website, a program, an email, a resume, etc.
• Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.
• Keep a laser-like focus on doing a few things, and doing them exceptionally well.
• It takes a lot more courage to say "no" than it does to nod along in the hopes of pleasing everyone.
• You can't knock simplicity.
• The problem with unit testing, then, is not the implementation. It's determining what to test. And how to test it.
• The real value of unit testing is that it forces you to stop and think about testing.
• Users are crazy. Automated test suites are a poor substitute for real world beta testing by actual beta testers.
• Although software is notoriously unreliable, we can't always blame the software. Sometimes you really do have a hardware problem.
• You need to have a central place that all your errors are aggregated, a place that all the developers on your team know intimately and visit every day.
• The price of control is always more effort and increased complexity.
• For Homo logicus, control is their goal and complexity is the price they will pay for it. For normal humans, simplicity is their goal, and relinquishing control is the price they will pay.
• Anybody can build a complex application that nobody can figure out how to use. That's easy. Building an application that's simple to use.. well, now that takes actual skill.
• Part of being a good software developer is knowing your limits.
• For any silicon-based product, if we graph the number of users against their particular skill level, there will be a few beginners on the left side, a few experts on the right, and a preponderance of intermediate users in the center.
• “Although everybody spends some minimum time as a beginner, nobody remains in that state for long. That's because nobody likes to be a beginner, and it is never a goal. People don't like to be incompetent, and beginners—by definition—are incompetent.
• I think intermediate users are the only users that matter. The huge body of intermediate users is so dominant that you can and should ignore both beginner and expert users.
• Heidi Adkisson notes that features sell products, but the people buying those products often don't use the very features they bought the product for in the first place.
• That disparity is why it's so important to observe how users actually behave versus the way they tell you they behave.
• Observation is a powerful skill, and so is learning to disregard what people tell you in favor of judging them by their actions.
• People lie not because they're all evil liars (although a few inevitably will be), but because they're usually lying to themselves in some way.
• We must design for the way users actually behave.
• You don't get paid to program, you get paid to ship.
• One key measure of success for any programmer is how much code you've shipped.
• What users say they will do, and what they actually do, are often two very different things.
• You have to observe what users actually do. Don't ask—observe.
• As I've regrettably discovered in many, many years of using software, adding more features rarely results in better software.
• People are the source of, and solution to, all the problems you'll run into when building social software.
• This peer motivation stuff, call it gamification if you must, really works. That's why we do it. But these systems are like firearms: so powerful they're kind of dangerous if you don't know what you're doing. If you don't think deeply about what you're incentivizing, why you're incentivizing it, and the full ramifications of all emergent behaviors in your system, you may end up with… something darker.
• The internet is radically unlike all the telecommunications networks that have preceded it.
• Most programming books suck.
• There seems to be an inverse relationship between the size of a programming book and its quality. The bigger the book, somehow, the less useful information it will contain.
• A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.
• The best programming books are timeless. They transcend choice of language, IDE, or platform. They do not explain how, but why.
• But I do have this call to arms: my top five programming books every working programmer should own—and read.
• If you haven't read these books, what are you waiting for?
• Code Complete 2
• Don't Make Me Think
• Peopleware
• Pragmatic Programmer
• Facts and Fallacies
• Reading someone else's advice on the rather generic concept of helping yourself always struck me as a particularly misguided idea.
• 95 percent of self-help books are complete bullshit.
• Reading self-help advice from other people, however well-intentioned, is no substitute for getting your own damn work done.
• Get out there and do stuff because you fundamentally enjoy it and because it makes you better.
• Over time, quality does lead to success, but you have to be patient. Really patient. Turns out, "overnight" success takes years. Maybe even decades.
• Remember, nobody's going to help you … except science, and if you're willing to put in the required elbow grease each and every day—yourself.
• All true; no hacker today would bother with frontal assaults. The chance of success is miniscule. Instead, they target the soft, creamy underbelly of all companies: the users inside.
• Social engineering is the most reliable and evergreen hacking technique ever devised. It will outlive us all.
• If you want to engage in computer crime, don't waste your time developing ninja level hacking skills, because computers are not the weak point. People are.
• Nothing captures the continued absurdity of the human condition better than having a child does.
• The difference between a child who freaks out at the slightest breeze, and a child who can confidently navigate an unfamiliar world? The parents.
• If you ever need to deal with children aged 2 to 99, stop reading right now and go buy “How to Talk So Kids Will Listen and Listen So Kids Will Talk.”
• You can’t argue with kids, and you shouldn’t dismiss their complaints. The magic formula includes: listen, repeat what they say, label their emotions. The kids will figure out the solution themselves.
• I've learned to fall back whenever possible to simply describing things or situations instead of judging or pontificating.
• Turns out, children aren't the only ones who have trouble dealing with their emotions and learning to communicate.
• “The New Turing Omnibus” is is probably the single closest published equivalent to what I do on this very blog. It's a grab-bag of computing topics.