Managing resources

Today, I reached a new milestone in my life-long attempts to improve my resource management and planning skills, and I wanted to share.

I wanted a bagel for lunch, and found that not only did I have exactly one bagel, I also had exactly enough cream cheese to cover that bagel. Exactly. No tiny amount left over to dry out in the container, and not so little I had to spread the cream cheese very thin onto the bagel.

I may never achieve this again, but one must keep trying.

Why old media always loses, part MMMMMCL

Last night, I was checking out Hulu (no link for those idiots) on my office PC and was happy to see a show I watch had a new episode. So I went upstairs, hooked up the tablet to the TV and got ready to watch.

But the new episode wasn't showing.

Heck, the whole show was completely MIA.

After muttering "WTF" a few times, I drilled down into my options in the Hulu app and saw each thumbnail for that show read "Web Only".

I am not making this up. I am allowed to watch a show on my computer, but I am not allowed to watch that same show on my tablet. Both using the same IP address and the same (paid) account, so presumably at home (not, god forbid, daring to watch a show while commuting or at a friend's house).

How exactly does this help anyone? The producers, the actors, the fans, Hulu? Who gains from this bullshit? Nobody.

The people making deals at old media companies need to retire already and put people who actually get the internet in charge.

Who says the enterprise software world isn't eccentric

Get a load of the crazy wild outfits these enterprise software guys are wearing. In public, no less. Pretty bold statement if you ask me.

A new startup

Inspired by the success of so many other start-ups in the red-hot monthly subscription, food, and cloud-based logistics-as-a-service (Laas) spaces, I have decided to jump into the fray and revolutionize the stuffy world of high-end international teas with my new venture, Senchabox (getsenchabox.io).

At the intersection of luxe, gourmet beverages, social and high tech, Senchabox offers an amazing selection of socially-curated, organic, fair-trade teas from around the world, delivered monthly in a handsome gift box ethically made out of fast-growing bamboo and natural latex from recycled tires. Twice a year, subscribers get a bonus mystery Senchabox containing a selection of teas especially curated by Senchaboxers whose impeccable taste has garnered the most badges through in-app game mechanics.

For $99.99 a month, subscribers receive 2 ounces of the most exquisite teas imaginable from all corners of the planet. 

Check out our home page:

My co-founder Richard Head and I will be co-CEOs--he's more of a biz dev guy, and I'm more of a geek, so it's an epic marriage of equals with fantastically complementary skill sets. We're pre-IPO at the revenue stage with a very promising pipeline of brands highly engaged in leveraging our powerful, highly disruptive distribution platform to increase their social reach. We've set up shop in an awesome co-working space in the heart of SoMa in San Francisco, with an amazing open floor plan and a fully-stocked kitchen replete with raw organic fruit and nuts and catered lunches every day.

Our fulfillment center is powered by a homegrown high-availability real-time non-blocking event-driven Clojure app on top of a lightweight SOA Node.js backend written in Coffeescript. All our warehouse employees are equipped with top-of-the-line iPads running our custom order management app to fill orders at the speed of light.

We're looking for superstar Ruby on Rails experts with significant large-scale cloud experience (Heroku or EngineYard a plus) to take us to the next level. 

Every dev gets complete latitude in their choice of awesome workstation (either a 27-inch iMac or fully-loaded Macbook Pro; we're proudly non-corporate and therefore Windows-free, and we take Steve Jobs' exhortation to "Think Different" very seriously). 

We offer full health, dental and death benefits (including your spouse or domestic partner), and we don't meter vacation time as long as you bring tea back from your trips. We also plan to encourage every Senchabox employee to take a 2-year sabbatical doing charitable work in devastated regions of the world (one of our founders recently spent 18 months in AIDS-ridden Swaziland training the locals on Twitter and Foursquare using hand- and solar-powered One Laptop Per Child computers).

Think you have what it takes to join our elite group of product, design and hacking geniuses to change the world and take on really hard problems on a daily basis? Apply now by DMing @http417 on Twitter (be sure to include your resume as a Dropbox link).

(inspired by a long gallery of near-identical start-up home pages I compiled today).

Moleskine goes public

Moleskine just went public in Italy. Expect to see overpaid San Francisco hipsters ceremonially burn their notebooks in the final bonfire at Burning Man.

Of www. and not-www.

For a couple of years around 2008, it was briefly totally unhip to use www. in your domain. Like, total luddite heretical uncoolness. All the RoR cool kids were even adding apache nginx rules to redirect www.example.com to example.com. "Www" was that bad. Anathema. A relic.

People were really passionate about that, too. 'What do you need www. for? It's stupid!! It serves no purpose and must be eradicated!' Sure, you don't really need it. To add insult to injury, "www." makes you type four things you don't need! The horror!

Never mind that most mainstream browsers have had keyboard shortcuts for years that let you just type "example" and fill-in "www." and ".com" (and other TLDs) for you. I never, ever type "www.", and neither should you.

Today it became apparent those shortcuts aren't well known, so as a PSA I'm making a handy list below. It should work in Firefox and Chrome, and possibly Internet Explorer, but notably the bearded nerds who really really care about eliminating "www." tend not to use IE so much, for some reason. Here goes.

"example" + ctrl-enter = www.example.com
"example" + shift-enter = www.example.net
"example" + ctrl-shift-enter = www.example.org
"example" + cmd-shift-backtick-ctrl-enter-space-esc = example.io

You can even customize what gets filled in, at least in Firefox. Or if you really hate www. you can turn it off entirely, so it never ever ever gets filled in, not even by accident.

So the anti-www. Nazis and the people who don't really get riled up about bullshit niggling details and don't mind observing 15-year precedents in the Web's young history can both be happy.

Technology, you're doing it wrong

I'm watching old Beavis and Butt-Head episodes on Hulu (that's right), and so far I've seen two commercials that made me go "wtf".

The first is an ad for a Lifetime reality show about two women whose job it is to fit and sell bras to very large-chested women. I am not making this up. It's called Double Divas and it's real. The best part is that they aired a commercial for a show about heh heh heh boobs heh heh heh on a women-oriented channel during a Beavis and Butt-Head episode.

But the second ad is what made me scratch my head. It's a long, expensively produced ad about how DirecTV is better than cable TV, because--get this--DirecTV lets your DVR record up to 5 shows at once, v. cable that only lets you record one.

It's 2013, the web is pretty grown up, bandwidth is pretty cheap, everybody has multiple computers and phones, and the media carriers are competing on who lets you record more shows at preset times. Never mind that all that content you have to record at the time they decide to air it is sitting there in digital form in large data centers, and there's absolutely no technical reason why you have to 1) record it in the first place or 2) watch it at a particular time. (ok, for DirecTV there is, because satellite bandwidth isn't quite the same, but cable providers? please).

To truly grasp how absurd this is, imagine this scenario. Say you want to watch the Gangnam Style video. In order to do that, you have to do one of two things:

• log on to YouTube on Friday at 9:30pm and watch it then
• set your computer to record YouTube on Friday at 9:30pm so you can watch it later

If you don't, you can't watch it. If you go to YouTube on Saturday at 11am, no Gangnam Style for you--you can only watch Dirty Loops.

Or take Amazon's Kindle library. Say I'm downloading War and Peace onto my Kindle, and my wife wants to download Infinite Jest onto hers. And then War and Peace, why not. Does either one of us have to stop downloading a book for the other to be able to download one? Do I have to stop reading for my wife to download her book? Of course not. That's absurd.

Yet that's exactly the kind of restrictions you have when dealing with TV content, and the providers are touting half-assed solutions ("record 5 shows at once, not just one like those idiots!") to a non-problem like it's the second coming.

One of the beautiful things about digital media (and I include email in that bucket) is that it's asynchronous. A piece of digital media doesn't really exist as a single physical object, and it doesn't obey the laws of physics like, say, a library book or a movie theater do. Once a library book is checked out, you can't have it until it gets returned. If 1,000 people want to watch Bat-Man at the local theater, the theater has to make up schedules and force people to show up at 8pm, because there aren't enough projection rooms, reels and projection guys to show the movie to 1,000 people at different times. None of that is true of digital content. Sure, there are physical aspects to it (data centers, routers, CDNs, bandwidth, etc), but those are so far removed from the actual experience of the content they are basically irrelevant. If I lend you my book, I can't read it while you have it. When we have an email conversation, we can both read it at the same time, we can give it to thousands of people and still have it, I can send it at 2am and you can read it three days later. 

Digital content doesn't really exist. It's everywhere and nowhere, all the time and any time. It doesn't need to be recorded. It doesn't need for you to book your 8-9pm slot on Friday night to be enjoyed. It just needs to be requested and delivered, whenever I want, wherever I want. I'm not being an unreasonable spoiled brat here--I barely watch any TV anyway--that's just the way it already works.

So just remove the recording step. Make the DVR go away. Just let people do what they want--turn on the TV, and pick the programs they want to see. For the anal retentive, and to help you manage your bandwidth so you can precache the stuff on the viewer's TV/computer at off-peak hours, throw in a scheduler that lets people say "oh hey, I think I'ma watch Dexter on Saturday". That's it. The DVR as a free-standing device has no reason to exist. Stick a storage device inside the TV for caching and buffering, and forget about this scheduling and recording business. Call it all-you-can-eat-on-demand-TV-holicapalooza, package it as a revolutionary new thing and hope people don't realize it's just a better YouTube. I'd buy that.

But don't try to make me care about, much less covet, a digital recording "service" that's mired in the way things worked in the 1980s. I'll just torrent the stuff until you figure it out.

The 5 Stages of Design

I'm a terrible designer. Hell, I'm not a designer at all. I can usually tell when a UX is good or bad, and I know what I like, but when it comes to producing designs, I'm useless. My only saving grace is that I know that and let others do the pretty.

Sometimes, though, it's easier to explain something with a picture than a bunch of words. So I bust out the Paint.NET and try to line things up well enough the idea is conveyed, but sloppily enough it's obviously not a final mockup.

In my early days at Crunched it took a few interesting conversations to get that process fine-tuned to work with our designer. I was unaware of the torment I was putting her through. Now we've agreed that...

• this is not my job
• it's still ok and moderately useful for me to do graphics every so often to convey an idea
• it's ok to laugh at them

Inevitably, though, when I present my "work", there's some trepidation about what horrors will be shown, and (legitimate) questions about whether what is seen can ever be unseen, etcetera. So today we identified the five stages of design:

1. Denial. (e.g. "WTF IS THIS or YOU CAN'T BE SERIOUS")
2. Grief (e.g. "MY EYES!!!!!!!!")
3. Mockery (e.g. "LOL")
4. Acceptance (e.g. "Ok, I see what you're trying to do here")
5. Improvement (e.g. "I'll make it pretty")

I wonder how common this is for designers.

A year and a half: a look back

It's been almost 18 months since I was thrown into the fast and furious team at Crunched and I thought I'd lay out all the many, many things I've learned.

Technology

I was originally hired to run the product side of the organization for our nascent online meeting platform. Feature development, user feedback, market research, usability, that sort of thing. As a long-time engineer, I also dabbled in some of the tech, but from the outside looking in. Part of it was my lack of familiarity with the whole stack (Ruby on Rails, node.js, CoffeeScript and a bunch of other things I hadn't used in my LAMP / Java / Windows past), and part of it was a very clear, if passive-aggressive, intimation that my tech input was not up to snuff and/or not welcome here. A few months into it, though, I inherited the whole engineering team and I had to get up to speed fast.

I'm still not completely up to speed, at least not nearly as much as I'd want to be, and definitely not when it comes to the subtleties of the front-end code (which I don't really want to deal with anyway, because browser development will make you mad). But I have learned a few things. Here are some thoughts, in no particular order.

• Github is one of the best programming tools I have ever used. The initial setup is awkward, and account/organization management sucks, but the stuff that matters is pretty damn amazing. 9/10
• Git is a lot better than svn and miles ahead of cvs. It lets you do a lot of things that are very difficult, cumbersome, error-prone, and/or impossible with those other systems. Its user interface, however, is  abysmal, its man pages are completely unintelligible, and it's a bad tool in the sense that it makes it 1) extremely easy to shoot yourself in the foot and 2) very hard to recover from said shooting. That said, once you get over the nomenclature and into a good branching hygiene groove, it's great and I wouldn't go back. 7/10.
• Trello is the best, hands-down, project management system I've used. It's not perfect, and they ship bugs almost as often as new features, but it's free (for now) and the pros outweigh the cons by a lot. Brilliant stuff. 9/10.
• Pivotal Tracker, on the other hand, is horrible. The real-time updates are great, but its nomenclature is all wrong, it forces you into one dogmatic workflow, it's very noisy, the UI is backwards (progress is bottom to top, right to left) and it does way too much stuff magically without letting you change it (e.g. you can't reorder "done" stories, which makes it hard to package release notes). I'd rather use bugzilla and sticky notes. 1/10. 
• ZenDesk may be great for customer service, but we used it as a bug tracker, and for that it sucks. The UI needs a lot of work--search isn't very good and most of the defaults are counterintuitive. I won't grade it because we didn't give it a chance to shine, but if you're thinking of using ZenDesk for bug tracking, DON'T.
• Ruby (the language) is becoming my favorite. The syntax is very expressive, and there's a bazillion libraries out there to do pretty much anything you want. It's a little slow and changes between versions are a little abrupt, but I still give it a 9/10 because it's so close to ideal in so many ways. And I'm still barely functionally literate in it. 
• Ruby (the tech ecosystem) is a mixed bag. The availability of gems is great, but package management is all over the place, and rvm is a plague upon the world. It's an awful solution to a self-inflicted straw man of a problem. 6/10.
• Ruby (the human ecosystem) is about the same. Some folks are really great (my team, Avdi, JEGII, and many others) but there's a lot of vehemently vocal douchebags and dogmatic tunnel-vision idiots who think reinventing the wheel in Ruby is a necessary endeavor because anything written in non-Ruby is by definition lame. There's also a dangerous enthusiasm for hacking all the things !!! and trying out lots of different new technologies just for the hell of it when some of us would like to actually deliver stable product and tangible value to customers rather than jack off to the shiny new DSL for generating a/b-testable webforms with automatic conversion tracking in the Rails-powered real-time analytics SaaS startup of your choice. Because who gives a flying fuck? Developers need to remember they are not their customer, by and large (unless they make a living writing tools) 6 5/10.
• Rails is clever, and was once pretty revolutionary, but now it's mostly annoying. It's headed up by an insufferable douchebag, it's bloated, it does way too much automagically, and it's almost impossible to know what the hell is actually going on in your app without a cadre of equally bloated tools and a divining rod.  The result is a bunch of mollycoddled self-centered Rails devs who have no clue about anything yet feel strangely superior and entitled to inflicting their opinions on everyone and dismissing valid questions or criticism with hackneyed dogmatic mindless hand-waving catchphrases, like zombified Moonies on Ambien, so self-obsessed they forget their primary duty is not to their own comfort as developers but to their apps' users, who ultimately pay their salaries and their Apple tithe. (note that vast hordes of LAMP devs are equally clueless and write even worse code, but at least they don't have the attitude). But every other blog post / tweet about Rails feels like a massive circle jerk and my brain needs a shower after reading them. Thankfully my team is pretty much the opposite of that attitude.

Aside: my main problem with Rails and its brainwashed proselytes is that their catchphrase, "Web development that doesn't hurt", is a false promise that misses the point. 

• It's a false promise because the painful part of web development is client-side, not server-side. Sure, Rails is integrated with front-end stuff, and its proponents are embracing tech that addresses that pain (SASS, jquery, or irresponsibly pointless and counterproductive Ruby-fanboyesque exercises like CoffeeScript), those technologies aren't Rails, and Rails' real claim to fame is for the server-side stuff--ORM, keeping business logic out of the front-end, etc. You don't need a J2EE-like behemoth of a framework to let you crank out quality, maintainable MVC stuff. You can do that in C/cgi, PHP, perl, python, .NET, whatever. All you need is a few basic libraries and decent software development skills.  
• It misses the point because every worthwhile web application lives way beyond the web layer. There's reporting and business intelligence, APIs, and lots of other things your business needs to run. Sure, you can do BI and analytics in Rails, but once you have sizable data sets you just can't anymore, and you have to either rip your web app apart or duplicate the Rails business logic in some other language to process the data that's modeled and mapped so tightly to your web-specific code. From that perspective, Rails is not nearly the step forward people claim it is, because while it (sort of) forces you to keep the business logic out of your views, your business objects are still very closely coupled with your front-end application, and if you're lucky enough to get scale, you're just as screwed with your Rails app as you were with your [other tech]-powered web app and Rails doesn't help you one bit. Of course I know you can write SOA and RESTful APIs in Rails, but if that's your counterargument then I urge you to re-read this last paragraph because you missed the point entirely.
• Lastly, Rails has made it a badge of honor and dev cred to be an opinionated dogmatic dick. And that's not forgivable.

So 3/10 for Rails.

• Sinatra is neat. Lightweight. Quick. Simple. The anti-Rails. If Ruby had become popular with through Sinatra and Sequel 7 years ago I probably would have jumped ship from LAMP back then.
• CoffeeScript. My lead engineer likes it a lot, and I have a lot of respect for him, because he's a brilliant tech mind. But for the life of me I do not understand the point of CoffeeScript, which is a Ruby-like wrapper for JavaScript. All it does is 1) add a step between you and gratification (compilation to JS) and 2) make debugging harder because the JS line numbers (which are what your browser tells you about) don't map to your CoffeeScript line numbers. The Ruby fetishism is singular and a little weird/creepy. It's not like JavaScript is hard. 1/10.
• Cloud hosting, by and large, beats owning, installing and maintaining your own hardware with a stick. This is my first gig with zero owned or leased physical server infrastructure, and it's not as bad or scary as it sounds. But not EngineYard. EngineYard is not for professional development. Their out-of-the-box database options are pathetic (MySQL 5.0 by default, and no support for failover), and they don't seem to grasp that professional web applications require automation--there's no API to add instances to your cluster (or remove them), so a human has to do it by hand in their web UI when you need scale; there's also no API to pull database backups in case you want to run automatic BI analytics on your own data outside of your production cluster and you have to do unspeakable hacks to pull those backups by script. I've also heard sometimes their backups quit running with no warning. Their email alerts routinely get sent 10+ minutes after the problem is resolved. And for a while their default setup wouldn't automatically run chef when you removed instances from your web cluster, leading to your LB sending traffic to instances you no longer owned, with hilarious results (I hear they finally fixed that). And they're expensive. So do yourself a favor and go straight to AWS unless you truly have no idea how to set up a basic web cluster, in which case you need to get help from someone who does, and that's not EngineYard. 8/10 for cloud/AWS, 4/10 for EY.

Update: Things I forgot

• Airbrake. It's a crowd favorite for catching app errors. It's also nearly completely useless, because there's no search and only rudimentary filtering, and you can't download full sets of errors for analytics. And it has cutesy relative timestamps ("A few minutes ago"). It feels like a product built by people who have never actually used that kind of product. If you're building an error log, the two most important things you need are exact timestamps (to correlate the log entry with an action or bug report) and the ability to grep, sort, count and do other basic things. Airbrake fails on those two absolutely elementary features. So I give it a 1/10 because I'm feeling generous.

Fund Raising and Venture Capitalists

My first tech job was self-funded and/or mostly profitable and it wasn't until the next job that I became aware of the venture capital industry. The past year has been rather interesting on that front and I'll summarize what I learned in a later post.

Remote Teams Are Awesome

A lot of people wonder how or whether we can make it work at Crunched with a fully distributed team. We have people all over: Georgia, South Carolina, Michigan, Canada, Seattle, New York, and Los Angeles. The product team does not have an office. We meet in person a couple of times a year (I'd like to do that more often). We're in Campfire and on Skype all the time. It works. Sure, it's not perfect, but I'll take this over the bullshit productivity- and morale-killing super-bright very loud open-floor-plan startup office you see all over San Francisco. Of course it's the team that makes it work, and my team is awesome. I'll write more about this later as well.

A new infographic

Infographics are very trendy. I've been dealing in Big Data for a few years now and thought I'd share some of my findings and contribute to the art and science of data visualization. Here's my first infographic, which shows very clearly that big is highly preferable to small.

Add caption