Essays from Peter Thiel’s Stanford class on startups. In a nutshell, freely available material like this is why I am a college dropout. Every essay is worth reading — queue up your Pocket. I particularly appreciated this one on markets, competition, and monopolies. (via Spittle)
How much should a custom WordPress website cost? Excellent piece by Brian Krogsgard — every paragraph rings with truth.
What I’ve learned so far about consulting work:
- Harvest feeds the OCD time tracker inside of me.
- Creating proposals is a huge time suck.
- There’s so much room for automating all of this.
10 Things We Forgot to Monitor. Great list from Bitly.
On Being A Senior Engineer. Chock full with pearls of wisdom.
How I failed: Six lessons learned. Wonderful set of insights from Tim O’Reilly. Number four is a very hard problem to solve.
Effective Technical Leadership. Rich with usable attributes and actions.
Couple of things I learned the hard way yesterday:
- When using a password to connect to an IRC server, you’ll need to join the room before you can post a message to it.
- IRC servers (or maybe it’s just ours) are quite slow to fully respond to connection requests. Like, two minutes slow.
Advantages of pre-deploy code review, over post-deploy audit:
- Authors have a strong incentive to craft small, well-formed changes that will be readily understood, to explain them adequately, and to provide appropriate test plans, test coverage and context.
- Reviewers have a real opportunity to make significant suggestions about architecture or approach in review. These suggestions are less attractive to adopt from audit, and may be much more difficult to adopt if significant time has passed between push and audit.
- Authors have a strong incentive to fix problems and respond to feedback received during review, because it blocks them. Authors have a much weaker incentive to address problems raised during audit.
- Authors can ask reviewers to apply and verify fixes before they are pushed.
- Authors can easily pursue feedback early, and get course corrections on approach or direction.
- Reviewers are better prepared to support a given change once it is in production, having already had a chance to become familiar with and reason through the code.
- Reviewers are able to catch problems which automated tests may have difficulty detecting. For example, human reviewers are able to reason about performance problems that tests can easily miss because they run on small datasets and stub out service calls.
- Communicating about changes before they happen generally leads to better preparation for their effects.
I like to think of funded startups vs. bootstrapped web sites like the split between signed and unsigned bands.
Think about what a band has to do if they sign with a major label. They write music, perform/record it, and play it. Now think about people like Prince, Aimee Mann, etc. that do every single aspect of their music themselves. They have to create and record and distribute music, but also book tours and hotels and hire roadies and even oversee building websites. On the positive side, those going their own way talk about making more money from lower record sales than they did on a label, even though they do a significant amount of work.
So it’s a lot of work, but I would argue it’s totally appropriate for anything that isn’t a huge world-changing idea. And there are a lot of benefits that come from it.