Your Startup Sucks

One geek's struggle to find meaning on the Internet.

[startupsucks]

Conjuring Bullshit for Fun and Profit

Arthur C. Clarke — a British writer whose Wikipedia article I just skimmed — apparently once wrote: “Any sufficiently advanced technology is indistinguishable from magic.”

A nifty little quote, all things considered.

If you can remember the first time you booted a computer or tickled an iPhone’s multitouch screen or perhaps the first time you sent a message to a chatroom and a bloke several continents over instantaneously invited you to STFU: you probably know what Mr. Clarke is talking about.

The idea that the skirting of electrons across wafers of finely laced silicon yields the impossible complexity we enjoy on our computers, in our vehicles, and on our phones seems just as foreign as purple-tinged smoke unfurling from a wizard’s crystal sceptre.

Technology is magical — in the same way that any complexity seems magical until you’ve popped the hood and poked around a bit.

Indeed, as remarkable and esoteric as technology can certainly be, it is also decidedly not magical. Someone — who in all likelihood was a human being like you — had to roll up their sleeves and pull shit together so that you can watch cat videos on your cellphone at 30,000 feet.

While the overall result is admittedly magical (and I do believe that this sense of "magic" is very special and very real), the underlying innovation is also fiercely deliberate, incredibly complex, and often clever as a cartload of monkeys.

Broadly speaking, it seems that the magic card gets played in two very different scenarios:

The first typically involves a person who has been delighted by a nifty bit of technology and who doesn’t quite know how the darn thing works. For instance, that’s exactly how I felt the first time I encountered a glasses-free 3D display; that shit is unreal.

The second typically involves salespeople trying to move product at the expense of uninformed, non-technical consumers.

Shall we play mad-libs? Go ahead and strike the salespeople/consumers bit from the above and drop in any of the following pairs:

Entrepreneurs / Investors

Shitty developers / Managers

Writers / Readers

Agencies / Clients

Apps / Users

You’ll note that the sentence remains true.

Though most users are finally starting to work up a hint of tech literacy, the supernatural is often easier to embrace than the mundane: who wants to (or has the time to) study engineering when the techno trolls and code sorcerers are so much more compelling?

The point isn’t that more people should be engineers — though I do think it’s an endlessly fascinating field — it’s that there are loads of phony “startup” people out there exploiting the magic inherent to technology to further their own goals and line their own pockets.

They’re our industry's equivalent of dishonest car mechanics -- but with twice the bullshit and half the expert knowledge.

The net result of these shenanigans? Wasted capital, widespread deception, and the preponderance of grifters over actual innovators, inventors, and builders.

If you’re a technologist, I urge you to call bullshit early and often. Don’t let the hype machine run unchecked. Add your two cents.

If you’re a user, I urge you to get curious. Don’t assume that something is magical just because you can’t see the smoke and mirrors. Hire an independent contractor. Get a second opinion. Invest in innovation.

If you can't find the value, chances are it doesn't exist.

[startupsucks]

One Year Later: WTF?

Approximately 460.5 days ago, in a distant place (Florida) and a distant mood (happiness), I sat down to review my lot in life.

I wrote about the things that I thought made NY tech pretty neat. I shed a tear over the kindnesses of local "hackers" and even waxed poetic about the experience of being a founder in the heart of the Big Apple.

My delusion -- whether contrived or genuine -- was crystal clear. The words I wrote came from a place familiar to anyone who has ever felt like an outcast: I just wanted to fit in.

Reading these words now makes me feel like a complete sellout. How did I go from telling recruiters to get fucked to celebrating the warmth and kindness of the NYC startup phenomenon so quickly?

I outwardly celebrated what I inwardly mourned and boy do I feel like a cheap floozy now.

I've come to realize that if I don't write about the stuff that pisses me off, I'll be doing this community -- my community! -- a disservice. And that's the last thing this increasingly hypersensitive, nepotistic and ferociously self-involved "innovation" community needs. More useful might be some Jergens and a box of kleenex.

We need to topple the bullshit artists from their soapboxes. We need to value knowledge and skill over pomp and persuasion. We need to ephasize learning and education over cockiness and swindlership -- and no, Computer Science education isn't a business plan.

Simply put, we need to innovate and not just revel in the smell of our own shit.

So let's cut the crap. Personally, I'll be tearing down my internal politician in hopes of reconnecting with the angry geek within. We cannot endure another Bravo reality show: the bubble is popping and the flies are congregating. Time to flick them away.

[startupsucks]

A Moment for Reflection

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!

[owenstrevor]

We Need Someone to Bridge the Gap

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.

[startupsucks]

Building MongoDB for Fun and Profit

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.

[startupsucks]

Me, Myself, and the NY Tech Meetup

  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.

[startupsucks]

Why The MongoDB Hate?

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.

[startupsucks]

[startupsucks]

Something Worth Fighting For

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.

[startupsucks]

Announcing 56k: A NY Tech News and Culture Podcast

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!

[startupsucks]

Saved Windows with GNU Screen

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,

<design>   vim -o pretty.css -o index.html -c 'vsplit ugly.js'   emacs just.html kidding.html   compass watch </design>  # here's a comment; incidentally, blank lines are okay too. 

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

To spawn screen with the requested windows, simply chant:

./work.bash debug

And that's it.

[startupsucks]

[startupsucks]

An Open Letter to the Media: ARGHHGHGHHG.

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

[startupsucks]

Putting LulzSec in Perspective

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.

[startupsucks]

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.

[startupsucks]

How to Hire Developers

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

[startupsucks]

How to (Fucking) Hire Developers

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:

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 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

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 goddamn 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 toddle through 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. 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.

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 dick.

Your startup sucks, Brandon