Effective Programming: More Than Writing Code

by Jeff Atwood

It is our stated goal as a company to live in harmony with the web, by only doing things that we believe make the internet better, at least in some small way.

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be.

with brevity. Increase the other dimensions as required by testing.

the code already tells us how it works; we need the comments to tell us why it works. Code

Creating a product vision statement helps teams remain focused on the critical aspects of the product, even when details are changing rapidly.

you should always favor fast websites.

The opportunity cost for switching on the public internet is effectively nil, and whatever it is that you’re looking for, there are multiple websites that offer a similar experience. So how do you distinguish yourself? You start by being, above all else, fast.

Sexist!

I find that cultural fit is often a stronger predictor of success than mad programming chops.

stuff.” You shouldn’t be treated to an uncomfortable silence after asking a candidate what 2^16 is; it’s a special number.

“why do programmers think Oct 31 and Dec 25 are the same day?”

That company no longer focuses its recruitment on candidates that exactly match previous experience with the required technologies. Instead they focus on finding and employing the smartest and most passionate engineers.

Somehow, they’ve forgotten that what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language

do you really want to work for a company that still doggedly pursues the years of experience myth in their hiring practices?

Requiring X years of experience on platform Y in your job posting is, well, ignorant. As long as applicants have 6 months to a year of experience, consider it a moot point for comparison.

Platform experience is merely a baseline, not a differentiator of real importance.

The higher their requirements for years of service in a given technology, the more likely that they’re looking for all the wrong things in their applicants, and thus likely that the rest of the team will be stooges picked for the wrong reasons.

Usually the things that make or break a project are process and people

At the point which you, or anyone else on your team, are using words like cancer to describe a teammate, you have a serious project pathology.

“My code is too complicated to test.”

the worst team member is the best predictor of how any team performs.

Time spent staring at a progress bar is wasted time.

This is all your app is: a collection of tiny details.

If you don’t obsess over all those details, if you think it’s OK to concentrate on the “important” parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis — you’re not creating great software. Someone else is.

once you have thousands of items to paginate, who the heck is visiting page 964 of 3810? What’s the point of paginating so much information when there’s a hard practical limit on how many items a human being can view and process in any reasonable amount of time?

Once you have thousands of items, you don’t have a pagination problem. You have a search and filtering problem.

In a perfect world, every search would result in a page with a single item: exactly the t...

you should strive to make pagination irrelevant because the user never has to look at more than a few items to find what they need.

Since it is often the user who notices a defect, it also doesn’t matter whether something is a bug or a feature according to the developer.

Limiting the number of login attempts per user is security 101. If

wrong. You must prototype the requirements quickly and show users something concrete to find out what they really need.

You will tend to overestimate the value of items you get for free.