Cheezburger recently turned 5 years old!  Hooray for us!  Who would have ever thought that a silly web site about cats could transform into the leading destination for online humor?!

Sadly, after 5 years, Cheezburger, and the entire Internet, are facing the most serious thread of censorship that has ever existed in the United States: SOPA.

In protest, Cheezburger will protest SOPA legislation with a “blackout” on January 18th.  From Geekwire:

All Cheezburger sites will also be instituting a blackout on January 18th to protest SOPA and PIPA. Now, go ask Wikipedia to do it,” Huh said in a Tweet on Thursday. Wikipedia creator Jimmy Wales said he’s considering taking the popular online encyclopedia offline in protest of the legislation, a black-out being led by Reddit which noted in a blog post this week that “there are powerful forces trying to censor the Internet.

SOPA would enable the government to shut down websites based on the simple accusation of a copyright violation.  No due process.  No day in court.  Just a claim and…poof…you’re done!

…Goodbye Cheezburger
…Goodbye Google
…Goodbye Facebook
…Goodbye Internet

Of course, those sites won’t really shut down.  What will really happen is simple thuggery: major corporations with deep pockets will threaten a company like Facebook with a SOPA claim, but…through the graciousness of their good hearts…agree to withhold their claims for a modest fee.

I believe the mafia calls that “protection money”.

Just another step on the path to the Banana States of America.

Have you contacted your Senator?  If not, do it now…here’s a list of phone numbers.

At Cheezburger today we took some time to reflect on how we’ve done the last few months using a technique called, “Mad, Sad, Glad”. Each person took a few sticky notes to express how they thought things had been going.

Turns out this is a great way to harvest success and surface impediments.

Recently, someone asked me my views on this article which reaches these conclusions based on analysis of StackOverflow reputation data:

Number of coders drops significantly with age. Top developer numbers, at age 27, drop by half every 6-7 years.

Developers in their 40′s answer roughly twice as much and ask half the questions compared to colleagues in their 20′s. It seems younger generation learns and older generation teaches.

Quality of posts, i.e. upvotes earned by post, only slightly increases with age.

Senior [developers] earn their high reputation by being more active than younger developers.

Here’s my analysis…

The junior developers ask more questions. This means they know less (which is why they ask). As a result, this means it takes them longer to figure out how to do stuff. Plus, if it’s a question unique to our own software, then they have to ask someone internally which means they’re taking another person’s time. And, they need more oversight and management to ensure that they’re doing it right. And, since they require more oversight that means more overhead. All of this adds up to a higher cost structure for the company.

Bottom line: the longer and longer I am in this business the more and more and more I value finding really good, experienced developers and not being afraid to pay for them. (Both in terms of actual salary and other benefits…make it a place they want to work forever, and so that we can get the maximum amortization from the training and investment we put into them.)

Not only are they more productive because they know how to do more, they work more independently thus requiring less management overhead, and since they have more work experience, they have less of the insecurities of younger employees (which just requires more management).

P.S. Shameless Plug: I am recruiting developers for my team at Cheezburger. Just because I raised the bar high in this post, doesn’t mean you shouldn’t check out our job postings at http://jobs.cheezburger.com/. As I said, we pay well and have an amazing work environment.

Based on my post, Cheezburger Network Doesn’t Show Its New Employees the Bathroom Until They’ve Checked In Code.

Ring the bell!  We finally hit the big time, kids!

Click here to view the embedded video.

Last week I was interviewed on the weekly TechFlash podcast about what’s going on behind the scenes with Cheezburger.  I gave an update on our progress, and strategy going forward…in short, I explained what we’re gonna do with that $30 million.  Click here to listen.

What do your new employees do on their first day?

Fill out paperwork?  Collect up office supplies?  Fiddle around with the customizations on their computer?

At Cheezburger, our new developers write and commit code to our production software on Day One.  Yes, you heard that right…we throw a newbie into the fire before they even have time to know what hit them.

I would strongly encourage you to aim for this goal with your new employees on Day One.  The result will be happier, more empowered employees with an attitude of ownership and a focus on productivity.

Even if you don’t work with developers, you can find ways for your team members in other departments—marketing, sales, finance, operations, etc.—to contribute on their first day.  For example, for marketing it could be to identify an improvement to the copy on the site or run a new SEM campaign. For sales or customer service, it might be hopping on the phone with an actual customer.

To illustrate, let me explain to you what we do with our new developers at Cheezburger. Given that there are only eight hours on the first day, and the developer does, in fact, have some paperwork to fill out, that means there are a few puzzle pieces you need to have in place to prevent this from being a complete disaster.

1.  Start with a small, specific task that you want the developer to complete, such as a minor bug fix or a simple code change.

For example, our most recent developer fixed a bug where if a customer attempted to use a password that was too short the error message was unclear.  From a technical skills perspective, this basically meant adding a new test (to catch the bug) and a new case to a switch statement (to fix the bug).

Let’s be clear: the point of the exercise is not to have someone show you their amazing coding chops.  The point of the exercise is for them to learn the process for getting code from their keyboard into our software.  It’s simply impossible for a developer to be productive member of your team if they don’t know that process, so that’s what we teach them first.

2.  Have a well-documented procedure so that the developer can install a development environment on their workstation.

When our developers arrive on their first day, sitting on their desk is a brand new computer.  We have already setup all the accounts to all of our systems that they are going to need.  And, in their e-mail is the licence keys for any software that they are going to use.  In other words, there is nothing blocking them from getting started.

Next, we provide them a document with a 17-step process for transforming their machine into a development environment.  This includes steps for installing software they will need to develop on our code base, for fetching our code from source control, and, finally, for building and running the code on their machine.  All in all, it takes about 90 minutes to get up and running (which includes installing an IDE and database server).

In addition to the installation guide, we have also developed a few essential pieces of bootstrapping software to accelerate the install process.  One piece sets up and manages the database schema automatically, and the other manages application configurations from machine to machine.

Now, don’t think this comes for free.  We have invested in the creation of this process because it has more benefits than just setting up workstations.  When we need to build a new machine, we have the steps documented.  Or, heaven forbid, in the event of disaster recovery, we have the steps to be back up and running.

3.  Assign a mentor.

Even the best developers are not going to figure out how to follow your process and fix that bug on their own.  It’s just impossible.  On Day One, a new employee is still trying to figure out the location of the bathroom, for goodness sake!

So, we assign them a mentor to coach them through the day.  And, we don’t just say, “Oh, you can ask so-and-so if you have any questions.”  No…I take another developer and have him sit with the new employee, side-by-side, at the new guy’s desk, for the entire day helping him through the process.

Most companies don’t want to waste a second of developer time…they want developers pounding out code.  Yet, we’re “wasting” an entire day of developer time, so that we can get a second developer up to speed much faster.  In my view, that’s not waste because ROI on that day is spectacular!

In sum, the net result is that by late afternoon on a developer’s first day at Cheezburger they have been genuinely productive and are fired up to come back on Day Two for more!

—-

The inspiration for this post was that we had a developer start just last week, and he was thrilled to be productive on his first day.  That led to a conversation [via instant messenger] between myself and the three most recent developer hires at Cheezburger.  Here’s what they had to say about Day One at Cheezburger:

Me: So…how does it *feel* to commit on your first day?

John: Good.

Eli: Scary, and very good!

Me: Could you elaborate on that? Why did it feel good? Why scary?

Eli: At [my last company name], it takes at least a week to even get your box. At Cheezburger, you can feel productive immediately. It’s a little scary being so new and pushing something out to production to quickly, I didn’t want to make a mistake. But it’s awesome to have a system where you can push out so quickly.

John: Well put. Ditto.

Me: So, why was it awesome to do that? There’s something about that which feels….????

Eli: Empowering is a good term. I’d also say that there is a greater sense of ownership at Cheezburger.  At [my last company] there were several layers between the developer and production.

John: After coming from a big mega-corp with 6 degrees of separation between devs and the production environment, it was very empowering to be able to push the button without having to collect 12 different signatures or part seas.

James: At my last job, I spent 2 weeks trying to build a working dev environment.  It was so frustrating, and most amazingly (as I was just telling John and Eli) nobody was willing to help me.

Me: Wow!  That would make me want to quit.

James: I very seriously considered quitting in the first two weeks. It was a complete waste of my time. It was hard.

Eli: When new guys came into [my last company], you didn’t want to help them build their box because box building was excruciating. It’s better to hope the new guy figured it out from the out-dated documentation that you do have.

I’ll let you be the judge, but it sounds like developers enjoy being productive on their first day.  And, in my experience, happy developers are productive developers, so the efforts we make for Day One at Cheezburger are well worth it.

UPDATE: Based on the comments, some readers have interpreted the title of this post to mean that we actually withhold the location of the bathroom from new developers until they commit code.  Ha!  That would be funny…not.

We show everyone the bathroom…both, in fact, because we have two.  The title of this post was meant as a humorous way to illustrate the importance we place on getting people up and running.

If you read the post carefully, I never say anything about not showing new people where the bathroom is located.  I’m sorry if I caused confusion.

My friend Rob, who makes wonderful baby gifts, posted this on Facebook today.

If you’d like some background on what we do at Cheezburger, you can read the full article here.

If you’d like to see my favorite LOLs and FAILs, you can take a look at them here.

And, if you haven’t subscribed to my blog already, then you should…just click here to sign up.  It’s free, saves time, and takes only seconds to sign up.

So?  What are you waiting for?

I regularly receive questions from readers about my experience working on the web, at Cheezburger, and so forth.  I enjoy it when people reach out to me, which is why I make all of my contact information—including my phone number—available on my contact page.

If you have a question for me, on- or off-topic, please don’t hesitate to send me a note.  (I’m even thinking that I might make it a regular feature of my blog to answer reader questions, so if you have them, fire away!)

Recently, I received an e-mail from Jackie in New York who asked a question that I am asked often, although in many different forms.  I thought I would respond to it here for everyone.  Jackie asked:

I’m looking for…advice and a little more information on how you got started…how did the success of Fail Blog and Cheezburger come to be what it is today?

The answer to that question has three parts.

First, and foremost, we have been relentless about focusing on great content, and the way we assessed great was by listening to what our users like: by monitoring what got lots of comments, what was shared via social networks, etc.  Every piece of content we post is an opportunity to learn what makes the audience laugh…or not…so we can refine what we publish.

Second, as a business, we haven’t had the luxury of lots of cash in the bank, so we’ve been religious about focusing our resources on the activites that really make a difference to the bottom line, and accepting imperfection in the areas that don’t.  This applies to everything from the features on our web sites to our technical infrastructure to our office and work environment.

And, third, no business is successful with out a little bit of luck, or at least some wind at their backs.  In our case, we have been given a great gift: funny content—the stuff in which we trade—is the type of thing which people like to share with their friends.  As a result, we get a great boost from word-of-mouth which, quite frankly, is the single most effective means of marketing.

So, in sum, if you want to follow the Cheezburger and Failblog model for success, here’s how you do it: focus relentlessly on your core competency, manage your business (which is different than your product) well, and find ways to generate great word-of-mouth marketing.

Yesterday’s post on being more productive in the morning reminded me of Paul Graham’s essay regarding manager versus maker time.

Paul’s simple point is that “doing work” requires a different type of mindset and workflow than “managing other people doing work”.  Most programmers completely agree, so I encourage you to read his essay.

One of the points that complete resonates with me is:

…there’s [a] way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

I couldn’t possibly agree with this more.  I feel like in order to be maximally productive, I have to have at least a 3-hour chunk of completely uninterrupted time.   And, sometimes that doesn’t even work…as Graham writes:

…one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

Yes!  Absolutely!

Rereading Graham’s essay is going to cause me to be more careful about scheduling meetings at Cheezburger.

Right now, we only have two types of meetings: an all-team meeting at Monday morning, and several daily standups for smaller project teams.  Typically, those meetings are all held in the morning, and I’m going to work to keep them that way…perhaps designating the afternoon as “maker time”.  Although, that is incongruent with the whole “morning people are more productive” idea, so maybe the key is to move the meetings earlier in the morning.

I’m not sure…what are your thoughts on this?