Learning from Effective Programming by Jeff Atwood

A small recap of what Jeff Atwood talks about.

Introduction

Programming is hard and you should only do it if it fills your life with joy. First you find a problem, then you try create a solution, then you learn how to code.

Being a good programmer requires technical skills and great communication skills. Being able to communicate your ideas is important for a project. 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.

The Art of Getting Shit Done

"This for that" type of incentives make creative processes suffer. Stack Overflow works because it's full of people in love with the subject.

Two great sources to "sharpen the saw" are programming reddit and Hacker News

If your goal is to have an excellent signal to noise ratio in a QandA site, you must suppress discussion. Building a community however is a completely different thing - Discourse

Go that way, really fast. If something gets in your way … turn. Speed of iteration, Boyd suggested, beats quality of iteration.

Multi-tasking kills productivity, this includes calls texting and even notifications from other projects. Perhaps the biggest problem of all, though, is that the majority of people doing the most media multitasking have a big-ass blind spot on just how much they suck at it.

Optimism is an occuplational hazard of programming. Most software developers are highly motivated by nature; the real art of managing programmers lies in knowing when to demotivate them.

Principles of Good Programming

The First Rule of Programming: It's Always Your Fault.

When your program doesn't work it's almost always your fault. Third-party software is not bug-free, but the problem is still probably in your own code. You should file a bug report only if you are 100% sure that it is not your code. You can do this by creating a minimal code example, which is also what the bug reports needs anyway. Do not be afraid of refacturing code - the third time is the charm.

The best code is no code at all.

Less code is better. A large codebase means more bugs and it needs more developers to maintain. The worst part is adding new features to a program - things will break. So keep your code concise.

Learn to read the source.

Documentation is great, but it can be misleading and just plain wrong (rare, but possible). So don't be afraid to dive into someone elses code, if you need to. It's hard, I know, but once you figure it out it can help others (in the open source world) and you might learn new tricks. So make sure the code you write is clear and concise.

Sometimes asking an inanimate object your question reveals the mistake you made, if not then you have a more throught through question to ask.

Ideas are worth nothing without execution. Execution quality rests on the team. So cultivate teams, not ideas. If you give a good idea to a mediocre group, they'll screw it up. If you give a mediocre idea to a good group, they'll fix it. Or they'll throw it away and come up with something else.

Try selling your idea to anyone