Add to this: transparent pricing. Most developers I know are highly allergic to "Call for a quote!"
For enterprise pricing, this can be unavoidable, but a ballpark is nice. Or say you can offer steep discounts in the right situation, and have me call to discuss.
nobody would be allergic to calling for a quote if calling got you a quote. problem is, it puts you in a pipeline/funnel and you still don't have a quote.
Transparent pricing and a free/evaluation tier that is feature complete but scale limited, rather than feature-gated. With that combination I can put together a really tiny "this can do X for us and would cost us Y at our current scale, potentially negotiable" demonstration, which will make the CTO sit up and listen. Without transparent pricing I'm just not going to bother (because it's the first question I'll be asked) and if you gate off enterprise features I can't demonstrate enterprise use cases.
At first glance, the colorful layout (and the introductory tone of the first page) made me think this was a brochure page for a company specializing in CRO.
It's not - it's a comprehensive and detailed 12-chapter summary of best practices and techniques. Stick with it, it's worth a read.
To the implementors: you may want to make it more obvious it's a full course, with the chapter list (or at least next/previous) at the top or in a sidebar. (I of course missed the "Chapter 1" badge and chapter list link when scrolling through.) Great work!
Gladwell seems to be making the point that doping in sports is a sort of reverse Harrison Bergeron, with the have-nots needing to "cheat" to get to the same level as the genetically gifted haves.
What happens, though, when the most innately talented (Armstrong, Rodriguez, Barry Bonds) also go in for enhancement?
This resonates with me on many levels. The main point - that clear and unemotional communication is key - applies obviously to all your relationships and not just those with a business partner.
I also like that he brings up the Puritan work-ethic canard and punctures the balloon of more hours equals more productivity. This view is starting to gain traction here on HN over the last couple years, which is for the best IMO. There is no denying that startups are hard and require long hours, but it is important to know one's limits - and macho "who works more" posturing is never helpful.
This is true - yet I'm pleased to see that the 37signals blog posts which are starting make it to the top of HN are those with more depth. For a while, it seemed like all of the ones making the front page were simple platitudes with no concrete examples or solutions e.g. http://37signals.com/svn/posts/3513-when-empathy-becomes-ins... .
What we do is to back up the staging DB, overwrite it with the current production DB, then run the necessary migrations on stage to get the schema up-to-date.
This has a couple of side benefits:
- "Dry" run of the migrations you'll eventually need to run in production anyway
- Using real production data in staging/QA (as long as you're allowed to) can uncover some edge cases you wouldn't have accounted for using fixtures or manual prepopulation.
If you follow the link to the more detailed blog post, Andrew shows how he was able to speed up the data transformation script by a factor of 60 by using ALTER TABLE statements to cast column types after the fact rather than rewriting every single INSERT. A little more dangerous perhaps, but still an impressive improvement.
