The past Tuesday night while at the Boulder New Tech Meetup I was introduced to Sarah Lacy, a reporter for BusinessWeek and co-host for Tech Ticker on Yahoo! Finance. Sarah just released a book called “Once You’re Lucky, Twice You’re Good: The Rebirth of Silicon Valley and the Rise of Web 2.0.” Her presentation was largely about who she is, what her book is about and how she hoped to talk to “interesting entrepreneurs” after the Meetup.

Once the Meetup ended and everyone went home, Stacy started ripping into Boulder’s entrepreneurial spirit on her blog.

Root Root for the Home Team from sarah lacy on Vimeo.

I’m an entrepreneur and I’ve never heard of Sarah Lacy before. I opt for Inc, and WIRED over BusinessWeek. I don’t give a rats-ass about Yahoo! Finance. I, like many other Front Range entrepreneurs enhance my knowledge via blogs, podcasts, Twitter postings and local powwows like the Boulder Tech Meetup.

I believe it’s a mistake to compare Silicon Valley to the Front Range, but inevitable people do it. Sure we have similarities. There are many ex-Californians who’ve migrated to the Front Range, we have a ton of VCs and in general we are a young tech-minded group of people.

We’re Different!
For us (Imulus) it’s about building something of quality, it’s about lifestyle, it’s about building a company that doesn’t want to be sold to a bunch of soulless shareholders. We don’t have an “exit strategy” we don’t “measure success by revenue” and we don’t sit behind a desk for 60+ hours a week. I disagree with Sarah’s premise that “people in Boulder are trying to create global companies.” Why does a company have to be global? There certainly isn’t a damn thing wrong with becoming a national success or even a regional one, if that is the goal the founders seek to achieve.

My recollection of the Silicon Valley boom days wasn’t so glamorous. I remember considering a job in the Valley which would earn me a starting salary of $75k per year, plus shares in the company. This in exchange for working 60+ hours a week. Not to mention I’d be living in a dump of an apartment by the time I returned home from work.

Sarah, I’m sorry that you didn’t get the Tweetup turn-out of Los Angeles or London when you visited Boulder. Like Matt Galligan mentioned, Kevin Rose only had 20 to 30 people show up to his Tweetup.

I’m not saying we’re perfect though. The local community can do much more to share ideas. I think the hunger for community-building is evidenced by the awesome turn out of the Tech Meetup.

Don’t discount us, we’re not the Valley. We’re the Front Range and we’ll be making our difference known over the next few years.

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.

We use a few of GoDaddy’s services, and every-time I login to GoDaddy to make an update I feel as though I’m entering a carnival…. playing circus music.

Today I logged in and immediately noticed something different… more black… more people… more flashing content…. huh? Yeah, they redesigned it.

Stunner! Did their internal IT team design this one?

I never thought I would say this, but the original site was better then the redesign. The homepage layout is atrocious and makes me work far too hard. I see boxes flashing and changing, type screaming at me and a 10+ different services to choose from.

Let’s play a game. How many typefaces / treatments can you find? I count 17.

How much pricing information can be fit into 430 x 360 pixels?

The site reads like a bad combination of used car dealer, pawn shop and thrift store.

Nothing like consolidating navigation options

OK… perhaps I’m being too harsh, but I don’t think so. Let’s just say GoDaddy’s target market are those people who have never purchased a domain in the past. These users are likely less technically savvy and somewhat unfamiliar with the more technical side of the Web. Therefore wouldn’t it make sense to simplify the layout…. to offer less options… to streamline the process?

On another note, what does NASCAR Racing and GoDaddy have in common? Other then the car they sponsor I’m really unsure as to why they have selected to market themselves using race car drivers.

Danica... when was the last time you registered a domain name?

I just don’t get it. I’d love to hear GoDaddy speak about the rationale behind this redesign and how their changes have made GoDaddy more useful to the average user.

Tonight Jason Fried from 37signals spoke at the Oriental Theater in east Denver. He discussed everything from client deliverables to the 37signals four-day workweek. In essence, Jason’s talk boiled down to three key points:

1. Don’t work on hard problems. Break them down and keep things simple.
2. Avoid distractions (open office environments, meetings, e-mail, etc.) get a site or product out of your head and into production ASAP.
3. Deliverables are bullshit, clients don’t care, the end product is what matters.

First off, I want to say I have great respect for 37signals and their impact on the industry. Having the chance to talk with Jason about issues such as: stopping IE6 support, disregarding Photoshop in the design process, and scaling with growth, was an absolute treat. Clearly the team at 37signals is one of the most innovative and talented in the industry.

However, I think 37signals dominance in the web products field has distorted their ability to critique the client-based approach. And while I don’t have knowledge to speculate specifically on day to day client interaction, I do have a few things to offer from a developer perspective.

Team chemistry is important.

First, people working from home all the time can be harmful to the group chemistry. Jason and team do a huge amount of work via telecommuting. Relying on campfire, screen sharing, and video chat interactions for the bulk of their communication. They feel this helps minimize distractions and keep people productive.

I’m not sold this is the way to go. I think it’s hard to truly feel connected and dedicated to your team if you don’t spend real time with them. When’s the last time you became really good friends with someone without spending some serious face-to-face time with them? For me it’s never happened, not once. And as great as chatting online is, it’s not the same as being in the same room and hashing things out. You miss the subtle face gestures, the inside jokes, the bantering, and the all around comradery that happens in the workplace. Part of the reason Imulus does great work is because we have dedication to one another. Even on days when I’m completely out of wack mentally I still find myself focused on helping the team. Why? Because I’m relied on to help create the great stuff we build. And I trust those I work with to do the same. As ridiculous as our office gets sometimes in the end we get shit done and we do it for each other and ourselves.

Deliverables have a purpose, it just needs to be refined sometimes.

Second, I don’t buy that all deliverables are bullshit. Just as some companies like to skip Photoshop (37signals) and go straight to coding, and others (Apple) like to make mockups pixel perfect it’s impossible to say that one solution is better than the other. Yet, we can agree that certain processes work better for certain people as well as certain projects.

Let’s talk about the way we work. Imulus’ basic approach is to offer the client a timeline, design brief, wire frame, and mockup of the final interface. Now, it’s important to realize that we haven’t always done it this way. In fact, for some time before I came to Imulus the wireframe process was basically nixed. What was the result? Instead of 5 hours spent reworking things in the wire frame process, 25 hours was spent reworking things in the development process. Look, we aren’t naïve, we recognize that clients change their mind and get new ideas all the time. However, we’ve found that most of this re-thinking takes place in the wire frame stage. And therefore we save hours of coding changes by altering the approach up front. In essence, if you’re building a car and the frame is faulty, why wait until the upholstery’s getting put on the seats to fix it?

Still, we know it’s a strong possibility that some of our deliverables are blown out of proportion. And as most firms do we will continue to collaborate and narrow down our inefficiencies. However, we have found that some deliverables are an extremely important step, and just because some projects or companies don’t require them doesn’t mean they aren’t important.

In conclusion

Clearly 37signals has clout and track record to support the way they work. And regardless of how that alters the Imulus process we love hearing about it. It’s phenomenal that they have so much passion behind what they do. I hope over time we can refine our own process to the point they have. Until then it’s great hearing a second opinion about things.

Last Thursday we had several hours of straight interviews, all but one of them were outstanding candidates. The first round of interviews for us is a “get to know” session. In 1 hour we have to get at the essence of the person. We actually put a good chunk into the person’s “blink factor.” If we aren’t feeling just a little bit of love in the first 2 minutes, then the candidate is going into an uphill battle.

After the “blink factor” we really want to know the person. How did they come into their career choice? What are they passionate about? Are they multi-dimensional? Are they a ridged or free-thinker? etc… Then we start analyzing the skill and experience level. Resumes don’t amount to much; just because a candidate lists every single program they’ve worked on doesn’t mean they are qualified for the job. Likewise a track-record of short job stints doesn’t mean they hop from company to company. In fact, one of the candidates in the last round of interviews didn’t list a job which lasted longer then 1 year. However, during the interview it became clear this candidate was very passionate about his line of work and the stints were not by choice but by circumstance.

The next part of the evaluation is the 4 staple questions which apply to everyone we hire at Imulus:
1. How do you rate your organization skills?
2. From 1 to 10, where are you with your writing skills and can we see samples?
3. Do you like formal meetings or ad-hoc gatherings?
4. How do you like to be managed?

Sure, they can lie their way through these questions but if they make it back to the second interview then the WHOLE OFFICE will have a shot at uncovering the real truth. At that point someone will smell bullshit. Anyone at Imulus has veto power, it needs to be a unanimous decision.

The last part of the evaluation is asking the question, is this person the best fit for the job? I would have hired several candidates if we were looking for an mid-level .NET person or Web developer, but we are looking for senior level experience. With just interviews and references to go off of it’s often tough to gauge how the candidate will respond to a real-working environment with our office dynamics, workload and management style. This is the part of the interview where I believe you have to trust your gut. I’m a big believer in quantifying data and looking at things scientifically but sometimes that feeling in the pit of your stomach is often the best judge of a situation.

I’ll guess you’ll see shortly who we’ve decided on.