Your Startup Sucks

A Moment for Reflection

Wed, 04 Jan 2012 20:53:00 -0500

When I started this blog two years ago, I set out to capture a side of the tech world that I felt was being overlooked: the people behind the scenes — and the sense of community that binds them together.

“Your Startup Sucks”, though silly, was imagined as a good guy’s travelog — a personal narrative probing the winding corridors of NYC’s business world. Its thesis was simple: dogs may eat dogs elsewhere but in NYC, we help each other out. That’s what makes us special. That’s what makes us important.

Over these past two years, I’ve been fortunate enough to meet thousands of people: founders, hackers, investors, writers, students, and leaders. Some among them sought success in business; others sought learning and fellowship. Most understood that the two weren’t so different.

Along the way, I’ve come to see starting up as being a bit like falling in love: passionate words whispered over drinks, late nights that turn into long weekends, fleeting moments of absolute (and terrifying) clarity… followed by the harrowing awareness that things will, in all likelihood, not work out in the long run. What then?

As it is with relationships, so it is with startups: the best and only balm for a broken heart is friendship and family. In this game of numbers, one cannot afford to wallow in “failure”; we must rely on one another to help us through the disappointments so that we can dust ourselves off and try again.

Economists are fond of saying that “a rising tide lifts all ships”; it is humbling to belong to a community that so brilliantly embodies this aphorism. We work together, we play together, and we learn together. We share in the good and the bad and we understand this: the journey is everything.

In this new year, I look forward to continuing our journey together — to see what we’ll build and what we’ll say, who we’ll meet and what we’ll do. Most of all, I look forward to sharing another year of ups, downs, ANDs, ORs, and NOTs with you.

Have a happy and healthy 2012!

We Need Someone to Bridge the Gap

Mon, 19 Dec 2011 12:50:59 -0500

trevorowens:

It’s 48 hours before elections close for the NYTM Board. Last year I outlined my reasons for voting for Evan Korth of NYU/HackNY and here I’d like to explain the reasoning behind my vote for this year.

Let’s start by asking: What’s missing from the NYTM Board?

Take a look at the Board and you’ll see a cast of accomplished and inspiring people. Dawn Barber, Scott Heiferman, Esther Dyson, David Rose, etc.

It’s great to have them on the Board because they bring influence and credibility to the NYTM, which is now the largest meetup in the world and the center of gravity for the startup community in NYC.

The Board’s job is to steer the direction of the organization through empathy with its members’ needs, and also manage relationships with other important bodies (the city, stakeholders, etc).

Think about the former for a minute and you’ll realize the opportunity I’d like to get across. While the membership is composed of mostly first-time founders—the hackers & hustlers who are trying to figure everything out—the Board are far past that stage.

The NYTM has been built up to an incredible scale and influence, and now it’s time for it to execute on fulfilling the needs, hopes and dreams of its members.

Because of this I believe that we need someone to bridge the gap between the membership and the Board. And I think the best person to do that is Brandon Diamond.

If you’ve been to the NYTM, you know Brandon.

He’s the young nerdy-looking co-organizer of NYTM that also runs the Hacker Union, a close-knit meetup for NYC’s developer community. Brandon’s incredibly active in the tech community, and he’s a first-time founder himself.

As co-organizer, Brandon does the heavy lifting of throwing the monthly event (which he’s done for the past two years) without much say into the vision/direction of NYTM. Electing him to the Board will give him that say.

Since Brandon knows the Board members and NYTM intimately, not only can he empathize, but he can also translate.

One of my favorite quotes goes, “In the beginner’s mind there are many possibilities, in the expert’s there are few.” There’s so many directions the membership want to go with the NYTM that have not been addressed or given attention by the Board. Brandon makes a specific mention to address this in his campaign page because he knows better than anyone what’s going on.

As an example, consider the Student NYTM, a subset of the NYTM that connects like-minded students in the community and gives them free tickets to the monthly meetup. Brandon spent significant time brainstorming and helping the group launch because he recognized the importance of the student pipeline. What did the Board do? Well, they’re not involved.

Another example is Hack of the Month, which Brandon created to get more hackers involved in the meetup. This adds a ton of value to the NYTM and is something that only Brandon could pull-off.

Not only does Brandon have empathy for the community, but also he has vision and the dedication to execute it. He won’t just be an important member of the Board, he’ll become one of the most important leaders in our community.

For these reasons, I hope you will consider the importance of casting your vote for Brandon.

Go here to vote: http://vote.nytm.org/polls/3

The opportunity to submit or modify your vote ends Tuesday, December 20th at 11:59pm.

Building MongoDB for Fun and Profit

Thu, 15 Dec 2011 18:05:00 -0500

This post was originally published on the College2Startup blog.

“How’d you land a job at 10gen?”

My name is Brandon Diamond, and I’m a Database Kernel Engineer at 10gen. I’m very active in the startup community having served as the producer of the NY Tech Meetup; I’m also involved in several other groups including the Hacker Union (HackerUnion.org) as well as the Brown University NYC Meetup.

The emphasis I’ve placed on community activism has helped me to build a great network of friends and colleagues; it has also afforded me the opportunity to learn a great deal about NYC startups and organizations. Over the course of the past year, I became friends with a number of engineers at 10gen; I even began to use MongoDB in a number of my own startup projects.

When I decided it was time to start a new job, I reached out to some of the friends I had made at 10gen and asked them about open positions. Between the engineering-oriented company culture, open source MongoDB code base, and 10gen’s strong ties to the startup world, I knew that 10gen would be a great fit for me. I came in for an interview and started the following week.

“So… what exactly do you do?”

The Database Kernel Team at 10gen focuses on the MongoDB database server and related systems. We construct features, implement improvements, and address bugs as well as other user feedback. We also help troubleshoot unusual behavior in users’ MongoDB installations.

Working on the Database Kernel Team has proven to be a fantastic learning experience. I spend a great deal of time working with low level aspects of a wide number of systems; the code itself is well architected and efficient. Importantly, there are a great many people who enjoy using MongoDB; it’s fun to work on an interesting, complex project that directly impacts so many diverse — yet technical — users.

“What’s it like to work at 10gen?”

10gen offers a uniquely awesome startup experience. The culture is technical, casual, and meritocratic. Between the fully stocked snack bar and the weekly office lunches, working at 10gen doesn’t quite feel like… well, work. The team is friendly, outgoing, and passionate — everyone is excited about what they’re doing and eager to share what they’re working on.

Hierarchically speaking, the company is largely “flat”; the CEO and CTO sit alongside the other engineers and both write a significant amount of code nearly every day. The emphasis is on progress, community, and great software engineering.

All in all, 10gen is a fantastic place to work if you’re a startup-minded engineer who doesn’t want to compromise on tech or miss out on the startup experience. I couldn’t be happier with my choice of employer.

Me, Myself, and the NY Tech Meetup

Tue, 06 Dec 2011 12:00:08 -0500

It Begins

Two years and four months ago, I got off the subway and walked through the doors of FIT for my first NY Tech Meetup. Inside, I expected to find startups and demos. Instead, I found a movement.

Later that night I sent Nate Westheimer the first of what would be many emails:

I love what you’re doing at the NYTM. Is there anything I can do to help?

Over the months, I’ve watched as the community has flourished and grown; I’ve worked hard to refine our meetup into an event worthy of the NYU Skirball stage and, more importantly, your time and attention.

I’ve trained and rehearsed hundreds of presenters and personally auditioned dozens upon dozens more. I’ve fought for openness, community, transparency, and action. I’ve rolled up my sleeves and gotten my hands just about as dirty as hands can get.

Two years and four months later, I’m still helping. Why? Because I love NY tech. That’s not campaign rhetoric: it’s my call to action, my modus operandi. It’s why I’ve volunteered for these two years, four months and counting.

My Platform (… in a nutshell)

I don’t run a business school, I haven’t grown a startup to 100 employees, and I certainly haven’t raised a billion dollars— but I have spent 2 years writing code, co-organizing the NYTM, and getting to know the community.

The NYC startup experience isn’t abstract to me: it’s what I’m doing right now.

The only skin I’ve got in the game is my own— I’m running for the NY Tech Meetup Board not as a representative of a huge startup or incubator program, but as your representative. I’ve given the community two years of sweat equity and dedication; now I’m asking for your vote so I can take things even further.

I stand for three things: community involvement, getting things done, and recruiting more hackers. It’s my intention to identify and empower community leaders as a means of fulfilling our potential as an organization. Meanwhile, we’ll collaborate more closely with our engineers, creatives, and builders to ensure that there’s a steady stream of talent to fuel our industry well into the future.

In Closing

I’ve been putting blood, bytes and tears into this group for a long time. It hasn’t always been easy, but it has always been rewarding. The NY Tech Meetup has incredible potential — potential that remains to be fully realized.

If you’ve attended a meetup or two, please take a look at my full platform at BrandonForNYTM.org — a small resource I’ve put together for the election. I’d like to do what I can to help the NYTM grow into the community-powered grassroots organization it was born to be; but before I can do that, I need your help.

Why The MongoDB Hate?

Sun, 06 Nov 2011 09:00:00 -0500

Disclosure: I hack on MongoDB.
Update: Check out Eliot’s (10gen’s CTO) response here.

I was a little surprised to see all of the MongoDB hate in this Hacker News thread (and later this similar proggit thread). I’m going to do my best to reply to these concerns directly and with a minimum of breast-beating.

There seems to be quite a bit of misinformation out there: lots of folks seem focused on the global R/W lock and how it must lead to lousy performance. In practice, the global R/W isn’t optimal — but it’s really not a big deal. Here’s why:

First, MongoDB is designed to be run on a machine with sufficient primary memory to hold the working set. In this case, writes finish extremely quickly and therefore lock contention is quite low. Optimizing for this data pattern is a fundamental design decision.

Second, long running operations (i.e., just before a pageout) cause the MongoDB kernel to yield. This prevents slow operations from screwing the pooch, so to speak. Not perfect, but smooths over many problematic cases.

Third, the MongoDB developer community is extremely passionate about the project. Fine-grained locking and concurrency are areas of active development. The allegation that features or patches are withheld from the broader community is total bunk; the team at 10gen is dedicated, community-focused, and honest. Take a look at the Google Group, JIRA, or disqus if you don’t believe me: “free” tickets and questions get resolved very, very quickly.

Other criticisms of MongoDB concerning in-place updates and durability are worth looking at a bit more closely. MongoDB is designed to scale very well for applications where a single master (and/or sharding) makes sense. Thus, the “idiomatic” way of achieving durability in MongoDB is through replication — journaling comes at a cost that can, in a properly replicated environment, be safely factored out. That’s another design decision.

Next, in-place updates allow for extremely fast writes provided a correctly designed schema and an aversion to document-growing updates (i.e., $push). If you meet these requirements— or select an appropriate padding factor— you’ll enjoy high performance without having to garbage collect old versions of data or store more cruft than you need. Again, this is a design decision.

Finally, it is worth stressing the convenience and flexibility of a schemaless document-oriented datastore. Migrations are greatly simplified and generic models (i.e., product or profile) no longer require a zillion joins. In many regards, working with a schemaless store is a lot like working with an interpreted language: you don’t have to mess with “compilation” and you enjoy a bit more flexibility (though you’ll need to be more careful at runtime). It’s worth noting that MongoDB provides support for dynamic querying of this schemaless data — you’re free to ask whatever you like, indices be damned. Many other schemaless stores do not provide this functionality.

Regardless of the above, if you’re looking to scale writes and can tolerate data conflicts (due to outages or network partitions), you might be better served by Cassandra, CouchDB, or another master-master/NoSQL/fill-in-the-blank datastore. It’s really up to the developer to select the right tool for the job and to use that tool the way it’s designed to be used.

At the end of the day, MongoDB is a neat piece of software that’s designed to be useful for a particular subset of applications. Does it always work perfectly? No. Is it the best for everything? Not at all. Do the developers care? You better believe they do.

Things haven’t always been peachy. That’s why we recommend all new users start with the 2.0.x series (frankly, it seems unfair to rail on a project when you’re two major versions behind). If you look back, you’ll find mistakes: but you’ll also find a team of dedicated people who have worked hard to fix those mistakes.

10gen has built a novel datastore that offers high availability, sharding, and schema-free design at a very specific cost. Bugs will be pushed, mistakes will be made, and systems will go down. There is no silver bullet.

If you’ve got a mission critical application and you’re looking for a datastore, the first question you should be asking isn’t about internals or anecdotes, it’s “how are the inevitable boo-boos handled?” If the answer isn’t “efficiently, transparently, and with a heaping spoonful of honesty” — like it is with 10gen — you’ve got bigger problems.

Like free pizza? And hacking? Come to the August Hacker Townhall!

Mon, 22 Aug 2011 15:33:42 -0400

Like free pizza? And hacking? Come to the August Hacker Townhall!

Something Worth Fighting For

Mon, 15 Aug 2011 15:24:00 -0400

I fear for the future of the PC. The whole of consumer tech seems to have embraced the idea of autopilot computing: we’ve traded our freedom of choice for hollow devices coated in black lacquer and chained to strict software repositories and restrictions. If we dare defy the manufacturer by running unapproved software, we risk remote deactivation and lawsuits.

I fear for the future of the Internet. As eagerly as we’ve surrendered general purpose computing, we’ve sold our right to access an unadulterated and open web. If we don’t take action to preserve net neutrality and to ensure that the carriers — and our representatives! — cannot strangle our Internet, soon we’ll find our web browsers just as crippled as our mobile devices.

I fear for the future of developers. With the workings and machinations of our computers buried beneath layers of abstraction, litigation, and restriction, future generations will be deprived of the discovery and learning that has characterized computing through the 80s, 90s, and 2000s. Those that do pursue programming will spend their time studying proprietary APIs and complex licenses with little hope of accessing source code let alone the hardware itself.

I submit that we’ve taken for granted the single most important aspect of the computing revolution: openness. The closed systems, networks, and technologies that loom on the horizon reek of 1984 and threaten to dissolve the progress humanity has made over these past decades. This is something worth fighting for.

Announcing 56k: A NY Tech News and Culture Podcast

Wed, 27 Jul 2011 15:09:00 -0400

Well, I’ve finally gone and done it. Meet 56k.

I’ve been wanting to put together a podcast for a long, dreadful time; something led me to believe that it’d be quicker to assemble than a high quality blog post. I was sorely mistaken.

If you listen (and I hope you do!), you’ll find something of a hitchhiker’s guide to the soft underbelly of the NYC tech world. It starts with an overview of “This Week in New York Tech” and ends with a sassy diatribe regarding MBA types’ eternal quest for tech co-founders. I plan on putting new episodes out every week.

So, what do you think? Drop me a line in the comments!

Saved Windows with GNU Screen

Wed, 13 Jul 2011 13:45:00 -0400

I seem to have a certain affinity for obscene numbers of local screen windows. Rather than do all my development remotely or in a VM, I’ve put together a simple little hack so I can get back to work with a minimum of ^A-c.

The script allows you to quickly re-open any number of screen windows, grouped by name. You tell the script what to do using a simple configuration file consisting of multiple sections delineated by psuedo-tags, each containing a list of commands to run in separate screen windows.

For instance,

vim -o pretty.css -o index.html -c 'vsplit ugly.js'
emacs just.html kidding.html
compass watch

# here's a comment; incidentally, blank lines are okay too.

vim -o lol.asm pwn.c
vim some-other-file.c
./run-server local

To spawn screen with the requested windows, simply chant:

./work.bash debug

And that’s it.

The NYC Hacker Townhall. Join us!

Tue, 05 Jul 2011 16:20:05 -0400

The NYC Hacker Townhall. Join us!

An Open Letter to the Media: ARGHHGHGHHG.

Tue, 05 Jul 2011 12:33:00 -0400

Dear Media,

It would seem that you’re struggling with a teensy bit of semantics — namely, the precise meaning of the word “hacker”. Let’s get this sorted out, shall we?

Fig. 1: A Cracker.

The root of the problem seems to be the distinction between bad hackers and good hackers. Many seem to swallow the qualifier outright, insisting that all hackers are zit faced cyber criminals lusting after AOL passwords. Tut-tut!

So let’s talk about bad versus good. To start, both are bad.

A Hacker is not characterized by any particular action (i.e., a hacker is not someone who plays footsie with Iran’s power grid): “hacker”, as a descriptor, simply implies a particular set of technical skills as coupled with a deeply creative and highly inquisitive demeanor. For this reason, a bad hacker is bad in the same way a bad lover is bad: the adjective serves only to modify the subject’s ability to perform. A bad lover doesn’t club seals on weekends, right? Neither does a bad hacker.

Fig. 2: A Hacker.

Moving on: if a hacker is — simply put — an inspired technologist, then who are these poopie heads that break into eBay and steal all of our megabytes?

Crackers. I know, the word isn’t quite as sexy as its counterpart (and may indeed conjure images of Jerry Springer) — but isn’t it about time we got this right? Think about all the nice hackers who build the technology that you love and cherish: the smiles on their faces as they merrily code your WordPress plugins and Drupal extensions. Get it right for the hackers!

Here’s how: if the subject in question is pubescent, goes by a handle like F1r3N1nj@ and/or reminds you of a character in the 1995 hit film The Net, you’re dealing with a cracker. Incidentally, you should probably change your password, social security number, and underwear just to be sure you’re not a victim of collateral pwnage.

Examples: LulzSec, Captain Crunch, Zer0 C00l, lots of Uzbeks (apparently), most employees of Microsoft.

Fig. 3: A Cracker (genus: scriptus kiddus)

If — conversely — the subject appears to be a tech savvy individual with a penchant for tinkering or a proclivity toward hackathons: well, that’s most likely a hacker. If it’s got a UNIX beard (… or a casio watch, or a subscription to 2600, or a Tux pendant), it’s definitely a hacker.

Examples: Brian Kernighan, John Resig, Dennis Richie, RMS, Bjarne Stroustrup, Fabrice Bellard (behold this), most unemployed developers.

Fig. 4: A Hacker (genus: tuxus maximus)

There you have it: a hacker is a clever techie who thrives on caffeine and code (and fedoras) while a cracker is a sociopath who breaks into your mom’s Facebook account and posts unflattering pictures of you from high school (in a fedora).

Watch those ports n3wbs,
th33vi1g33k

Putting LulzSec in Perspective

Mon, 27 Jun 2011 18:47:00 -0400

For one reason or another, everyone on the Internet is talking about LulzSec — the latest and, well… latest cracking sensation. Think Zero Cool meets 4chan for a very twisted, very inappropriate playdate.

Since the whole lulzy affair started, coverage has gradually increased both in frequency and righteousness. And now that LulzSec has since “abandoned ship” (crawling begrudgingly upstairs to bed without Xbox privileges for a week or longer), bloggers everywhere are suddenly locating their respective gonads.

But it’s too little, too late: the attention paid to LulzSec — a group of variously skilled crackers with a proclivity toward anarchy — is disgusting. And dangerous.

The single, key difference between LulzSec and most script kiddies is that the members of LulzSec (whom many purport are indeed youths) have been indulged by a group of “technologists” who know nothing of technology and who have indisputably encouraged all sorts of copycat dickery at the expense of everybody else.

These technologists (bloggers, writers, journalists, podcasters, youtubers, tubers, potatoes) continue to call the shots without pausing to do a lick of research or — be still my heart — bothering to learn a goddamned thing about how tech works.

Sensationalism. That’s all it amounts to. Stories are delivered by neckbeards fawning over iPads and Twitter who couldn’t even begin to explain the difference between a DDoS attack and a buffer overflow. But who really gives a shit? As long as an article generates hits and traffic and revenue, it’s all good.

But it’s not — especially to the younger members of groups like LulzSec.

Teens act out. Tech-inclined teens act out online. They make up handles, hang out on IRC, bot their Facebook friends, and swap “dox” on one another. Are these really the behaviors we should be promoting?

We’ve all been young. We’ve all made mistakes. We’ve all sought power over something small to prove that those bad grades or that fight we had with our parents doesn’t mean we’re not important.

It’s a healthy, psychological need that tends to be satisfied in an unhealthy way… if not nipped in the bud by a caring, invested support network. It’s about self worth and self confidence — and that’s it.

Which is why LulzSec is a tragedy in two parts.

First, the senseless coverage belched forth by the blogosphere has without question supercharged the script kiddie egos trying to ‘sploit — and then fuck over — the companies that we depend upon every day. Shame on Sony for having an unpatched version of Procmail on a production machine but more shame on the crackers who release the sensitive, personal information of thousands of innocent people for a quick tweak from Gawker or TechCrunch.

Second, the members of LulzSec, both youths and adults alike, will eventually be caught and will eventually face very real, very serious consequences. These crackers — though misguided — are still intelligent, capable people. That they turned their attention to virtual gangbanging is a symptom of a larger problem: we’ve created and sensationalized an image of hacking that is both immoral and dangerous.

This is a loss and failing that all technologists must confront together. We can and must build a better culture that outshines the technologically and socially backward fairytale “hacking” projected by the media.

For a long time, I made many of the same mistakes: rooting, trojaning, ping-of-death-ing. I fancied myself a pretty elite hax0r — and my buddies on IRC generally agreed. We were all wrong, of course.

Around age fourteen, I hooked up with a researcher named “RH” at eEye — a noted security firm — and implored him to serve as something of a hacker mentor. What he taught me was the polar opposite of what I’d expected to learn: RH helped me understand just how twisted my view of the world had become. He dubbed me script kiddie and offered to plot my course to rehabilitation were I still interested. I was.

Over months of swapped emails, coding assignments, and a hefty number of O’Reilly books, I finally came to understand how to fill the void* in my heart: and it wasn’t by chortling at a system administrator with egg on her face.

No: my goal was far loftier, far less accessible, yet far sweeter. I learned to appreciate the simple beauty of a clever hack — to satisfy my curiosity by exploring and observing — to solve problems thoughtfully and with a patient hand. Most importantly, I learned to respect others and in so doing, I learned to respect myself.

The cracking scene may soon pay a steep price for what amounts to a misunderstanding of what it really means to hack. Unless we change the way we view, cover, and experience technology — that price might be ours to pay, as well.

"There are folks who spend their time doing actual scientific research into what’s a good..."

Sat, 18 Jun 2011 12:00:00 -0400

“

There are folks who spend their time doing actual scientific research into what’s a good predictor of future performance on a task. And guess what: experience / having done it before is the best predictor. Ignoring prior experience is throwing away the best predictive tool there is[.]

And there are entire segments of the population whose brains are wired not to think well on the spot. They need time to process, yet they can come back with stunning solutions. You’re ruling all of those perfectly skillful folks out with your insistence on a capability unrelated to what they’ll actually have to do on the job.

Coding isn’t like playing speed chess.

”

- Mathew L, in reply to “How to hire a (fucking) developer”. Well said, sir.

How to Hire Developers

Thu, 16 Jun 2011 19:09:00 -0400

This is a SFW version of an article I wrote called “How to (#$@*&!) Hire Developers”.

This is a topic that has really gotten out of hand. There are all sorts weighing in these days — along with far too much hand waving by middle managers and idealist super hackers.

So let’s cut to the chaff, shall we? Here’s how to hire a great developer:

1. Use credentials.

I don’t know how the discussion has devolved to the point that this isn’t obvious. You’re not going to somehow probe the extent of a persons’ mental faculties by quizzing them on minutiae that virtually nobody commits to memory. You judge a person based on what they’ve done before they land in your office. It’s simply not possible to compress a college education or a product launch into a 30 minute interview.

“Sure — but college isn’t the real world. What good is a bunch of theory when I need someone practical?”

The purpose of a college education is to demonstrate the ability to learn and excel at a high level. If a candidate managed to distinguish herself in school, pay attention. For computer scientists (unlike, say, English majors) part of that training is legitimately practical: we learn how to engineer software using big-kid tools. Ask us about our projects and then decide if they’re credible.

The notion that the years we spent pounding on books and keyboards doesn’t count as much as writing slapdash browser plugins for $20/hour is simply unfair. Disregarding students’ investment as mere rigmarole is equivalent to asserting that Gandhi went on hunger strikes because he wasn’t hungry. Many of us sacrificed for our education; the least you can do is honor it.

“Fine — but what if a candidate slipped through the cracks? Or earned bad grades? Or didn’t go to college? What then?”

Respect for learning is hard to fake. Consider: past-experience; volunteering; open source; projects; hobbies. It’s not the college so much as the education. Which brings us to…

2. Pay attention to outside projects.

Who really cares if an engineer can write a binary search? Anyone who still writes code to sort a batch of integers is either (1) a student, (2) not merely sorting integers, or (3) a total amateur. How do you sort a list? You invoke sort. Next?

“But that’s a trivial question! What about sorting seventy eight petabytes of cat images on a machine with forty kibibytes of RAM and a system bus that’s only two and a half bits wide?”

Okay. That’s interesting — and we’ll get to the questions you should ask next — but there’s an easier way to cut the fat:

Spend four minutes actually checking out the candidate’s outside projects. Do they have a github? Did they write a thesis at school? Did they send you a code sample? Did they provide a recommendation from a professor?

When you ask people to write programs or solve programming riddles in front of you, you’re testing thousands of irrelevant skills at the same time. For one, there’s a huge difference between coding and coding on a dirty whiteboard in front of a manager as she breathes down your neck and weaves a frosty web of critique. For another, developers (usually) make awfully nervous thespians.

Besides, a developer will almost never encounter a similarly abusive situation in practice: code reviews and discussions are conducted by peers and friends who aren’t simultaneously computing an ultimate judgement of your person and intellect.

In fact, let’s get even more specific…

3. Get (and study!) a code sample.

What’s better than yakking in front of a whiteboard for thirty minutes? Reading through original source code that the candidate is genuinely proud of and that she deems worthy of your eminence.

And you know what’s better than tossing around open questions about favorite bugs and algorithms?

Asking those same questions about the candidate’s code sample while it’s actually out in front of you.

Heck, you can really dig into that sample — the more code the better. If there aren’t interesting questions to ask about the candidate’s specimen, well, either they’re dumb or you are.

But don’t forget: use code that we’ve had time to architect and think about. And most importantly…

4. Don’t give any homework.

I’m looking for a job. I’m busy interviewing at fifty different companies in fifty different townships. I’m trying to make ends meet and I certainly don’t have time to write a spellchecker for you in C++.

It’s not fair for you to ask someone to spend hours writing dumb programs for you and it’s certainly not fair for you to ask someone to spend hours working on your dumb programs without paying them (just because I’m a developer doesn’t mean I can’t wait to write plugins for your marketing tool).

Don’t take the easy way out: get that code sample, study it, and then ask me about it. Simple as pi.

And while you’re asking me questions…

5. Don’t you dare ask me a riddle.

Whoever started posing brain teasers on tech interviews deserves a swift elbow to the gut. Brain teasers are completely unrelated to:

my ability to code
my creativity
my ability to design algorithms
my performance as an employee
my performance under pressure
my intelligence
my engineering experience
my personality

You know who’s good at brainteasers? People who are good at brainteasers. That’s about it. The rest of us spend our time writing awesome code, learning about system architecture, and having a life instead of trying to figure out how many blind prisoners on a desert island ate green pudding last Tuesday.

Don’t waste our time…

6. Ask relevant questions.

Really want to see what color I turn when I’m forced to be insightful and creative in a strange person’s office? Fine. But at least ask me relevant questions that emphasize process over results.

As was mentioned, don’t grill me on minutae like syntactical quirks or the x86 paging model. Focus on genuinely creative questions that are interesting without requiring a stroke of genius solution.

For instance, if you’re hiring a network architect, ask your interviewee to design a hypothetical protocol for swapping cat images among a ring of anonymous, volatile nodes. Or, if you’re hiring someone who will legitimately need to design algorithms (which is much less common than it ought to be), ask him or her to walk you through the design of a lesser known algorithm and then perhaps give you some basic runtime analysis.

Most importantly, don’t get hung up on the details and do not pose questions that require a blinding flash of brilliance to solve: algorithmic plot twists are fun when you’ve got a few hours to think about them — not when you’re being grilled by someone who already knows the answer.

And please, for Pete’s sake…

7. Care about my personality.

The sad, sorry truth about the hiring process is that even a super brilliant ubergeek is worth dirt if she’s incompatible with your team.

In fact, I’d say the most — if not only — important thing to evaluate during an interview is whether a person is capable of learning quickly and whether that person is also someone you’d enjoy working with every day for the next five years.

Being smart, considerate, and (if necessary) a leader doesn’t require two decades of experience writing XSLT. These are intrinsic qualities that can only be ascertained by genuinely getting to know someone over a long period of time. Isn’t that the basis friendship?

While you can never know for certain whether a candidate is genuinely smart (… and genuinely not a jerk) there are a few things you can do to hedge your risk:

First, if any of your employees seem socially handicapped or otherwise sassy, don’t let them conduct interviews. You need friendly, kind folks who are capable of judging character — not the guy who “pwns Haskell” with his “skillz”. Fools beget fools.

Second, invite your candidates to join you for lunch, dinner, a snack, a company outing, whatever. Do your best to abolish the negative vibe so you can learn more about who your candidates really are.

That’s it.

Hiring developers doesn’t need to be dramatic and it certainly doesn’t need to be painful. Embrace the candidate’s humanity and focus instead on his or her existing street cred and his or her existing personality. If you must quiz, stay relevant — and most of all, don’t be a jerk.

Your startup sucks,
Brandon

How to (Fucking) Hire Developers

Thu, 16 Jun 2011 15:45:00 -0400

This is a fairly coarse article. There’s a gentler version posted here.

This is a topic that has really gotten out of hand. There are all sorts weighing in these days — along with far too much jowl waggling by middle managers and idealist super hackers.

So let’s cut the shit and get down to business, shall we? Here’s how to fucking hire a great developer:

1. Use fucking credentials.

I don’t know how the discussion has devolved to the point that this isn’t obvious. You’re not going to somehow probe the extent of a persons’ mental faculties by quizzing them on minutiae that literally nobody commits to memory. You judge a person based on what they’ve done before they land in your office. Why? Because it’s not possible to compress a college education or a product launch into a 30 minute blabberfest.

“Wah! Boo-hoo. College isn’t the real world. I can’t use no book learnin’ to straighten out our VB.NET calculator optimization plant!”

You are what’s wrong with the industry. The whole point of a college education is to demonstrate the ability to learn and excel at a high level. If a candidate distinguished herself in school, pay attention. For computer scientists (unlike, say, English majors) part of that training is legitimately practical: we learn how to engineer software using big-kid tools. Ask us about our projects and then decide if they’re credible.

The notion that the years we spent pounding on books and keyboards doesn’t count as much as writing bullshit browser plugins for $20/hour is flaming garbage. Disregarding students’ investment as mere rigmarole is equivalent to asserting that Gandhi went on hunger strikes because he wasn’t hungry. Many of us sacrificed for our education and you better damn well pay attention to it.

“Hurr-durr, what if a candidate slid by? Or earned bad grades? Or didn’t go to college? What then?”

Respect for learning is hard to fake. Consider: past-experience; volunteering; open source; projects; hobbies. It’s not the college so much as the education. Which brings us to…

2. Fucking pay attention to outside projects.

Who gives a shit if an engineer can write a binary search? Anyone who still writes code to sort a batch of integers is either (1) a student, (2) not merely sorting integers, or (3) a total loser. How do you sort a list? You invoke sort. Next?

“But that’s a trivial question! What about sorting seventy eight petabytes of cat images on a machine with forty kibibytes of RAM and a system bus that’s only two and a half bits wide?”

Okay. That’s interesting — and we’ll get to the questions you should ask next — but there’s an easier way to cut the fat:

When you ask people to write programs or solve programming riddles in front of you, you’re testing thousands of irrelevant skills at the same time. For one, there’s a huge difference between coding and coding on a dirty whiteboard in front of a sweaty meatball breathing down your neck and belching a constant stream of critique. For another, developers (usually) make awfully nervous thespians.

Besides, a developer will almost never encounter a similarly abusive situation in practice: code reviews and discussions are conducted by peers and friends who aren’t simultaneously measuring the length and girth of one’s coding prowess.

In fact, let’s get even more specific…

3. Get a fucking code sample.

What’s better than bullshitting in front of a whiteboard for thirty minutes? Reading through original source code that the candidate is genuinely proud of and that she deems worthy of your eminence.

And you know what’s better than tossing around open questions like “lol what was ur favorite bug???” or “hehe wut algorithms do u think r kewl?” Ooh! I know:

Asking those same questions about the candidate’s code sample while it’s actually out in front of you.

Hell, you can really dig into that sample — the more code the better. If there aren’t interesting questions to ask about the candidate’s specimen, well, either they’re dumb or you are.

But don’t forget: use code that we’ve had time to architect and think about. And most importantly…

4. Don’t give me any bullshit homework.

I’m looking for a job. I’m busy interviewing at fifty different companies in fifty different townships. I’m trying to make ends meet and I certainly don’t have time to write a bullshit spellchecker for you in C++.

Do you ask a cleaning service to clean your home before you hire them? Do you ask your accountant to file your taxes just to see if they’re any good? Do you sleep with a love interest before going on that magical first date?

No. It’s not fair for you to ask someone to spend hours writing dumb programs for you and it’s certainly not fair for you to ask someone to spend hours working on your dumb programs without paying them (just because I’m a developer doesn’t mean I can’t wait to write apps using your proprietary API).

And while you’re asking me questions…

5. Don’t you fucking dare ask me a riddle.

Whoever started posing brain teasers on tech interviews deserves to be elbowed heartily in the junk. Brain teasers are completely unrelated to:

my ability to code
my creativity
my ability to design algorithms
my performance as an employee
my performance under pressure
my intelligence
my engineering experience
my libido
my personality

Don’t waste our time…

6. Ask goddamn relevant questions.

And please, for Pete’s sake…

7. Give a shit about my personality.

The sad, sorry truth about the hiring process is that even a super brilliant ubergeek is worth dirt if she’s a douche-nozzle (or, more delicately, “incompatible with your team”).

In fact, I’d say the most — if not only — important thing to evaluate during an interview is whether a person is capable of learning quickly and whether that person is also someone you’d enjoy working with every day for the next five years.

Being smart, considerate, and (if necessary) a leader doesn’t require two decades of experience writing XSLT. These are intrinsic qualities that can only be ascertained by genuinely giving a fuck over a long period of time. Isn’t that the basis of friendship?

While you can never know for certain whether someone is genuinely smart (… and genuinely not a jerk), there are a few things you can do to hedge your risk:

First, if any of your employees seem socially handicapped or otherwise douchey, don’t let them conduct interviews. You need friendly, kind folks who are capable of judging character — not the guy who “rapes Haskell” with his “skillz”. Dicks tend to attract dicks.

Second, invite your candidates to join you for lunch, dinner, a snack, a company outing, whatever. Do your best to abolish that dank S&M vibe to learn more about who your candidates really are.

That’s it.

Your startup sucks,
Brandon

Tide change at the lagoon.

Mon, 06 Jun 2011 16:04:29 -0400

[Flash 10 is required to watch video.]

Tide change at the lagoon.

"What we obtain too cheap, we esteem too lightly (…) it would be strange indeed if so celestial..."

Sat, 04 Jun 2011 00:39:36 -0400

“What we obtain too cheap, we esteem too lightly (…) it would be strange indeed if so celestial an article as FREEDOM should not be highly rated.”

- Thomas Paine

O' Brave New World, That Has Such UI In't!

Fri, 03 Jun 2011 19:09:00 -0400

“You’ve got to choose between happiness and what people used to call high art. We’ve sacrificed the high art.”

- Mustafa Mond, Brave New World (A. Huxley)

For two decades, we’ve been mind-meltingly fortunate. A defense network designed to facilitate communication in the face of nuclear armageddon has, in time, blossomed into a gleaming instrument of freedom, liberty, and humanity. This tremendous equalizer is, of course, the Internet: that intertwined abode of humanity’s killer app, the World Wide Web.

This Web has provided a realm of information and human connection to billions of different people. Though at times ugly and “NSFL”, our World Wide Web has served as a bastion of freedom in an ocean of repression. We have enjoyed an unprecedented Era of Information. An era that is quickly ending.

Today’s Web is different. Information is no longer the Web’s first class citizen. Instead, we find a farce of design and flash, noise and indulgence. Less an “Information Superhighway”, the modern Web is a tepid well of consumerism and constant consumption: Media 2.0.

Certainly there are counter examples. Worlds don’t change by instances but by paradigms and to this end, a shift is undeniable: the modern Web is an instrument of consumption — a network of funnels and advertisements and distractions.

Old Media wasn’t destroyed by “New Media” — it has merely been upgraded to a smarter distribution network. One that we pay for. One that subverts privacy. One that is all-powerful. We’ve traded our computers for Nielson boxes with high gloss finish.

Turning to Orwell — and soon Huxley — it isn’t too difficult to glimpse shards of 1984 festering at the fringes of our Web. Countries like China and Australia restrict the flow of information and legislation in our own country seeks to further convolve the interests of large corporations with the interests of the people’s Internet.

Yet, as critical and essential as net neutrality is, I posit that the greatest risk to the free Internet — if not general computation as we know it — lies closest to Huxley’s famous dystopia.

Were you to ask a student to describe a valuable website or application in 1995, you’d likely encounter phrases like “detailed”, “carefully organized”, “functional”. Ask again today, and you’ll discover a different yarn.

This is where we meet a straw man: modern applications are designed to be “well organized” and “easy to use”. That technology has been made shinier and more accessible isn’t a flaw but a feature — and besides, this is what people want.

Consider, then, Steve Krug’s famous usability motto: “Don’t Make Me Think!”

My criticism lies not with Krug’s motto nor with the pursuit of simpler and more intuitive systems: instead, I take issue with the way we, as a culture, have been interpreting this directive.

Krug’s quote and the corresponding book is straightforward: user interface elements ought to be as simple and efficient as possible. No interface should cause the user to pause unnecessarily.

Notice the distinction: Krug is discussing the interface and not the problem domain. His charge is to design a calculator that doesn’t make you think about button location or output format, not a calculator that forgoes tricky calculation.

Neither does Krug suggest that command line interfaces are innately bad or that having a task bar and icons is akin to assaulting one’s users: his philosophy simply encourages one to value intuition over elegance so that the user can focus on what’s important.

Too often are our products — both devices and software — the progeny of a misinterpretation and misapplication of the “Don’t Make Me Think” philosophy. Developers forget that a great calculator can still solve great problems; designers forget that there is such a thing as over-simplification.

We, as builders, are imposing idiocracy on our users because we don’t want them to think, ever — but we’re not solely to blame.

The bigger problem (and the second strawman we’ll meet) is that simple, dumb products are actually popular. The future is simplicity and varnish: widgets and apps and mobile devices and touch screens. Isn’t the customer always right?

Not this time. Increasingly, general purpose computers are being replaced with feature-limited, proprietary, and utterly closed off devices: take a gander at Windows 8, for instance.

Simple at the expense of power.

Despite the fact that these products are good fun and do handle a limited set of tasks exceedingly well, we mustn’t forget the impact that these walled gardens have on learning, creativity, and progress.

As a child of the era in which a computer’s inner workings would occasionally glow beyond the bevel and gradient of its windows, the loss of freedom is overwhelmingly clear. I, for one, would not be in this field were it not for the opportunities I had to explore a system instead of a toy.

Simple yet powerful.

Our addiction to simplicity has created an implicit resurgence of anti-intellectualism. Fashion has taken priority over function. Now, we’re in danger of losing a resource that has defined two decades of intellectual, economic, and social bounty.

Our only hope is to remind ourselves of why the Internet is not just another clearing house for the mass media. We must challenge our tendency to forgo function over form just as fiercely as we challenge governments that would impinge upon the free flow of our datagrams.

This is our Internet to preserve and to protect.

Your startup sucks,
Brandon

"A fire eater must eat fire even if he has to kindle it himself."

Thu, 02 Jun 2011 15:06:08 -0400

“A fire eater must eat fire even if he has to kindle it himself.”

- I. Asimov: “Bridle and Saddle”, Astounding Science-Fiction (June 1942)

Shifting My Bits

Thu, 02 Jun 2011 13:23:00 -0400

I seem to continually make the same mistake: I get hung up on something, sit on it for awhile, and digest it down to a grossly oversimplified 140-character treatise that manages to insult half of my Twitter followers and alienate the rest. It’s a small problem.

I’ll often promise to think things over and come back with a cleanly written, well-argued blog post — but that never seems to happen (as it turns out, blogging is hard).

Inevitably, the thoughts will persist and I’ll continue to chew them over until I reach a fork in the road: abandon my opinions and remain a wet noodle flopping about awkwardly or take a stand and spend a bit of time clarifying the murky butter that forms my thoughts.

Often, I noodle out; WordPress is a cruel mistress and I really hate designing the silly interstitial images that my (old) blog consumed. Irked by the UI, I’ll retreat to the safe, weathered cloister that is vim — keeping my hands on the keyboard for longer than four seconds feels great after an overdose of WIMP.

But I’m sick of being a floppy strand of angel hair (or even one of those cute tri-colored wagon wheels). Piping my opinions to /dev/null has gotten me nowhere and, for fuck’s sake, I’ve got a lot on my mind— goodness knows what sorts of health problems I’ll run into if I don’t flush my brain on a regular basis.

As a result, I’ve made a concession. In particular, I’ve shifted my bits from a machine under my control to one owned by a group of people whom, for the longest time, I’ve dismissed as tight-pants-wearing, thrift-store-shopping, master-lazer-praising, williamsburg-loitering hipster robots (never mind the fact that I wear skinny jeans and listen to Band of Horses when nobody is around). It’s a concession I’ve made in the interest of maximizing productivity over my all-important geek cred— besides, I can always make up the difference by spending a bit more time configuring snort.

Curmudgeon though I am, I simply can’t deny that Tumblr makes blogging fun again. Besides, in my advanced age, Tumblr’s use of unnecessarily large fonts does wonders for my eye strain. Life is good, it would seem.

Though this semi-inaugural post is virtually devoid of content, I intend to share many more of my somewhat “controversial” opinions in the coming days: articles ranging from why Windows 8 will bring about the destruction of human civilization to comparisons of modern internships and the indentured servants of the eighteenth century. I’ve got a lot to say and I intend to say it, by gum. I hope you’ll stick around!

Your startup sucks,
Brandon