Bootstrapping by Contracting

For my new company, JustGolf, we opted to try to bootstrap some of our initial development by taking on a contract app development job. I would not call this a mistake, but it did have an unforeseen challenge that you should be aware of if you decide to bootstrap in this way. That challenge is avoiding the urge to get emotionally involved in the project.

When doing contract work, you must do your best work. You owe it to your client and your reputation depends on it. That sometimes means adding, or at least suggesting, the addition of features (large and small) outside the original statement of work — especially if it is clear that the lack of those features jeopardizes the potential success of the project. That said, if the project is a means to an end, the line has to be drawn somewhere.

Building Someone Else's Dream

The guys we contracted for were a couple of guys a lot like us: two guys with a dream and the motivation to make it happen. They wanted to build an Open Face Chinese Poker app, but weren't developers themselves; they're professional poker players. Because they were kindred spirits (not to mention nice guys), they were a lot of fun to work with.

In meetings with them, it was easy to get caught up in the excitement of their building a business. After all, they were doing the same things we were: setting up a Twitter account, a Facebook page, and a blog and starting to get some traffic. We helped them research their competition and brainstorm about how to position themselves against it. In development, we continued to add little features that we thought would make the app better.

This was all well and good until it dawned on us that we were building someone else's dream. One of the reasons that we left corporate jobs behind was to build our company, not someone else's. Here we were, back to working for someone else. We had let ourselves become emotionally attached to their company and separating from that was hard. It was time to get on with building our company and our first app. The mantra became "Get it done."

If you're considering bootstrapping a startup by contracting, let this be a cautionary tale. Know what you're getting into and keep some emotional distance. Otherwise, you may wake up one day and wonder why you never got around to building your killer company.

Bozo Filter

Whoa! Time to dust off this blog a bit. To that end, a quick story from my now-previous job that dovetails well with my last post.

At Appconomy, we used See[Mike]Code to do technical phone screens. One or two developers would jump on a call and have the candidate write a couple of simple functions in the programming language of their choice. These were bozo filter kinds of coding questions, nothing complicated. Ideally, the process would take 10-15 minutes, including the initial pleasantries. We just wanted to make sure the candidate actually writes code before we would bring them in. We did this as a last screen before bringing someone in for an onsite interview -- after screening resumes and having our HR Director do her phone screen.

One afternoon, our HR Director stopped me and a colleague (coincidentally his name is Mike) in the hall. She said somewhat meekly, "I just had a candidate decline to do your coding test. He said, 'I cannot condone that kind of interview practice.'". Mike and I looked at one another quizzically and then he turned back to her. "Perfect, it's working better than we ever imagined."

I don't know what this person's real objection was, but if you are interviewing for a programming job, there are no valid reasons to object to writing a small amount of code as a part of the process. With few exceptions (e.g., your name is DHH), there is no reason to object to a bozo-filter. Just remember, if you're good enough to get hired (and if you're objecting, you must think you're a lock to be hired), you will eventually be the one who's doing interviews when you could be coding. When that day comes, you will appreciate having a good, fast filter in place.

Is Interviewing a Burden?

Jason wrote a nice post today about startup hiring. Hiring in startups is different from hiring in bigger corporations because the stakes are so much higher. A bad hire at a startup can crush employee morale, sap valuable time and energy, and in the worst case, kill your company. None of Jason's thoughts were new to me, having worked for and/or with Jason for almost 5 years. Even so, it was worth the read.

There was a comment that struck me as missing the mark. Anonymous wrote:

Good people also don't have time to take tests, or really don't care. Every job I've applied for I get an offer 90% of the time.
...
At the end of the day, having all these filters and questionnaires will deter the "good" people.

If you're getting an offer 90% of the time you apply and you still feel burdened by personality tests and 3-question questionnaires (as in Jason's example), you must be casting your net too broad. Here's an alternative:

Figure out where you want to work. If you want to work for a startup, follow the startup blogs, twitter feeds, whatever comes after twitter, for companies in your area. Get a sense for the various company cultures. Eliminate from consideration any company that you know would not be a culture fit for you. Good. Now you have a short list. Keep it up to date even as you're happily employed at your current job.

When your current job comes to an end, pull out your list and figure out who's hiring (if they're following Jason's advice, they all are). Apply. During the application process, determine if the company is still a place you want to work. Do the things that the company is asking of you as an applicant unless and until it becomes obvious that the job, not the application process, is incompatible with your personality, ambitions, etc. Because you have a short list and a high offer rate, you don't have to apply to that many jobs, so whatever the load for any given job, as long as it's not completely out of line, the total load just is not that high. If a company is out of line in their requirements, then it's probably not a good fit anyway.

Notice how this meshes well with Jason's advice for hiring. Boiled down, he says companies should have a public persona that is both desirable and honest. Seek to hire strong candidates when they are looking for a job. As a candidate, I say, find desirable companies when you're not looking for a job. When you're ready go talk to those companies. If you're getting offers from 90% of places you apply, you only need to apply to a couple of places to land your next gig.

Muddled Thinkers Need Not Apply

Lately, I've been doing a fair amount of interviewing (as an interviewer, not a candidate) and have a few thoughts on passing my interview. Yes, that's right, I'm going to give you some advice that just might get you hired by my company.^* Here's the best piece of advice I can give you. When asked a question, compose yourself and think clearly about the question before answering. The number one reason I ding people in interviews is because I perceive them to be muddled thinkers.

Muddled thinkers confuse customers when they give unclear answers to tech support questions. Muddled thinkers write muddled code, with comments that are equally incomprehensible. And muddled thinkers have a hard time learning new things, because they don't have a structure or system for applying that new knowledge. This leads to something my friend Duncan calls "programming by accident". Keep randomly permuting the code until it seems to work and then stop. This approach creates bugs and unmaintainable code. If it's your strategy for solving problems, I don't want you on my team.

A specific muddled thinking antipattern we see a lot involves the naming of temporary variables. If I ask you to write code and you need a temporary variable to solve the problem, stop and think clearly about the purpose of that variable. If you name the variable t in an attempt to finish as quickly as possible, you are well on the way to failing your interview. I won't fail you just because you chose a poor variable name, but I will fail you because your failure to choose a good variable name confused you to the point that your solution was incomplete, didn't solve the problem, or you begin randomly permuting your code in hopes that "if I just change this to that, it should work." That smells too much like programming by accident.

Think you have what it takes? Want to work at a growing (yup, even in these economic circumstances) startup? Want to work on a product that makes a difference in other programmers' lives? Smart Bear is hiring software developers and senior QA engineers. Send us a resumé. jobs@smartbear.com.

* Remember when you're in an interview, the interviewer wants you to succeed just as much as you do. We don't do interviews for fun; we do interviews so we can get more people to help with our real work. Ironically, the backlog of real work gets longer the more interviews we do.

Learning Scala

Taking a page from the Pragmatic Programmer, I'm going to try to learn Scala this year in my spare time. Yes, it's a large undertaking, especially since I don't have a lot of spare time these days, but I think it will be worth the effort. Maybe some day I'll get to use it in my day job, but even if not, it will force me to learn new things, to think new ways, and to grow as a programmer. As an added bonus, it will give me something to blog about.

Why Scala? I was actually heading down the Clojure route and was really enjoying the way it was tickling memories of Scheme. So, today I instant messaged my friend Rob who is a programming language geek of the first order and a fan of Scheme. I asked him if he had taken a look at Clojure and he had not. He pointed me in the direction of Scala. Not being married to Clojure, I decided to switch my focus. With Scala, I have two extra resources to help me learn: a published book (sorry Clojure, missed me by a couple of days) and Rob. Maybe I'll spare some cycles to play with Clojure too — or maybe I'll save it until next year.

void main*

My boss, Jason Cohen, recently blogged about how it is imperative to join the social media "revolution" — even if it's not clear what that means. I see his point, and while I do blog occasionally at the Smart Bear Company Blog^†, I think it's important for me to build up my personal social media juice. After all, I won't be at Smart Bear forever, and whatever I do next, a little Google karma won't hurt.

I will try to keep this blog on the topics of software development, technology, and startups. That said, I know that blogs can sometimes take on a life of their own. Hopefully, it won't wither away to nothing.

^* The title of this blog entry is me resisting the temptation to title it "Hello World". As for "Noop in a Loop", that came from a discussion of measuring CPU clock speeds.

^† As long as I'm employed at Smart Bear, most of my posts will be crossposted to the Smart Bear blog. I apologize in advance to anyone who reads both blogs.