Thanks for reading!

Read Serverless Architectures at Martin’s site.

Last year I was inspired by several engineering leaders, including Camille Fournier (at the time CTO of Rent the Runway) and James Turnbull (CTO of Kickstarter) to roll-out ‘career ladders’ within the Engineering organization at Intent Media. The technology team grew large enough, and aged enough, and changed enough that the team members lacked clarity about (a) what expectations everyone had of each other’s work; (b) what opportunities people had to grow within the company; and (c) what areas of their work they could focus on in order to best move into those new opportunities.

I read how various teams overcame these challenges (especially Rent The Runway’s work here, here and here, and Kickstarter’s work here) and created, with the assistance of the rest of the organization (especially PJ (Paul Julius), CTO), our own version. In the spirit of giving back to the community that helped to inspire me, I present our model here. Enjoy!

Download – Intent Media Engineering Ladders

To set a little context here – I’m working on a brand new product with a friend of mine. We’re about 3 weeks in and have a very early, very rough, prototype of a small amount of what we want in the MVP. I thought it was too nascent to be able to get user feedback on but I was convinced by Pierre Wooldridge, one of the Test Tube organizers, to try out his meetup anyway.

Taking place this time at Gilt’s office in midtown about 50 people were there. After brief introductions and a short talk from one of Gilt’s UX people we got down to business. Here’s how it works:

• Everyone there is organized into a first pair, who I’ll refer to as Ms Green and Mr Red.
• Ms Green has 7 minutes to get feedback on her product from Mr Red.
• Ms Green starts by giving the briefest context possible, and by describing the scenario she’d like Mr Red to try to work through.
• Mr Red then uses the product, vocalizing his thought process as he goes.
• When there’s about a minute left they’ll try to summarize the experience.
• Ms Green and Mr Red then swap roles, giving Mr Red 7 minutes to get feedback on his product from Ms Green.
• After both people have gone through the process all pairs are rotated (a strict clock is kept in the room) and the process is repeated 4 more times, giving each person 5 different opportunities to get feedback.

I’ve never done user experience (UX) testing before with people I didn’t already know and found the process absolutely fascinating. Even with the extremely raw product we currently have there was enough there for our opposites to give what in their minds were just their first feelings but in ours’ was insightful feedback. As an example from 4 of the 5 rotations one of the most basic assumptions that I’d already made about the product, which affects the very first screen of the application, turned out not to fit people’s expectations.

One of the truly brilliant aspects of The Test Tube is the time constraint. Not knowing the people you’re sitting with could lead to social awkwardness and hesitancy. But with only 7 minutes you’ve got no time for that and so you’re forced to plough straight in. Furthermore since there’s only 15 minutes per pair you can get 5 completely different sets of feedback in less than an hour and a half – brilliant!

I’d like to congratulate Pierre and Tom on a fantastic idea, well executed. I’d whole heartedly recommend The Test Tube to other NYC software product developers, whether in startups or established businesses.

First some very quick background. Travis CI is a wonderful, hosted continuous integration service, that is free and very easy to use for open source projects on Github.

I have a Clojure project on github that I want to build, but it’s in a sub-directory of its parent repository. It took me a few attempts to have Travis handle this correctly, but in the end it was simply a matter of doing the following in the .travis.yml file:

What doesn’t work (and which I tried before realizing what’s going on) is using before_script, or putting the ‘cd‘ call within a script line itself. This doesn’t work because Travis runs ‘lein deps’ after before_install, but before before_script (and therefore before script) and thus fails if you haven’t already changed to the directory where your project.clj is by this point.

My full .travis.yml at time of writing is as follows:

Evernote already provides a thorough Java SDK and Clojurenote doesn’t aim to completely replace it. Clojurenote does, however, implement the following:

• OAuth authentication (using the fantastic Scribe Java library)
• Basic read/write capabilities, using an OAuth access token, or developer token
• ENML to HTML translation (ENML is the XHTML derivative that is used for the content of Evernote notes)

You’ll still need to be happy mucking in with the Java SDK but Clojurenote will make a few things cleaner and easier for you in your Evernote-accessing Clojure code.

Firstly a quick introduction for those who don’t know what Evernote is. It’s a tool for easily capturing pretty much any thought or content that can be put into an electronic document, tracking it however you like, from any device, on-line or off-line, with the ability to share with other people and applications.

Urrk, that’s not as quick as I’d like. I wanted to the description smaller but it’s precisely the combination of all these things that make Evernote so compelling to me. I’ll try to break them down a little.

I use Evernote for storing (at least) to-do items, reminders, emails I want to read later, web pages I want to save, travel plans, project ideas, a journal, restaurants I might want to go to with my wife, workout history, and a whole lot more. Evernote themselves like to use the phrase ‘outsource your memory’ – that describes my usage well.

One of the things I particularly like about Evernote is that it lets you organize things how you want, not how it wants. Evernote gives you a blank slate, a few cataloguing criteria, and then gets out of the way. The genius is that there’s enough to be powerful, but also little enough for you to organize, and change your organization process, as you see fit. This feature of Evernote is actually what causes a lot of people to struggle with it at first (and it took me a while to get used to), but frequent Evernote users are often of the type that once they get momentum then they find more opportunities to increase the efficiency of their lives through even further usage of Evernote.

I use Evernote wherever I am. I primarily use the Mac Desktop app, but I also use the iPhone / iPad app, the web clipper, the email bridge, etc. The off-line capability of the iPhone app is great – I can check my important to-dos from the subway and then read some articles I’ve saved.

Sharing is useful too. As a premium user I setup notebooks with my wife that we can both edit. We typically use this for restaurants and bars that we want to try out, but shopping lists are another common usage for other people. And that’s before you even start considering the business usages of shared notebooks.

Also of huge value is Evernote’s API. It means than many apps beyond Evernote’s own can integrate with my Evernote data. I’m a big fan of using Drafts on the iPhone to create content on the go. My own app, Orinoco, lets me see my journal in a more natural way and lets me capture my tweets, foursquare checkins, etc., automatically into Evernote.

Finally, I like Evernote the company and trust them with my data. Evernote rejects all indirect revenue – they only make money from premium and business subscriptions. This means they don’t have ads, and don’t do data mining on my content. They also want to be around a long time and not just ‘exit’ at the earliest possible moment.

These are all just reasons why I value Evernote as a user. There are other reasons I value Evernote as a developer and I’ll write those up another time.

(cross-posted at http://mikeroberts.postach.io/why-evernote)