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.


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.