rcoder

Not to detract from the YC experience, but I think you can create this sort of rhythm independently, too. Demos in front of a <100% complimentary audience (i.e., not your cofounder/girlfriend/parents) can be enough to force you to develop many of the habits of a successful startup (fail fast, pivot, stretch yourself, listen to customers, etc., etc.) no matter where you are.

That discipline, coupled with an honest daily status report to my team, effectively ended ~10 years' worth of my own bad coding habits (procrastination, under-estimation, and insistence on clever/perfect/fast solutions where "good enough" was in fact enough) in about a year.

The extra pressure of a YC demo day may help increase your pace in the short term, but you eventually need to learn the discipline to show continual improvement without the pressure of a room full of VCs criticizing your every word.

Maybe I'm just nitpicking here, but at a hiring rate of 0.08%, you'd have to accept resumes from ~1250 candidates, not 127. I think the OP meant 0.8% (1/127 == ~0.008), which I don't think is a terribly low number, given that he was hiring for a reasonably well-known startup.

I've been involved in a number of searches for developers at much less visible or "sexy" shops, and would say from my experience that screening 80-100 interviews for every position is pretty normal.

I don't want to get into a framework war or anything -- in fact, I'm a Django developer currently after several years working with Rails, and relatively happy with the switch.

That being said, both #1 and #2 above are plain wrong.

Django template tags are a PITA to write, have weird inconsistencies (largely due to the first issue causing them to be implemented in a very hack-ish way) and don't have access to any request or application state that isn't explicitly added to the template context. Rails template helpers are powerful, easy to write, and ubiquitous. Those properties also make them easy to abuse for functionality that should absolutely be in a model or view function.

South, on the other hand, is powerful, complex, and not part of the Django core. That simple fact immediately makes is less useful. Any Rails developer (and by extension, any Rails codebase) will be familiar with AR migrations. No extra dependencies, training, or versioning issues to worry about.

I mostly agree with #3, though I definitely still find some funky edge cases with Django form validation. They aren't a terribly gently introduction to the "Right Way" of doing form handling for someone more comfortable with HTML than Python, either.

A clear ticket queue and test suite are indicators of good habits, but they have nothing to do with getting work done. You might as well promote a prep chef based on the cleanliness of their line station, or an accountant based on how many spreadsheet cells they filled in during an average week. Best practices and good intentions do not magically translate into value.

This is where you need a smart, ambitious CEO with a strong vision. They place the goalposts so that everyone can measure their own progress and contribution, as well as that of their group. It also gives investors and shareholders something on which to evaluate the company other than simple financials.

There are several options here. First, you could use the Django "sites" framework, which has the advantage of being idiomatic and familiar to other Django developers:

http://docs.djangoproject.com/en/dev/ref/contrib/sites/

Second, you could define a database backend per customer (using the Django 1.2 multi-DB support) and write a custom database router that is aware of your custom FastCGI environment variables:

http://docs.djangoproject.com/en/dev/topics/db/multi-db/

Third (and best, IMHO) would be to run separate FastCGI processes for each customer, and route appropriately from Nginx. This approach is obviously the most complex setup, but it has the major advantage of letting you run every customer's FCGI backend under a different user id, offering yet another level of protection against data leakage and other security issues.

This is actually a great tip -- cast iron is not only great to cook in, it helps provide dietary iron, which is especially important if you're eating a diet light in red meat (which naturally contains iron) and prepared cereals (which tend to be fortified with it).

Does anyone else find it interesting that the actual underlying bug causing this data loss is related to what seems to amount to a stateful variable? I.e., the "reference to [a] timer is kept in the updater state", and the actual bug being a process which "never cleared the timer reference".

I think this might suggest an additional criteria for extra code review scrutiny in systems (like CouchDB) that are built in functional langages: any code that "feels" stateful or procedural should probably be examined with additional care, as it is the most likely to contain exactly this classic sort of stateful logic error.

The main advantage of having an official "developer" model like the N1 is immediate access to the latest OS. Google pushes updates to the developer models much faster than carriers do, which means you get all the updated features on actual hardware much sooner than your carrier-locked counterparts.

The Droid does have a physical keyboard, but after owning both a G1 and a Palm Pre, I don't really trust any sliding keyboard mechanism to not get crunchy and/or loose after a few months' use.

You can already do this using Rhino, but it isn't a huge win without idiomatic library wrappers that make the Android Java APIs a little less Java-ish.

This is exactly why a candidate with an active GitHub account will always get fast-tracked through the screening process any time I'm involved in the hiring process. It doesn't matter if the projects there are 40-line utility scripts or heavy-duty middleware; the important thing is how they indicate willingness to write and share your code.

(Of course, if the code on a candidate's GitHub page or blog is terrible, that tells you something too...)

Actually, you can round-trip users through Mobile Safari and process payments however you like. (For example, Amazon does exactly this for the Kindle app.) Users simply can't click a "buy" button in your app and have it pass through a processing system other than Apple's.

I've observed this on my laptop and iPad. Subscription content is only available on the Kindle hardware.

Sadly, this means I'll probably be canceling my NY Times subscription next month, as the free iPad app offers enough content to make the $20/month Kindle-only sub pretty unappealing.

I don't really think that it's fair to blame Amazon for problems you have running their app on older hardware with a gray market ROM image.

It's hard enough to run tests on the legitimate Android configurations active on the market. Trying to account for homebrew setups like Cyanogen would be a recipe for lots of pain and effort with very little payoff.

My perspective on Seaside may be a little different, because I still remember Avi trying out many of the same ideas in Ruby, and moving to Smalltalk (at least initially) because its continuations didn't leak memory like MRI's did. I also know from personal discussions that the Smallthought guys are very pragmatic about their tools: when Squeak/Seaside were the right tool, they used it, but when Ruby, Java, Javascript, or another language/framework made more sense, they weren't dogmatic about using it.

I'm not trying to downplay the importance of Smalltalk to DabbleDB, but it was just one piece of the puzzle. The same "use the right tool for the problem" attitude seems to be increasingly pervading Twitter these days, which I think has helped as much as anything else in their improved stability and scale over the last year or so.

I don't know that I would call this a success for Smalltalk or Seaside as much as it is a win for a very smart startup who simply happened to use Smalltalk for some of their products. Furthermore, I doubt they'll be doing much Squeak hacking inside Twitter, so in some ways you could look upon it as a loss for the community.

Regardless, I have a lot of respect for the Smallthought guys. Their presence at Twitter HQ does only good things for my opinion of their business and technical direction.

This is why Net::SSH and Paramiko are so wonderful. Using the OpenSSH binaries through a pair of pipes is certainly a pain, but if you grok the protocol, either of those libraries can make it really easy to wire up secure pipes between machines.

I wonder if some sort of hybrid of the current push notifications and GCD might prove a workable stopgap? I.e., apps can register asynchronous event listeners while running, and push notifications can trigger those to give the appearance of multitasking.

If the background listeners/workers are heavily resource-constrained and subjected to limited API access, you might be able to maintain most of the battery life and performance advantages of the current single-task model, while still allowing apps to perform some amount of background processing. Any "heavy lifting" involving a full app UI, the GPU, or outbound network access could still require user confirmation and a task swtich.

Given that iPad app pricing has been substantially higher than it is for the iPhone, I can't imagine too many iPad buyers balking at a reasonable OS upgrade fee. Here I define "reasonable" loosely as "cheaper than a desktop OS upgrade", which would put the price cap somewhere in the $20-25 range.

This isn't a "virtualization possibility" for the iPad; it's a remote desktop client. The iPad has a fast but simple single-core ARM CPU, without the ISA extensions that make virtualization reasonably fast on modern Intel and AMD desktop + server kit. Virtualization would be painfully slow, and furthermore, rather useless unless virtual machines were allowed to run in the background.

Dark Horse Comics is hiring UI and Python/Django backend web developers:

http://portland.craigslist.org/clc/eng/1651760592.html

http://portland.craigslist.org/clc/eng/1651753399.html

We're launching 2-3 new substantial web projects this year, and need some great hackers to help us.

We're based in Milwaukie, OR -- just a couple of minutes south of Portland. On-site strongly preferred, but c'mon, you know you've been wanting to move to Portland anyway...

Google has studiously avoided ranking search results according to sites' ad spending. Placement in an AdWords block outside of the normal search results is an obvious compromise that allowed them to "sell" placement without destroying the value of their core search product.

Where Yelp has allegedly crossed a line is in manipulating the user-generated reviews of a site according to whether they pay for advertising, while claiming that no manual intervention is happening.

The truth is likely more murky than either party's depiction, of course; I wouldn't be at all surprised to hear that their "automated filter" does take the "ad partner" status of a business into account when deciding how many reviews to flag for moderation or removal.

Of course, you're right to suggest that at a certain level, Yelp can do whatever they want. They just shouldn't misrepresent what you're buying with your ad dollars.

I mostly agree with you, but, just to play devil's advocate...

How exactly would you propose cramming a usable Python runtime into a download that was substantially less than 1.5 MB in size? On the OS X 10.5 box I'm sitting at right now, the 'libpython2.6.a' static library from my source build of Python 2.6 is over 6 MB. The actual 'python' binary is nearly 2 MB, and stripped of all debugging symbols, still comes in at about 1.4 MB.

If you had some really good compression, and included only a small part of the standard library, I can see getting a CPython package in around the 2-3 MB mark, but not much more.

I think you could get well into the "people are paying money for this service" stage of a hosted Django hosting platform without ever having to touch C. Python is fast enough to do most of the systems-level programming you'd need for such a beast, especially since so much of the standard library (socket, struct, asyncore, subprocess) sits directly on top of the fast POSIX syscalls you'd be invoking to do the same work in C anyway.

Going down to the metal may help squeeze the last 10-20% out of your hardware, but the the really interesting and challenging work in coming up with a scalable hosting platform is elsewhere: security, monitoring, process spawning/reaping, deployment, et. al. If working in Python gives you a time-to-market advantage, then go for it. You can hire a C hacker when you have enough business to make the improvement in your hardware utilization efficiency pay off.

You know what's even better? When someone who writes that style of code (in C++, no less!) knows that one of the intermediate values could be null, so they use a set of macros involving setjmp and longjmp, and trap SIGFPE, all to implement a fragile sort of try/catch for null de-references.

Clever? Insane? Horribly un-portable and prone to breakage depending on compiler, libc, and OS versions? All of the above!

(And yes, I have seen this coding style used in multiple projects at a major corporation. It was a favorite of a coder-turned manager, which means it tended to sneak in on any project he supervised.)

Farmers are the original pioneers of "renewable energy." Their main energy source is sunshine, converted directly to foodstuffs by some amazing works of generic engineering (a.k.a. "plants). Biofuels? Yeah, they've been burning corn and vegetable oils for decades. Robots? How about biological labor aids -- horses, herding dogs, chickens, etc.

Regardless, there's a reason you seldom hear "comfortable" and "subsistence farming" in the same sentence. Growing enough food to feed yourself is a full-time job, even with modern agricultural tech. Yeah, there could be a singularity-style event that makes traditional farming obsolete, but RepRaps and Roombas ain't it.

I for one took "working at Starbucks" to mean "sitting at Starbucks, working on my laptop."

Weight matters more if you tend to walk or bike around a lot. Carrying a 6+ lb. mobile workstation from your desk to your car and visa versa isn't much of a burden, but schlepping it around on your back for an hour or more on a regular basis can cause serious back and shoulder pain.

Ergonomics are important when you're either sitting in front of a computer or carrying it on your back for 90% of your waking hours.

This concept really resonates with me -- my girlfriend and I bought a house recently, motivated by a combination of the tax credit, ever-increasing rent, and a desire to be able to plant, build, and remodel to our hearts' content.

Having a proper workshop in the garage and garden plots in the yard is important for me. I grew up "hacking" on physical objects just as much as computers, so being stuck indoors with only computers and small gadgets to work on always felt oddly limiting.

At a fundamental level, home improvement and micro-scale agriculture offer many of the same sorts of problem-solving challenges as coding. Plus, it's a lot easier to get other people interested in your latest kitchen remodel or crop of produce than the SQL optimization you pulled off at work.

Owning your own place can complicate the pseudo-nomatic lifestyle that a lot of developers seem to thrive on, but it can be totally worth it if you want interesting problems to solve outside of the digital realm.

I'm currently working on a team that switched from PHP to Python+Django for web application development a little over a year ago. Since I've been writing Python code longer than PHP (8 years vs. 6 or so), I can't really speak personally about what the transition is like, but I can tell you about what I've observed and heard from other members of the team.

In general, the Python language and tools tend to steer you in the direction of writing cleaner, better-structured code. Working with Django also gives you access to a lot of decent 3rd-party applications that you can integrate into your project, and the Python stdlib absolutely dominates PHP in terms of scope, quality, and consistency. Having the bytecode compiler and libraries that provide better data structure and algorithm in app servers also opens up the door to a whole bunch of performance optimizations that are difficult to accomplish with PHP.

That's not to say that the Pythonic way is always better, of course. PHP encourages a very iterative approach to development -- at a basic level, you're creating a static page, then incrementally adding dynamic behavior until it does what you need. Python apps tend to put the code front-and-center, and output HTML (or JSON, or XML, or whatever) as a last step in the process. In the long term, that's usually a Good Thing, but it can make the prototyping and learning processes longer for some people.

No offense, but putting critical financial data like invoices into a schema-less datastore strikes me as short-sighted and risky in the extreme. Best case, you're making a bunch of extra work for your accountant; worst case, you could completely fail to impose the structure needed to do basic reporting and billing. Financial data is highly structured already; I'm not sure why you'd throw away all that nice regularity and structure in order to save a few inner queries.

Also, in the case of a simple blog app, I don't think that contention is going to be your biggest worry. The on-disk structures for CouchDB are append-only, so your biggest worry isn't going to be locking, it's going to be the stale document revisions taking up disk space between vacuum operations, and the replication overhead for all the intermediate versions.