Tuesday, March 25, 2014

How I Work

Technically Baltimore just did an interview with me about how I work. It was fun because I got to namecheck some of my favorite apps and practices. Check it out if you like to nerd out on tools and productivity! Excerpt below.

When you need to take a break, what are you turning to? 
My main escape is reading a lot of novels, especially science fiction. I also try to play a couple of the really immense AAA video games that come out each year (Arkham Origins was my winter obsession). Besides being really fun, there’s just so much creative stuff happening in games right now, I don’t want to miss out on the cultural moment (see my essay on the subject if interested and also Tom Bissell’s book “Extra Lives“). 
Oh also, if I get sick of reading, I try to get past level 15 of “Pixel Dungeon,” a truly excellent casual Android “roguelike” game. 
When driving or doing monotonous chores, I listen to a lot of comedy podcasts. My current favorites are Nerd Poker, Thrilling Adventure Hour, and The Andy Daly Podcast Pilot project.
The full interview is at Technically Baltimore.

Tuesday, March 4, 2014

Requiem for gb.tc

I'm a little late to write about this, but it's taken awhile to get my thoughts together. I'm so crazy busy with Staq right now that I'm going to write fast.

Last month we learned that gb.tc, one of my favorite Baltimore institutions, is going "on hiatus".  This news filled-me with sadness and I don't want the event to go by without remarking on it. gb.tc brought a lot of vitality to the city. It felt like a uniquely Baltimore institution, something that other cities would eventually import from us. I can't think of another institution that cares about helping Baltimore develop innovative industries and people. There are plenty of foundations and non-profits around town that could argue with that statement, I suppose, but my answer to all of them would be: "yes, what you're doing is important, but you're only focused on this one small piece of the puzzle", or "you are too slow-moving and focused on top-down solutions to ever make much of an impact". That, to me, was the special competency of the gb.tc - harnessing the grassroots/bottom-up energy of technologists and helping organizing it into a force for good in the city.

The general sense I get from my peers is "the tech community is self-organizing, so we didn't really need what those guys were doing" which I think is flat-out, dead wrong. It's true that Baltimore has many interesting, vibrant events, they're for the most part labors of love done by people who have other priorities besides making the city great, and they depend on the force of personality of a small group of hard-working volunteers. There still ought to be a team of people committed to growing these events and ensuring we don't lose momentum (something I called for back in 2011). For example, I helped run the first (and so far, only) RailsGirls event in Baltimore. I think we need to be doing 2 or 3 of those per year, given how long the waiting list for that event was...I just don't have the bandwidth to do it. Who is going to pick up that mantle? (Fortunately, Girl Develop It has come to Baltimore, but look at all the time that went by between RailsGirls and Girl Develop It).

gb.tc also developed deep relationships with different parts of the city - no one else was trying to connect the more entrepreneurial part of the tech community with the public sector, as exemplified by "Hack for Change Baltimore" which had strong city support. The city would not be trying to support more hackathons this year if not for gb.tc's efforts. They've also provided free startup mentoring,  the "Baltimore Weekly" podcast, amazing "Tech Crawls", and many other valuable services.

I'm not sure if I'm making sense here. Maybe go read that Innovation Community Manager post I wrote in 2011 to get a sense of what we've lost.

It sounds like Betamore is going to try to provide a soft-landing for gb.tc. I feel skeptical of the idea but I really want it to succeed - I just think there's an inevitable mismatch between the mission of a for-profit company (even a mission-driven company like Betamore) and the social-good mission of the gb.tc.

Thank you to Jason Hardebeck, Andrew Hazlett, and Sharon Paley for all of their hard work over the past few years (along with all of the other people who built gb.tc into what it was before their tenure). Your efforts made Baltimore a better place to do creative things, and we're poorer without you.

Thursday, February 20, 2014

Slides for Writing Clean, Concise, and Confident Ruby Code

Today I will be giving a talk at NET/WORK called Writing Clean, Concise, and Confident Ruby Code. Since it's very code-focused, I once again used Stefan Otte's presenting.vim. The slides (which include links to all of my references) are all up on Github.

I'm indebted to Avdi Grimm for providing much of the inspiration for this approach to Ruby, and to my Staq colleagues for letting me try out my armchair programming philosophy on them!

Monday, February 17, 2014

Web programming notes newsletter

I'm a voracious reader and student of programming. Being mostly self-trained, I consider myself very much a life-long journeyman programmer. So every week I send the dev team at Staq a few links I've come across in my researches along with a few links here and there that inform my leadership philosophy. I also throw in occasional commentary.

I decided to create a mailing list where anyone else who is interested in these links and thoughts could signup. The content will mostly involve web programming and startup life, with a focus on Ruby, JavaScript, and cloud-based services.

I promise you'll get one email per week, at most, usually on a Friday, and I'll never do anything with this list other than send you web programming notes. (My first startup was after all an email overload management company!) You can signup using this form:

powered by TinyLetter

I will also occasionally post the links to this blog (easy to do since TinyLetter makes a nice archive page of past emails). Below is a collection of the links I've sent to the team over the past year.

Monday, February 3, 2014

Staq's Ruby Apprentice Program Was a Great Success!

Back in September 2013 we announced Staq's apprentice program, where we offered paid work to novice Ruby programmers. Today we're announcing that we just completed the program by hiring four of the apprentices who went through the program as full-time software developers at Staq!
Me, my partner James (2nd from left) and the new developers
Over the fall and winter we fielded many questions about how the training went, whether we will do it again, and so on, so I thought the Internet might like to find out how everything worked out.

We received over 100 applications from around the world, many of which were from very well-qualified candidates. I was very surprised at the number of people who had a strong computer science and engineering backgrounds, who saw this a chance to jumpstart their careers or re-engage with programming after a period of time doing something else.

We selected 12 candidates to attend in-person training sessions at our office in Hampden. We conducted four sessions of two hours each where we dived right in and showed the students the guts of how Staq's data extraction technology works, along with the basics of Ruby and rspec. In retrospect, our syllabus was far too ambitious; the next time we do this we will just focus on using Ruby to write web-and-API scrapers using mechanize and typhoeus, along with a gentle introduction to CasperJS. I should have introduced Staq's proprietary framework later in the process.

This experience also opened my eyes to the importance of good documentation: we have written a lot of specialty code that would be a lot easier to understand with good in-line documentation. So now everything we write includes extensive YARD annotations.

I regret not having more resources and time to devote to the training, since we're still a small company at this point. The next time we do this, I want to involve a professional Ruby trainer who could give more structure and rigor to the program (are you reading this, Jeff Casimir?). It would also be cool to coordinate our efforts with Betamore Academy. I wish I had been able to prepare a more thoughtful syllabus, or present in a less harried, rapid-fire manner, but such are the exigencies of startup life.

We chose five students to become Ruby apprentices, based on their performance during the training classes. The apprentices started out as hourly, part-time employees, who scheduled their work hours around other commitments. We started weekly training sessions for them (which every programmer in the company began attending), but most of the training was hands-on. The apprentices made many heroic contributions to our company, cleaning up messes, digging into details, writing critical revenue-generating code, and exhibiting great professionalism in a demanding, low-supervision work environment.

The apprentices graduated in January and we made full-time job offers to all five of them. One graduate decided to move to New York, and got a great job offer with a well-known, successful software company.  The other four accepted.

We absolutely will do this again, but we've got to grow the business some more first. Watch this space for details!

Thursday, January 9, 2014

Rockstars, ninjas, and silent technical privilege

Technically Baltimore did a nice write up of my recent appearance on the gb.tc podcast. One of the things we touched on was the continuing difficulties of tech companies with recruiting people and with attracting a more diverse set of people to the software industry. I think the best solution to both problems is for software companies to spend a lot more time and money on training people instead of trying to find the perfect person who's incredibly experienced. I plan to write more about the outcome of our own training program very soon (short answer: it worked out awesomely).

The Technically Baltimore article focuses on my off-the-cuff critique of passé, potentially harmful recruiting terms like "rockstar" and "ninja". I think that terminology unintentionally contributes to a culture of silent technical privilege that repels smart people who don't identify with those labels. The reporter also links to some further analysis of this problem, so please check out the writeup! And start using better recruiting language if you want to cast the widest net possible for talent.

Tuesday, November 5, 2013

Staying fast and good when making enterprise software

My startup Staq builds enterprise software using the techniques I've learned from building consumer web apps. As we bring more customers on and our revenue increases, we have more to lose when there's a bug in our code, and there's pressure to revert to a more traditional development process where the developers have less control. Specifically we're debating whether to move away from our current fast-paced "manual continuous deployment" process (where we're pushing code throughout the day, every day, and getting immediate feedback) to a more traditional commit-review-QA-release cycle. I have pretty strong feelings against going in that direction that I wanted to document here.

I know from experience that a process like that will inevitably slow us down, which we can't afford during this phase of hyper-growth. It can produce a boring, toxic work environment in the long run. Code you wrote today doesn't end up getting in front of a user until next week, and you've already forgotten the context to explain why you wrote that code the way you did. When there's a bug, you have to start from scratch when figuring out the problem. Feedback gets delayed, if you get it at all. 

So how we stay fast while keeping the software quality high? How do we stay fast and good?

I intend to establish a core value at Staq where we never, ever stop deploying. We make software at such a high level of quality, and our cluster immune system is so awesome, that it's nearly impossible to kill the app. When defects occur, they are so obvious and so easy to correct, that users rarely notice the problem.

In the early days there may be times when we have to compromise on this value. When that happens, I want it to feel like an ugly compromise. I want the situation to become a sign that we need to improve our systems to get back to the platonic ideal of Always Be Deploying. ("Coffee is for committers!")

Here's a partial list of strategies we came up with to make this work, most of them drawn from the lean startup movement:
  • Work in small batches: smaller changes are less likely to cause a disruption, and are easier to pinpoint when they do cause problems.
  • Don't take shortcuts: skipping tests and hacking things together ultimately add unacceptable risk and technical debt.
  • Practice five whys/root cause analysis: don't make the same mistake twice; gradually develop a cluster immune system
  • Expect 100% unit test code coverage, backed by appropriate integration and feature tests: catch problems as early as possible
  • Setup a continuous integration server: we have too many modules for any one developer to test all of them at once, so this server will become a backstop, alerting us when there is a problem in one of our modules.
  • Use Feature flags: while we are testing new features, hide them from users until they are fully baked.
  • Build staging environments that make it easy for developers to double-check their work
    • Since we're on Heroku we plan to use their awesome pipelines lab for this
    • We can also fork our database to create a sandbox for features that depend on database changes
    • This should never be construed as a required step before code can be released to production
  • Code reviews
    • Two times a day I review every commit in our system, really helps spot issues before they become problems
  • Build informative, actionable alerting systems

What else should we add to the list?