Links from last week you may have missed:

Twitter pays engineer $10 million as Silicon Valley tussles for talent

Tech Ops As A Metaphor For Building, Running, & Leading A Company

Your career is a mess

Why your tech startup can’t hire engineers (and how to fix it)

Are Dev Bootcamps a scam? A Hacker’s perspective

How to Avoid Problem Clients

7 Lessons We Learned Going from Zero to $30k/Month in Under a Year

In preparation for a public launch, we ran a cursory load test to ensure that our rails application could handle a reasonable amount of traffic. Apache Bench is very easy to use, but the initial setup is a little confusing, especially if your site requires users to log in.

Collecting a cookie

The first step is to log into our website and store the cookie, so we can use it to make requests as an authenticated user.

Rails uses an authenticity token to protect the login page from CSRF attacks, so collecting a cookie with cURL is a bit of a hassle. We’ll first need to capture the authenticity token:

LOGIN\_PAGE=https://staging.example.com/sign_in
curl --cookie-jar cookie_file $LOGIN\_PAGE | grep csrf-token

The hiring market for developers is exceptionally tight right now. Just about every tech presentation ends with a “We’re hiring!” slide and any developer with a linkedin profile probably gets a few recruiter messages a week. Even unexperienced coders are in-demand: bootcamp-style developer classes run 10-12 weeks and usually have placement rates above 80%.

What’s surprising to me is how focused this attention is on filling so-called “permanent” roles. That is, full-time, salaried positions where a developer works exclusively for a single employer. Despite the shortage of developer talent, employers seem hesitant to consider working with freelancers or external consultancies. That’s particularly confusing when you consider the high cost of working with a recruiter, which is the standard solution for most companies that can’t hire quickly enough. Instead of paying a recruiter over $20,000 to fill a position, I would rather pay a freelancer to fill in the gaps in my team.

There are valid reasons to prefer in-house employees over contractors. But some of the conventional wisdom is merely cultural inertia. I describe some of the factors to consider below:

Startup founders and employees often describe their role as being either a Business or Technical. Developers, designers, QA testers, etc. are grouped together as part of the engineering/technical team, while product managers, sales, and marketers are part of the business team.

Although common, this division misses the point: there are two essential functions for product company and neither is strictly business or strictly technical. Specifically, these are:

1. Identify a market of people with similar problems, a willingness to pay someone to solve those problems, and the ability to pay for that solution.
2. Create a product that solves or alleviates a problem, in a repeatable manner, at a cost that is less than the value it provides.

I recently wrapped up a project to refactor all of my chef cookbooks to be more maintainable and coherent. This was my second chef project. The first attempt was reasonably successful: I could create new cloud servers and automatically provision them with a single command. But I didn’t have anything resembling a true development or staging environment, so any changes had to be made directly to the production servers. This obviously was not a healthy situation. This post will explain many of the mistakes I made the first time and how I corrected them.

Most of my code is available here: Chef Cookbooks. I’ll explain below how to configure these with your project specific settings.

The following are my notes from the 2013 AWS Summit Keynote presentation. These notes are largely for my benefit (mostly to make sure I’m actually paying attention during the talks) but may be interesting to others.

I wrote these notes during the presentation and have not diligently separated my thoughts from those of the speakers. It’s possible I have misunderstood some points or added thoughts of my own. Please assume any good ideas were originally those of the speaker. Any bad ideas are either my own musings or a misinterpreting of the presentation in question.

For some inexplicable reason, the internet didn’t already have a recipe for bacon cheese kugel. I decided to fix that:

Bacon Cheese Kugel

Ingredients:

• 1 pound noodles. You may use potato noodles if you’re making this for Passover
• 3/4 pound cheddar cheese, shredded
• 3/4 pound bacon
• 8 eggs
• kosher salt

As part of my efforts to promote this new blog, I’ve been submitting posts to hacker news. Not surprisingly, my initial submissions went roughly nowhere. Less than 100 visitors saw the posts.

Stepping back, I decided to think a little more about timing my submissions to get better results. HN Pickup Ratio looked like a nice representation of the relevant factors, but it is sadly defunct, as App Engine has been blocked from scraping hacker news. I liked the concept enough to write my own implementation, which is now available here: HN Notify.

Timing my last submission was exceptionally successful: it reached the front page of hacker news and was seen by 3,000 readers.

Concept

Assuming you want your HN submission to reach the front page, then it’s important to post at times when scores on the new page are relatively high compared to the front page.

As my startup gears up for our first paid marketing campaign, I’ve been giving some thought to the necessary preparations a developer should go through before driving some traffic to a web app.

In general, the goal isn’t to prevent every possible problem. In addition to being impossible, any attempts to do so would almost certainly involve premature engineering. Instead, my goal is to be adequately prepared for unforeseeable problems. The important thing is to ensure I’ll be notified when a problems occur and that I’ll have enough information to investigate and fix said problems.

We’re hosted on AWS, so this list assumes you’re running in a similar environment. Managed platforms like Heroku take care of much of this for you.

In no particular order, the following should be completed before aggressively promoting a new web app:

Grabowski’s Who Is Going To Buy The Darn Thing? isn’t nearly as popular as Steve Blank’s various works, but both share a similar underlying sentiment: that a startup’s marketing functions are as important if not more important than product development.

Grabowski’s contribution is a simple quantitative metric, the Marketing/Engineering ratio, and the claim that successful startups spend more on marketing than engineering (an M/E ratio greater than 1).

Defining the M/E ratio

To start, it’s important to clarify what “marketing” is in this context. Although the term is often used to describe a broad range of activities including sales and advertising, Grabowski takes a much narrower view:

Marketing is defined as the up-front process that comes before the product is ready. (Promoting and selling come after the product is ready.)

Grabowski’s writing pre-dates the Lean Startup Movement, so his definition unfortunately implies a hard separation between pre-launch and post-launch activities. Viewed from a Lean perspective, he is essentially arguing that “learning” have its own line item on a budget and that startups should spend more time/effort/money on learning instead of building. Arguing for an M/E ratio greater than 1 is just another way of saying we should spend more time learning about what to build than actually building. That’s a fairly obvious statement when put plainly, but it’s still surprising how many entrepreneurs get mired down in product development before actually confirming that their target market exists.