The software and web industry can learn a lot from the lumber industry, the oil business, and corn and soybean farmers. They take waste and turn it into hefty profits.

The lumber industry sells what used to be waste — sawdust, chips, and shredded wood — for a pretty profit. Today you’ll find these by-products in synthetic fireplace logs, concrete, ice strengtheners, mulch, particle board, fuel, livestock and pet bedding, winter road traction, weed killing and more.

Ultra refined petroleum finds its way into plastics, cosmetics, food, rubber, synthetic fiber, insecticides, fertilizers, heart valves, toothpaste, detergents, waxes… The list goes on.

Corn and soybeans are refined and processed into just about anything these days. By noon you’ve probably consumed a few pounds of corn energy without even knowing it. It’s hidden in your food in the form of HFCS, xanthin gum, dextrin, maltodextrin, MSG, or ethanol in your gas tank.

By-products

Everything listed above is a by-product. Lumber was originally cut for boards for building. Oil was originally drilled for fuel. Corn and soybeans were originally farmed for food. But today these industries have figured out how to use the waste to make even more products. They’re squeezing, pressurizing, refining, heating, cooling, and otherwise processing leftovers into money.

We’re lucky and not so lucky

In some ways, we’re lucky to be software people. We have easy jobs. We think, we type, we move the mouse around. We make stuff by putting pixels in the right place and words in the right order. Yeah, that’s pretty much what we do.

But that also makes it tough to spot our by-products. A lumber company sees their waste. They can’t ignore their sawdust. But we don’t see ours. Or we don’t even think that software development produces any by-products. That’s myopic.

When you make something you make something else

When you make something you make something else. Just like they say you can not not communicate, you can not not make something else. Everything has a by-product. Observant and creative entrepreneurs spot these by-products and see opportunities.

My parents old all-in-one printer just crapped out so it’s time for a new one. They asked me to make a recommendation. I’m like “Sure, no problem.” I figure I know enough about this stuff to check a few out and find the right one for them.

Turns out I’m an idiot. And so is everyone else who’s looking for a printer like this. Well, we’re not really idiots, but we sure feel like it. Buying a printer remains the last confusing part of modern computing.

Do I choose the MP620 or the PIXMA MP480 or the C4580 or the MX700 or the J6480 or the P2055, or the MFC-8460N or the SCX-4500W.

This weekend we pushed a couple of new features to Basecamp. One was long overdue (email notifications on Writeboards), and the other is a sign of things to come (working with Milestones on the Dashboard).

Milestones

When you log into Basecamp you are dropped onto the Dashboard. The Dashboard is information rich but functionally poor. There’s a lot to look at but not a lot to do. We want to change that.

The first thing we wanted to tackle was milestones. Milestones show up in a few places on the Dashboard, but mostly you’ll see them right at the top of the screen. They are either overdue or they’re due in the next 14 days.

Prior to this update, if you wanted to change the date or check off a milestone you had to click on the milestone. Then you’d be taken deep into the project so you could do your thing. That’s fine if you only have one thing to do, but if you want to complete a few milestones or move a couple back because the schedule changed it was a hassle. You had to move back and forth between project and Dashboard repeatedly. It was click consuming and frustrating.

No longer. Watch the video to see how we solved this problem:

This is the first step to “flattening” Basecamp. We want to bring more functionality to the Dashboard so you don’t have to click deep into a project to take care of common tasks. We’re exploring more ways to implement this technique in more places.

In a few weeks we’ll be welcoming Michael Berger to our team. Michael will be joining Sarah on customer service/support. We want to provide the best customer support in the business. Sarah has been kicking ass on her own, but it’s definitely time to add another person to the team. We’ve interviewed and tried a few other people, but we just haven’t found the right fit. Until now.

Turns out it’s a small world. Last year my mom went to an Apple Store in suburban Chicago to have an Apple Genius look at a problem with her laptop. She raved about the service and mentioned that the guy who helped her recognized her last name and asked her if she was my mom. Yup, that was her. And yup, that Apple Genius was Michael Berger.

Why Michael?

Michael has been working for Apple since 2004. He started as a Mac Specialist and was promoted to Genius in July of 2005. He was famous among co-workers and customers alike for providing “Bergercare” — beyond kick-ass customer support. Michael really cares about helping people. He’s built for it.

Fast forward to late 2008. Michael heard we were looking for another support person through some mutual friends. We interviewed him a few times, put him through a few weeks of part-time support work and basic training, and decided that he’s our guy.

We offered him the job last week and he accepted.

So everyone please welcome Michael Berger to the team!

I’ve been buried under a lot of work lately. I don’t know what happened, but in the last 10 days or so I feel like I’m working three jobs. Paperwork, administration work, design work, vision work, writing work, misc. work.

My desk is a mess. My desktop is full of icons. My inbox is overflowing. I have a list of people to get in touch with. I have what feels like a hundred decisions to make.

I’m not complaining, I’m just observing. And the primary observation that comes out of all this is that multitasking is the fastest way to mediocrity. Things suck when you don’t give them your full attention.

I’m not thrilled with the work I’ve been doing lately.

This isn’t a breakthrough, it’s just a reminder. If you want to do great work, focus on one thing at a time. Finish it and move on to the next thing. It means some things aren’t going to get done as fast as some people may want. It means some people aren’t going to get your full attention for a while. But doing a bunch of crappy work, or making a bunch of poorly considered decisions just to get through the pile isn’t worth it.

The hot article of the day is Why Your Startup Shouldn’t Copy 37signals or Fog Creek over at OnStartups.com.

I agree. And I’m sure Joel Spolsky agrees too. I think this comment on Hacker News nails it too.

Here’s the problem with copying: Copying skips understanding. Understanding is how you grow. You have to understand why something works or why something is how it is. When you copy it, you miss that. You just repurpose the last layer instead of understanding all the layers underneath.

The article is referring to ideas and business models, but I think interface design is an example more people can relate to. Have you seen an interface that was obviously copied from someone else’s interface? The copy usually lacks depth and detail. They miss the spacing, the proportions, the relationship between colors and objects and buttons and links. It’s usually pretty close, but there’s something not right about it.

Why? Shouldn’t copying something be easier than creating it? Someone else already did the work, right? The problem is that the work on the original is invisible. The copier doesn’t know why it looks the way it looks or feels the way it feels or reads the way it reads. The copied interface is a faux finish.

This is why future iterations of a copied interface begin to break down quickly. The copiers don’t understand where to take it next because they don’t understand the original intention. They don’t know the original moves so they don’t understand the next move.

Look around at interfaces that were clearly copied from someone else’s UI and you’ll find a lot of inconsistencies and sore thumbs. That’s the new stuff.

While I’ve been using interface design as an example, the original article was more about business models. I think copying leads to a lack of understanding there as well. Be influenced by many, copy none.

So bottom line: Copying hurts you. You miss out on what makes something good. Instead, try to be exposed to a variety of perspectives and points of view. Take whatever you find useful and leave the rest behind. Fill in the gaps with your own ideas. In the end you have make your own way forward.

Today is a very significant day in the life of 37signals and Basecamp (and, indirectly, Ruby on Rails). Today Basecamp turns five years old.

We launched Basecamp with a post right here on Signal vs. Noise on February 4, 2004. No traditional PR blitz, no advertising, no real expectations of big success. Just a product and a post and “let’s see what happens.”

Basecamp was a side project. We were a web design firm at the time. We built Basecamp because our projects and client communications were a mess. We were using email to update our clients. That works for about 5 minutes, then goes from ripe to rotten pretty quicky.

We looked around at some of the industry standard project management tools at the time. The leader was Microsoft Project. We didn’t get it. Projects aren’t about charts, graphs, stats, and reports. Projects aren’t broadcasts. Projects are about people and communication and collaboration. Projects are about back-and-forth, give and take.

Collaboration, not management

We also didn’t really like the idea of “management.” Management is hard work. Management is administrative. Management gets in the way. Collaboration better described what we were after.

So after experimenting with a manually updated blog-like project site, we decided to build our own tool. At the time, 37signals was just myself, Matt, and Ryan. Three designers. We weren’t programmers, so I hired a student from Denmark who I met over the web to write the code. I’d hired this guy before to write some PHP for a client project. I was happy with his work. We saw things the same way. This guy was was David Heinemeier Hansson. You know the rest of that story.