More on this book
Community
Kindle Notes & Highlights
“Not every programmer aspires to the same things in their career. But it's illuminating to consider what a programmer could accomplish in ten years, twenty years, or thirty years — perhaps even a lifetime.”
The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.
People spend their entire lives learning how to write effectively. It isn’t something you can fake. It isn’t something you can buy. You have to work at it. That’s exactly why people who are afraid they can’t write should be blogging.
I’m not sure if you have thought about this side effect or not, but Stack Overflow has taught me more about writing effectively than any class I’ve taken, book I’ve read, or any other experience I have had before.
I can think of no other medium where I can test my writing chops (by writing an answer), get immediate feedback on its quality (particularly when writing quality trumps technical correctness, such as subjective questions) and see other peoples’ attempts as well and how they compare with mine. Votes don’t lie and it gives me a good indicator of how well an email I might send out to future co-workers would be received or a business proposal I might write.
Everyone should write a lot — whether it’s a blog, a book, Stack Overflow answers, emails or whatever. Write, and take some care over it. Clarifying your communication helps you to clarify your own internal thought processes, in my experience. It’s amazing how much you find you don’t know when you try to explain something in detail to someone else. It can start a whole new process of discovery.
“Each day, you must rise with a restless enthusiasm. If you don’t, you are working.”
It turns out that traditional carrot-and-stick incentives are only useful for repetitive, mechanical tasks. The minute you have to do anything even slightly complex that requires even a little problem solving without a clear solution or rules — those incentives not only don’t work, they make things worse!
If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.
Kathy Sierra wrote a great post comparing multi-tasking and serial tasks and followed it up a year later with a typically insightful post proposing that multi-tasking makes us stupid:
The First Rule of Programming: It’s Always Your Fault
In coding, you have many dimensions in which you can rate code: Brevity of code Featurefulness Speed of execution Time spent coding Robustness Flexibility
Start with brevity. Increase the other dimensions as required by testing.
Jeff Atwood@codinghorror “”Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.”"
The value of my advice is debatable. But you would do well to heed the advice of Mr. Sivers and Mr. Catmull. If you want to be successful, stop worrying about the great ideas, and concentrate on cultivating great teams.
Software developers think their job is writing code. But it's not.* Their job is to solve the customer's problem.
every person on your team should be able to pass the "elevator test" with a stranger — to clearly explain what they're working on, and why anyone would care, within 60 seconds.
immediately. Without a coherent vision statement, it's appalling how many teams can't pass the elevator test — they can't explain what it is they're working on, or why it matters.
When a code addict needs a fix, they just do a few extra lines.”" 3:26
[Google found that] the page with 10 results took 0.4 seconds to generate. The page with 30 results took 0.9 seconds. Half a second delay caused a 20 percent drop in traffic. Half a second delay killed user satisfaction.
In A/B tests, [Amazon] tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.
“At Atari we hired based on hobbies and not grades in school. We ended up with he best engineering group in the world.”
After a fair bit of trial and error I've discovered that people who struggle to code don't just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.
