I coded all day yesterday, focusing on a new feature for Hirelite: Speed Dating for Software Jobs. I implemented ~300 lines, added tons of functionality, and was feeling crazy productive. After this surge of productivity, though, the familiar pangs of technical debt anxiety came. I prescribed a hearty dose of refactoring.

I looked for commonalities to refactor among the eight paths of the feature. In particular, two paths stuck out as having more in common with the rest of the feature than the other six. Coincidentally, these two paths were far more commonly used than the others. Additionally, these two paths could effectively cover the scenarios implied by the other six.

Interestingly, these commonalities emerged through implementation. As I implemented the eight paths, the data structures backing each path generally fell in to two buckets. Each of the two more commonly used paths took advantage of different data structures, allowing the less common paths to be covered by one or a combination of the two.

These things weren't obvious from the user experience or product perspective. It took a deep, code-level understanding of the details of the problem and multiple potential solutions to surface this insight.

By the time I actually finished the feature, it was down to 50 lines. Though the simplified solution now seems obvious, I'm sure I would not have found this shortcut without working through the initial cases and writing the 300 lines. 

It always astounds me how much work it takes to understand something well enough to truly simplify it. Sometimes I feel bad, like I've wasted a bunch of time building something that should have been easy from the start. Or maybe I shouldn't have done it at all - I should have hired a rockstarguru who doesn't need to write rough drafts of anything, ever. And then I remember those people don't actually exist.

The same seems to be true for art. Picasso said:

... pictures went forward toward completion by stages. Every day brought something new. A picture used to be a sum of additions. In my case a picture is a sum of destructions. I do a picture - then I destroy it. In the end, though, nothing is lost: the red I took away from one place turns up somewhere else.

Picasso simplified masterfully. In 45 days, he drew 11 bulls, eventually boiling a bull down to just 9 lines.

(download)

Click here to download:

effort-to-simplicity-code-design-art-fhBpzkoBBlJHteezjfHa.zip (205 KB)

Despite all this, I still have this gut feeling that I should have known.

• Do you run in to situations like this?
• Any tips on how to shortcut early iterations that take so much time?
• Is this the type of thing that more experience helps you get around or is it purely a creative process?

After we launch the feature, I'll try to follow up with a deeper dive in to the specifics of the implementation.

One of the main reasons all of development isn't outsourced is that it's hard to replace an in-house developer's personal investment in the business, cultural understanding, and market understanding. Additionally, communication is typically orders of magnitude more efficient.

As an in-house developer, you have a clear responsibility to give technical feedback on product designs, but your responsibility doesn't stop there. You are the last line of defense for your company's product or service. If a bad feature makes it past you, it gets released. If you're implementing a feature that makes no sense for your target market, or is spammy, or rubs you the wrong way, it is your obligation to speak up.

There is a natural set of responsibilities and checks for a product company. The management team sets the product vision. The product team specifies the product vision. The development implements the product specification.

There are two ideal outcomes from you defending your product:

1. You convince the product team or your manager that there's a problem.
2. Your product team or manager convinces you that the specified solution applies well for your market, use case, or company culture.

Neither situation is bad. In #1, you make them think more about the problem and potentially reach a better solution. In #2, you learn more about your product and market allowing you to better defend your product in the future from poor designs. 

Alternatively, you could learn that your company doesn't accept feedback like this. If that is the case, you are likely undervalued, and your company should probably be outsourcing the work (and likely will in the future). You should start considering other employment options.

Remember, if you release a bad product or feature, it is your fault. "I just built what was specified," is not an excuse for full-time, in-house developers. You build the product, you understand its details, and you release it to customers. It's your duty to defend it.

Self promotion

I run a company on a mission to put recruitment agencies out of business. We host speed interviewing events using video chat where 20 job seekers talk to 20 companies for 5 minutes each. If you're looking to evaluate the software job market or looking to hire, check out Hirelite.com.

Since starting Hirelite: Speed Dating for Software Jobs, I've been taking a lot of meetings around New York City. After each meeting, I like to find a place nearby to sit, plug in my laptop, and hack for a few hours. In New York, it's hard to find a place you can sit with some elbow room unless you know where to look (Starbucks is usually packed). It turns out, due to zoning regulations, NYC abounds with free public space, often indoors and often with open power outlets where they don't mind you sitting for a few hours.

tl;dr - In Manhattan, look for newish buildings that have a higher base height than buildings around them. Chances are, there's a place you can hack.

[Base height illustrated source]

Example

In the example below, there are three buildings. #2 has a much higher base height in relation to buildings #1 and #3. There's probably a place to hack here.

Why is this?

In the late 1800's and early 1900's, as buildings in New York City were built taller and taller, people protested the loss of light due to the shadows cast and light blocked by new buildings. When the Equitable building was built in 1915, it cast a 7-acre shadow and enforced the need for more zoning regulation.

[The Equitable Building source]

Early attempts to regulate building height, base height, and setbacks (how high building walls may be before they must be set back in relation to the building footprint), including the 1916 Zoning Resolutions, were too restrictive and were plagued with other problems inherent to a growing city.

New regulations were drafted to better fit the city's expansion, culminating in the 1961 Zoning Regulations. These regulations set forth incentives for building developers to create publicly available space. Essentially, the new regulations allowed building developers to build with a higher base height in exchange for having an enclosed atrium, an outdoor park, or some other public space. This is where the hack comes from (the hack doesn't work if there are a cluster of buildings taking advantage of these incentives).

If you prefer to research for yourself instead of finding a place on the fly, just visit this list of of all privately owned public space in NYC. This will also help you narrow down outdoor vs indoor public space.

For more information see: NYC Zoning History.

I'm embarrassed to admit that lately, I've been watching a lot of HGTV. Whenever I have programming to do that is easy but time consuming, I watch House Hunters or Designed to Sell in the background. On both shows, buyers and sellers use comparable houses to help them put a value on a house. Similarly, investors value companies based largely on how the company compares to other companies they've seen before. Wouldn't it be nice if there was some way for founders to see the valuations of other startups too?

Finding and Valuing Startup Comparables

You can start valuing your company more like an investor by seeking out comparable startups and working backward from the funding they've raised.

1. Go to the funding section of CrunchBase and look for companies who have received funding recently that are similar to you: similar stage (angel, seed, series X), similar progress (demo, launch, 10k users, paying customers), similar team size/composition.
2. Take the funding amount, divide it by 0.2 and 0.3 to get a range for the post-money valuation. 0.2 and 0.3 correspond to how much dilution you expect from the funding. Example: GroupMe raised $850k. The post-money (high end of the range) is $850k / 0.2 = $4.25m.
3. Subtract the funding amount from each side of the range to get the pre-money valuation. Example: GroupMe's pre-money (high end of the range) is $4.25m - $850k = $3.4m.

Here are a few example pre-money valuations of companies on CrunchBase who have received seed or angel funding within a month. Ideally, you'd look closer at the composition of the team and the progress of company; however, I've only included the team size and how long the company has been operating here.

Through Hirelite, cofounders often ask me how much equity a technical cofounder should get. The graphic below balances the risks cofounders take with their relative contributions to help answer this question. All assumptions and clarifications are noted after the graphic.

This covers one of the most common situations I encounter: For a pre-funding web startup whose team includes only a non-technical cofounder, how much equity should an incoming technical cofounder get?

Technical cofounders, remember that the number of shares or options doesn't matter, just your percentage ownership (what the chart shows).

Assumptions

For this case, I assume the non-technical cofounder has already contributed significantly to the business and will likely get more equity (in this chart their minimum ownership is 50%). This doesn't have to be the case. Technically inclined people can definitely build something on their own, and then seek a non-technical cofounder, retaining more equity for themselves. Even if the technical cofounder doesn't prototype something first, they can still contribute more to the business and receive more equity (ex: someone who did marketing for 2 years out of undergrad manages to recruit a top 10th percentile programmer with a successful app in the iPhone app store).

I assume both the non-technical and the technical cofounders are compensated equally. I also assume they are either working on their company full time now or will be soon. Compensation is probably between $0 and a ramen salary. This is an area that varies widely and can significantly impact how much equity a technical cofounder receives (if they take more salary). It's beyond the scope of this post, but I'll try to cover it in the future.

I assume the technical cofounder has a reasonably general set of technical skills and can pickup new technical skills quickly. Ex: they're primarily a back-end programmer, who can code basic front-end specs, and who can administer cloud hosting.

I assume both cofounders will be diluted equally as more employees and investors get involved.

Finally, I assume this chart may be a little surprising to non-technical cofounders. Why should a technical cofounder get so much of the company? Especially a company based on your vision. Basically, it's because ideas aren't worth much. Execution is what matters, and in most web startups that falls on the technical founder. Software developers are a hot commodity right now, and many of them know it, so they're on the lookout for really stellar business people to partner with, not some run-of-the-mill, me-too idea having, 10k foot synergizer without any concrete sales prospects, marketing ability, or product experience. Sorry for the rant, but in all seriousness, I've seen too many good non-technical founders delay building a product for months because they're too stingy with equity.

Other Reading

Here are a few other approaches by others in the venture and tech community. There are no hard rules for this kind of stuff, so I'd recommend reading them and synthesizing with this:

• How To Allocate Founder and Employee Equity by Fred Wilson
• Fair Equity Allocation by Joel Spolsky
• The only wrong answer is 50/50: Calculating the co-founder equity split by Dan Shapiro (in response to Joel Spolsky's post)

Notes

[1] Technical cofounder starts with 50%: start by assuming the technical and non-technical cofounders will contribute similarly to the business and are taking similar risks for the business. Give the non-technical cofounder extra equity for anything "above and beyond" (see final assumption above for more). Also, here's an example calculation: 50 (base equity) - 10 (for working prototype) - 5 (has over 10k users) - 10 (has raised VC) = 25. The technical cofounder gets 25% of the company.

[2] Working prototype (not just wireframes) -10%: If a non-technical cofounder has a working prototype, they've likely assumed some risk already to build the prototype (perhaps by contracting it out). Creating wireframes doesn't require much risk taking or even really help de-risk much of the busines.

[2a] Has paying customers -10%: If the company already has paying customers, the non-technical cofounder has already eliminated a huge risk for the business; someone wants the product.

[2b] Has over 10k users -5%: If the company doesn't have paying customers, but does have some reasonable user traction (with an nice trajectory), the non-technical cofounder has de-risked the business some, but not as much as having paying customers.

[3] Non-technical cofounder has significant connections or experience -10%: Connections include: relationships with key people in the company's target market, social network connections, blog readership, etc. Domain specific experience within the target market are helpful as are more broad experiences in sales, marketing, product development, or business development (probably on the order of 5+ years outside of undergrad, grad, or MBA school).

[4] Non-technical cofounder has raised venture capital before -10%: The non-technical cofounder has done a startup before, and someone has trusted them with a lot of money. It will probably be easier to get money again. If your business doesn't need external capital, tone this number down, but it's still important (maybe -5%) because it conveys a degree of startup savvy.

[5] Non-technical cofounder has had a successful exit before -10%: The biggest predictor of future success is past performance. This could also apply to non-exit situations where the non-technical cofounder started a company that is operating successfully and the non-technical cofounder has chosen to move on, etc.

[6a] Salary upon funding -0%: No extra equity for getting a salary upon funding. It may not be a market salary, but a technical founder will likely get something if they elect to. Why should a technical cofounder take less equity upfront because they may or may not receive a salary later? In this situation a technical cofounder and a non-technical cofounder are taking similar risks; therefore, neither get any extra equity.

[6b] Non-technical cofounder has idea and vision -0%: This is just part of the job description and included in the non-technical cofounder's initial 50%. Execution is what matters anyway (see final assumption above for more).

[6c] Non-technical cofounder has MBA -0%: (this is my opinion) In the early days of a startup, an MBA doesn't help much. It certainly doesn't hurt, but it shouldn't affect equity.

[7] Non-technical cofounder invests money -5% per $10k: This is an approximation based on a very early stage valuation of $200k. The situation will vary from company to company based on who is involved with the company and what they've accomplished so far. When I think about this, I only include money still unspent when the technical cofounder joins (usually the money was used to build the initial prototype. Sometimes I adjust the equity for the "working prototype" step above).

[8] Lower limit 10%: A non-technical cofounder wants to ensure the technical cofounder has compelling incentives. I consider this the minimum if the technical cofounder is not taking a salary.

In both Git and Mercurial, there's a very easy way to browse your local repository in a web browser that I didn't know about until recently. You should really try these right now. They've already made a huge difference for me.

Browse your local Git repository

git instaweb --httpd webrick # view at http://localhost:1234

If you prefer not to use webrick, you could install lighttpd and then just run git instaweb.

Browse your local Mercurial repository

hg serve # view at http://localhost:8000

Both of these tips came from this forrst post and discussion.

It's hard to determine if a tech job board is worth watching (if you're a job seeker) or worth posting to (if you're hiring), so I made a quick visual comparison of job boards in New York City.

I used metrics that were easiest to quantify quickly through examining up to 300 recent local tech job posts on each of these sites, so you should definitely consider metrics other than what I've mentioned here (namely what types of job seekers frequent each job board). A few notable job boards are missing due to technical constraints that I didn't have time to overcome while scraping data (Startuply and Monster load some posts using JavaScript, and TheLadders and LinkedIn require logging in). I've tried to be as objective as possible, but I run Hirelite: Speed Dating for the Hiring Process, so keep that in mind.

A few notes and observations after the graphic...

What each metric means

• Cost - the cost of a single post. The life time of the post varies per site.
• Headhunter posts - the number of posts originating from recruitment agencies as opposed to from companies that are hiring.
• Typical company sizes - an estimate of the typical size of companies posting to a job board based on the company name, funding stage, salary/equity balance, and other information contained in the post.
• 20 most frequent words - the words most often used in job posts at a particular job board. Technical note: I used Lucene (and the StandardAnalyzer) to help with text processing and frequency calculations, so very common words (a, the, ...) are excluded. Additionally, some special characters were omitted from words (see observations for effects).

Observations

Keep in mind that more (and more random) samples would be ideal, but here are some preliminary observations:

First, I noticed that "c" appeared much more than I expected. Companies can't be requesting C skills enough to put it in the 20 most frequent words used Craigslist and Stack Overflow! Well... maybe Stack Overflow. It turns out, the tool I used process the text (Lucene) cut out special characters, normalizing C++, C#, Objective-C, and C all to C, thus inflating the frequency of "c".

The words "you", "we", and "our" appear very high on 37signals, Craigslist, Hirelite, NextNY, and Stack Overflow, but are much less emphasized on CareerBuilder and Dice. Are the job posts less personal or intimate? Does this matter? From looking at the posts in more detail, it seems to correlate with a greater focus on more specific requirements in posts on CareerBuilder and Dice. Note that the word "years" as in "3 years of Java experience" appear in the top 20 most frequent words of CareerBuilder and Dice; however, they do appear in the top 50 most frequent words of all the job boards surveyed.

I highlighted words in top 20 most frequent word lists that I thought correlated to technical skills or softer skills to observe the relative importance of each, but I don't see any discernible pattern. Additionally, many of the meanings of these words depend highly on their context (requirements section vs responsibilities section vs about the company section).

Initially, I thought that posts from larger companies correlated with a higher number of recruiter/confidential posts, but then I got to NextNY where many posts for positions at small to medium sized companies are recruiter/confidential posts. Maybe recruiter/confidential posts will appear in high numbers wherever they're allowed? Hirelite and Stack Overflow have policies against posts where the hiring company is not named, but I don't know of any explicit policy on 37signals (though they have no recruiter/confidential posts). Does anyone know if they have a policy about these posts?

Finally, let me know what you see in the data or if you have other ideas of what to do with this type of data. I'm considering doing some kind of analysis of how typical job post language compares to typical English - I predict probably an inordinate use of "pirate" and "ninja".

Data (including top 50 most frequent words)

37signals
Cost (single post): $400
Headhunter posts: 0%
Typical company sizes: generally medium sized companies or funded small companies
50 most frequent words: we, experience, our, you, web, have, design, team, work, development, business, can, developer, your, who, software, looking, end, ruby, new, rails, project, management, skills, working, us, strong, requirements, about, from, css, well, knowledge, front, things, technologies, jquery, html, systems, php, all, years, use, technology, some, should, projects, javascript, help, has

CareerBuilder
Cost: $419
Headhunter posts: 65%
Typical company sizes: large companies
50 most frequent words: experience, skills, management, business, technology, development, job, work, requirements, our, technical, systems, project, information, knowledge, support, must, years, software, data, have, your, team, ability, required, strong, services, security, robert, half, all, working, email, time, us, opportunity, we, sql, contact, developer, more, new, network, industry, design, you, company, system, server, application

Craigslist
Cost: $25
Headhunter posts: 46%
Typical company sizes: all company sizes
50 most frequent words: experience, our, software, development, you, we, work, skills, have, team, new, design, business, strong, knowledge, management, systems, web, c, your, java, developer, technical, years, requirements, please, ability, working, applications, environment, job, must, programming, project, all, company, data, time, technology, product, sql, looking, candidates, york, client, solutions, plus, services, from, well

Dice
Cost: $459
Headhunter posts: 51%
Typical company sizes: large companies
50 most frequent words: experience, business, skills, development, management, team, work, knowledge, services, technology, systems, project, technical, new, client, years, data, strong, design, java, support, developer, our, you, required, software, information, web, financial, have, description, working, ability, all, solutions, position, application, requirements, sales, applications, company, other, manager, your, must, title, environment, including, york, understanding

Hirelite
Cost: $100
Headhunter posts: 0%
Typical company sizes: seed stage to medium sized companies
50 most frequent words: you, we, our, experience, software, team, web, work, have, your, development, skills, new, looking, design, engineer, from, environment, applications, java, years, strong, technology, get, working, plus, senior, about, us, technologies, developers, who, systems, ruby, javascript, can, business, product, platform, people, like, engineering, building, what, want, understanding, technical, other, developer, company

NextNY
Cost: $0
Headhunter posts: 43%
Typical company sizes: seed stage to medium sized companies
50 most frequent words: experience, you, we, work, have, our, skills, your, team, development, new, web, product, business, working, strong, client, management, media, from, apply, all, clients, project, online, data, software, ability, looking, design, marketing, can, years, technology, us, time, sales, including, high, company, about, requirements, must, technical, services, environment, who, advertising, please, lead

Stack Overflow
Cost: $350
Headhunter posts: 0%
Typical company sizes: generally medium sized companies or funded small companies
50 most frequent words: you, experience, our, we, development, software, work, team, have, c, skills, new, systems, from, web, technology, design, your, knowledge, strong, working, developers, programming, java, developer, looking, applications, environment, years, technical, high, including, code, business, application, management, about, projects, technologies, all, ability, well, requirements, performance, media, engineer, us, science, more, computer

These tricks have saved me a lot of time. Many of them I started using after reading this Definitive Guide to Bash Command Line History by fellow Hacker News reader, pkrumins. It includes a much deeper look at history than the quick examples I cover here. 

Search Your History Quickly

No more history | grep ... or hitting the up button 20 times. Just open a command prompt, press Ctrl-R, and begin typing a word in your command. As you type, the most recent command matching what you type will appear. To continue searching backwards in the history, hit Ctrl-R again. Then hit the left or right key to edit the command or hit enter to run it. 

Increase Your History Size

Once you know how to search your history, make sure your commands stick around for a while. By default, the history size is pretty low, usually only 500. To increase your history size, add the following to either ~/.bashrc, ~/.bash_profile, or /etc/profile:

export HISTFILESIZE=1000000000
export HISTSIZE=1000000

Analyze Your History

Once you've built up a sizable history, analyze it to determine possible aliases that will reduce typing time. To see the top 30 most used commands, run:

cut -f1 -d" " .bash_history | sort | uniq -c | sort -nr | head -n 30

To see the top 30 most used commands including arguments, run:

sort .bash_history | uniq -c | sort -nr | head -n 30

Stop Getting Annoyed When You Forget sudo

I used to get so mad when I forgot to sudo a command, especially a long one. Not any more. To repeat a command using sudo, run:

sudo !!

Reuse Arguments

Say you want to backup a file then edit that file. Here's how you can reuse an argument from the most recent command:

cp a-very-long-file-name.txt a-very-long-file-name.txt.bak
vi !^

Also, you can use !!:N for the Nth argument, !!:N-M for the Nth to Mth arguments,  !!:$ for the last argument, or !!:* for all arguments.

Self Promotion

If you're a software engineer with Linux experience in NYC, consider coming to Hirelite: Speed Dating for the Hiring Process tomorrow evening (4/27).

I realized I made my first Delicious bookmark just over four years ago. Here's a visualization of my links. It's a decent approximation of what I know.

Update: I switched to pinboard.in after all the Delicious shutdown controversy.