Let’s face it. Today’s tech industry work ethic revolves around tight deadlines, top notch output, and dedication to your users. This performance hat trick isn’t an easy thing to pull off. If you’re like me you rely heavily on caffeine and weekend sleep to keep on your game. And, while sleep may not be plentiful during the week, it’s even worse when it’s restless.

Here’s the thing, even if you only get 6 hours of sleep a night you’re still spending 25% of your day asleep. That’s a fourth of your daily life that’s spent in an unconscious state. So, if you’re going to spend that much time sleeping you might as well make it good.

The quickest action you can take to increase sleeping comfort is to aquire a new pillow. I’m not talking cheap, I’m talking a quality of pillow that Zeus himself would use. The type of pillow that makes you feel as if you’ve been placed in a bed of satin angora rabbits.

My personal choice is this monstrosity of comfort offered by Bed Bath and Beyond. It’s fluffy but also large enough to avoid constant readjustment. It’s nice to wrap your arms around or place directly under your neck. If you’re not into down pillows another option is the selection from Tempurpedic. A bit sci-fi for sure, but sturdy and made to fit your exact curvature.

Realistically, the pillow type doesn’t matter, what matters is that you sleep better. I know way too many people who just aren’t willing to drop $100 on a pillow. Trust me, it’s worth it. You’ll be more refreshed and less sore. Your actions day to day will reflect this. Don’t buy it? Ask around. I guarantee a few of your good friends have learned the lesson of crap pillows: being cheap on comfort just isn’t worth it.

For a long time here at Imulus we had trouble keeping track of internal company information. Client datasheets, software licenses, Imulus specific programming tips, bug tracking, email setup documentation, employee calendar links, etc. This problem was not something isolated to just us, every work environment I’ve been a part of has struggled with documenting and finding information. Generally the solution ends up being a massive repository of excel documents or a shared hard drive full of text files and snippets. Neither of these solutions are practical or scalable.

Our answer to this problem was an internal company wiki. Our goal was to have a central resource that was easy to update and easy to get information out of. It needed to be searchable, easy to edit, and secure. Being a .NET shop we decided to go with ScrewTurn a free open source wiki for .NET environments. A few other alternatives are: Wordpress plugins and hosted solutions such as pbwiki.

We’ve been using this solution since last August and it has been a huge time saver. Our project manager no longer gets flooded with requests for, “that spec requirement the client sent over,” and our programmer’s no longer have to use local text files to keep track of bugs in their code.

Here at Imulus we all use glass top studio desks. There are a few main reasons for this: sex appeal, weight, and office personality. However, there are also a few hidden benefits.

From time to time when brainstorming and talking out ideas we’ll simply pull out a whiteboard marker and start drawing right on the desk. Rather than getting distracted moving into the conference room and drawing on the whiteboard (which usually involves erasing it first) we’ll just get our ideas out right away. Plus then you get the added benefit of being right next to the computer and you don’t have to retrace your ideas onto a notebook.

Sure, this could be done using a sketchbook or a portable whiteboard, but we find it a nice add-on to the standard “desk setup” of today’s office.

Earlier today I was reading an A List Apart article titled Progressive Enhancements with CSS. The main idea behind it being that breaking out styles into a multitude of files is beneficial. For example, creating a typography.css for type styles, a layout.css for positioning styles, and a colors.css for colors and graphics. At face value this sounds great because abstraction, for the most part, works well on computers (utilizing folder hierarchy’s, categorizing types of media, tagging web articles, etc).

Fine and dandy. But there seems to be a real world problem.

There are three big reasons I see not to break out CSS into multiple files.

First, when you break out CSS into multiple files you are forced, no matter what to write a lot of duplicate code. For instance, if I want to have a certain container have a typeface, background, and color in a single main.css file I can do the following piece of code:

#element {
     position: relative;
     float: left;
     width: 20em;
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

However, if I break this out into: typography.css, layout.css, and colors.css files I have to do the following:

/* typography.css */

#element {
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

/* layout.css */

#element {
     position: relative;
     float: left;
     width: 20em;
}

/* color.css */

#element {
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
}

Okay, pretty easy to see that the amount of code being used favors having one central CSS file. Now, let’s talk about style management and the second argument I have for not using multiple CSS files.

A single CSS file for a website can grow to be quite a large file. Most I’ve written fall in the range of 1200 to 2000 lines. The problem with this is that making small changes can be a bit of a hassle. However, I would argue that the single best way around a complicated CSS file is to clearly comment code, use shorthand css, and make sure there is good style structure. I.E. Don’t go styling something in two different parts of the file and don’t write five lines of CSS when one will do.

But, in no way is the answer to break the CSS into multiple files. Why? Because the worst possible thing you can have to do is deal with the above problem three different times. Granted, if you only have to make a small color change than you only have to edit one file. But, if you use only one file to begin with then you only have to edit one file anyway.

Last, there’s a reason a site like digg loads in one 2500 line CSS file. The answer is that the less page requests the better. Doing multiple page requests to get different styles that are separated is inefficient. If a site gets a lot of traffic or a large traffic spike the less page requests the better. Granted, this may not be common but when it happens there’s nothing more important than trying to keep the site up.

Want more assurance?

Neither Dan Chederholm simplebits.com, Veerle Pieters veerle.duoh.com, or Jeff Zeldman zeldman.com use broken out CSS for type and color.

It has to say something when the big wigs in the bizz don’t follow the advice of A List Apart eh?

Exceptions?

As always, there are a few exceptions to this. For instance, if the website is like MTV.com and has a constantly changing color scheme then it could be useful to break out individual styles into a separate CSS file. One that overwrites the default styles of the base design and can be updated without disrupting the primary styling of the site. Also, microsites that have completely different layouts from their parent sites almost always deserve a new CSS file.

Conclusion

Basically there’s no need to break out your styles into a multitude of files. While the idea of abstraction might sound good the benefits just don’t add up. All you really end up with is a waste of time and resources.

Chances are if you’re a seasoned web developer at one time or another you’ve needed to insert Flash into a website but you have no idea what the dimensions of the movie are.

Previously there were basically three options for solving this problem:

1. Go directly to the person who created the flash and ask them the dimensions.
2. Open the .fla file in Flash (if you own a license) and get the document dimensions yourself. Chances are you’ll end up getting a cup of coffee at the same time because Flash takes so long to start up.
3. Shistily try to take a screen shot of the open Flash movie and measure the dimensions in Photoshop, usually ending up 1 or 2 pixels off and forcing you to go back to option one or two.

Or… browse to the .swf file in Finder and drag it into your TextMate file window. Wala! Now you have the flash insertion code right along with the exact dimensions of the movie. No more annoying hassles.