Automation for Developer Happiness

I'll be giving this talk in October of 2015, if everything works out well. I think I've described what I want to cover well, but maybe not. We'll find out.

Lazy productivity is the motivation behind automating development workflows. We shouldn't spend time with repetitive tasks, we should let computers do our bidding!

Let's cover a start-to-end development workflow focusing on developer happiness with lazy productivity, and site performance with maintainability. We'll use use bash and grunt (and gulp, if preferred) to automate tasks, and see how these tools can help us increase our site's performance. We'll also dive into scripts and aliases and other tools that will help us complete the small tasks that build up over time.

Automate Front-end Performance

Here are my slides for Automating Front-end Performance with Grunt that I gave at Fluent Conf 2015. I'll likely write it up, to give a transcript. I think the videos are about a month away. Unsure on that one.

Automate All the Front-End Things!

This talk was presented at Scotch on the Rocks on the 5th of June, 2014. This page can be referenced at Community note taking was offered at Example and demo files are at

You can download these slides at They are also available at

Notes follow the slide deck.



Installing Node
  1. Go to
  2. Click the green INSTALL button
  3. Follow directions

Install Ruby

Ruby has different flavors.

Upcoming talks!


I'm pretty excited for the next two weeks. I'll be speaking at Open Web Camp on July 13th. Afterward, I'll be heading up to Portland for Refresh PDX on July 17th.

My talk description:

CSS can do all these amazing things now: Animations! Gradients! Transforms! Yet, it’s tricky to remember every vendor prefix and, blech, time consuming to do everything by hand. Let’s take a mad dash through CSS automation with Sass and other handy tools to automate ALL THE THINGS CSS (including those amazing things), traveling but one path to a faster, easier, and more reliable way to develop websites and web applications.

A few more details:

I'm going to talk about setting up Sass (look, it's easy!), setting up layouts (see, it's easy!), variables, mixins, extends, functions, as well as namespacing. Then use Sass to do the cool things: animations, gradients and transforms, showing how Sass makes adjustments easier. I'll include LiveReLoad so that the pages update automatically when I git up to a branch to demonstrate changes. I'll mention grunt (more so at Refresh PDX, since Dirk Ginader will be talking about grunt at OWC), too, for automating other tools, such as csscss to find duplicates. And Alfred for general workflow automation, not just CSS stuff.

I'm also going to bounce a lot.

Interlink CSS Workflow

More details at CSS Workflow.

Schedule CSS Workflow.

Slides: interlink-css-workflow.pdf

Resources will be compiled shortly and posted here.


I gave this presentation at Open Web Camp at Stanford on 16 July 2011. Organized by John Foliot (@johnfoliot), Ed Palumbo (@doted), and Thomas Ford (though I interacted with only John), Open Web Camp was an *amazing* event: the speakers were incredible, the talks great, the events well organized, the location fantastic (wow, I love Stanford). Both lunch and t-shirts were provided by sponsors, and, wow, I can't adequately convey how much I enjoyed the event.

My talk was about how to build a mobile app with web technologies. I'll do a screencast shortly. In the meantime, my slides and a transcription of the talk I gave:


Upcoming Talks

Wow, do I really have nothing scheduled?

Talks I've Given

Squares Conference 2017 (slides and talk transcript)

Engineers for Engineers (slides, video, and links)
This talk, Automate Your Site's Front-End Performance, was given at Constant Contact's Engineers for Engineers conference in Waltham Massachusetts, on September 18 2015,

HighEdWeb Technical Academy, Milwaukee Wisconsin, Oct 3 2015, hands-on workshop. Automating for Developer Happiness and Front-End Performance

Hacker Dojo: Anarchy with Respect

This is my actual talk at Open Source Bridge 2011 (my session page). I wrote this post as a way to practice my talk before giving it. Included below are my slides as well as a pre-recorded version of the talk. When available, I'll include the audio version of my talk from Open Source Bridge if they allow republishing the content.

The short description is:

Imagine an open source project was an actual place: a place where people volunteer to make something better; contribute their time, knowledge and resources; a place to share ideas or just to get work done. Hacker Dojo is for hackers and thinkers and this session will describe how the open source ethos can successfully be applied to a physical space.

The full description is:

Hacker Dojo is a community center in Mountain View, California, for hackers and thinkers to meet, discuss, learn, create, build and play. More than a co-working space, more than an event space, and more than the chaos it could be, the Hacker Dojo encompasses the open source culture and spirit both at its start and in its continual development.

Starting from a small but passionate group of developers, Hacker Dojo has grown into one of the biggest hacker spaces in the world. The growth hasn’t been without its pains, the same pains that successful open source software projects go through: How do we manage a large group of people with differing opinions and personalities? How do we inspire the many to help help the dedicated few who do the bulk of the work? How do we “indoctrinate” new members into our open and inviting culture without losing their valuable contribution? How do we handle the bad apples while building our champions?

Adopting an open source philosophy from the code to the conduct has enabled our community to grow, developing into our vision of a Silicon Valley institution. Hear of our journey of “anarchy with respect,” and how open source works in physical space.

The pre-recorded version on vimeo

Hacker Dojo: Anarchy with Respect from kitt hodsden on Vimeo.

The slides:

The transcription:

hacker dojo

Hi, my name is Kitt Hodsden. I'm a founding director of Hacker Dojo.

from dusk to dawn

Back in January of 2005, a group of friends gathered together to have the equivalent of a reverse LAN party: instead of playing games from dusk until dawn, they pondered creating games from dusk until dawn.

Okay, maybe not so elaborate as building a game in twenty four hours, but definitely a party where the focus was to build something in 12 or so hours, and show it off in the morning over breakfast.

(pbworks )

Of the twelve people who started that evening, six made it to morning. From that weekend, one project survived. It's doing pretty well.


The party happened again the next month, then continued every four to six weeks after that. While the event itself grew in size, it varied in timing and location. It grew beyond the house specifically, and into sponsored locations, such as SocialText, Sun Microsystems and Google.

At Super Happy Dev House 30, in January 2009, at Sun Microsystems, we hit a local maximum of 376 people, and the organizers had to ask, what if we could have a dev house 24 hours a day? How awesome would that be?

scratch own itch

Looking around at various venues that existed, options for a 24/7 Super Happy Dev House equivalent were limited to coworking spaces where, sure you build stuff, but the sense of community where you turn to the guy next to you and ask, "Hey, I have this loading issue on my node-js project, have a second?" is sorely lacking. In a coworking space, the focus is on working, and less on the social aspects that are a significant aspect of SuperHappyDevHouse.

Other options for community include existing hacker spaces. The only problem with existing hacker spaces was, there weren't any in the South Bay where a significant number of the organizers of Super Happy Dev House lived.

¡not invented here!

While there may have been some parts of the "Not Invented Here" syndrome going one, in reality, there wasn't a space in the South Bay that had the vibe, the feel, the openness of SuperHappyDevHouse, so, like most open source project, we scratched our itch.

We created what we were looking for.

many eyes make bugs shallow

Because we started with the SuperHappyDevHouse community, and drew from an existing group of people who already had both a passion for building stuff and a tangifiable interest in a hacker space with the same feel as SuperHappyDevHouse, we were able to hit the ground running with the many eyes that make bugs shallow.

Also known as many hands make light work.

(build out )

The weekend after we received the keys to the building, we hosted a build out session. We had about twenty people show up to clean up the space and start to make it ours. The space was previously a stained glass manufacturing facility, and already had character, so we cleaned it up, painted the walls that needed painting, repaired the parts that needed repairing, like large portions of the electrical system, and received donations of tables and chairs and couches and other furniture.

patches count

When a project is starting out, and even when it's bigger, the effort and results of those interested in the success of the project is what counts most. Those most interested in the Dojo are the ones who helped it succeed early in the beginning, and helped it grow to what it is today.

In come cases, our patches were time. People came out to help with the build out, some people helped staff the facility, some people made connections for us.

Every contribution helped. We had a half dozen people sign up to be members who have never been to the Dojo. They believed in the idea enough that even if they weren't taking advantages of the facilities, they still believed in the idea, and contributed financially.

free as in speech, not as in puppies

One of the important reasons for the success of the Dojo is the financial support of the members.

Okay, you might be wondering why I didn't say "free as in beer." The issue is that with beer, you buy it once, you drink it, you're done. Open source isn't like that. You create something, you maintain it for a lifetime. With puppies, you buy it food, you pay for its shots, you pay the vet, there are a lot of expenses and bunch of time involved. It's not just pay once and you're done. Open source creating is more like a puppy than a beer.

Running a company, and the Dojo is a company, it's a not-for-profit company, but it is still a company. The company pays the rent on the facility, pays for the lights and the heat, pays for the fibre network for fast internet even with 400 people connecting three devices each, pays for building improvements.

As such, we need a revenue stream.

From day one, we charged for membership. Members pay the rent, for the lights, for the fast internet. While we do have a hardship rate for students and the unemployed, and a work-trade programs for those who have time but not the money to be a member, every member pays for the facility use.

That we had raised enough money for two months rent before we opened and that we started charging on day one was crucial to our success.

has no owner

So, yeah, members, they pay the rent, they keep the doors open. Just as ideally open source software has no owner, or perhaps many owners, the Dojo has no owner per se.

At the Dojo, any member can attend any event or be in any space at the Dojo and any time. This is true for paid events and classes. The reason the space continues to exist is because the members pay for it, so it is important that the members have access to the facility. For events such as classes, members are not allowed to be disruptive, nor are they allowed access to class materials unless the instructor is willing to provide them.

Another aspect of having no owner is that everything at the dojo is communal. People bring in items to donate, such as desks and books and refrigerators and electrical equipment and monitors. If an item is left at the Dojo, it is assumed to be communal property. Monitors and food are pretty much the only things that can be labelled and claimed. With food, you don't eat it; with monitors, anyone can use an open one, but you're asked to give it up if the owner wishes to use it.

An aspect of everything is communal is that when donating items or leaving things at the Dojo, it is understood that someone else can come along and use it, abuse it, change it, break it, or possibly throw it out. This happens and it's part of the rules.


Because we encourage experimenting, we encourage trying new things.

Fundamentally, Hacker Dojo is one big experiment. We realize a problem, we think of possible solutions, we try things. If something works, we do more of it. If something doesn't work, we try to figure out why it didn't work, improve upon the solution and try again.

When we first opened the Dojo, going for the 24/7 aspect of keeping the Dojo open was hard. We initially went with the traditional staffing model: we had a calendar where people could sign up for time slots, we published a calendar, we gave staff keys to the front door, the Dojo was open when staff was around. We had weekly staff meetings.

Yeah, you see where this is going, right?

The problem with this method, oh, yes, anyone who has worked on an open source project or even in a volunteer organizations knows this one, once a task becomes onerous, once it becomes tedious, once someone demands a certain action, meh, it's no longer fun: it's work. There isn't any benefit to the members who are staffing, it's not like they're getting paid: more responsibility but no benefits.

Yeah, not going to work.

We struggled to fully staff the dojo. Oh, sure, members who had keys were there, but they weren't staffing. Keys were copied and handed out without any tracking, sometimes to non-members. The doors didn't open, people forgot to show up or remove their signup the week they went on vacation. It degenerated into a chaotic mess.

So, we changed things up. We experimented.

A maglock was installed on the front door. Anyone who had been a member for 60 days (now 30) could sign up for their RFID tag to gain entrance into the building. If you were willing to be available to help others, you could unlock the Dojo and open it for everyone.

This process worked. We experimented, we iterated, we found something that worked and we went with it.

rapid feedback

We've done this with other items, too.

Besides the big ones of staffing and opening and closing the Dojo, figuring out the rules we all agree to was another big one.

Initially, on this we floundered. We had our basic rule of Anarchy with Respect. Anything goes, have at it, as long as it doesn't interfere with the rights or resources of another member. People want more than that. People want rules to be well-defined so that we know we're all playing by the same rulebook. We, as directors, however, didn't want to make the rules: the community needed to define those rules.

Except how do we define how to define the rules?

Initially the staff created the rules, since the staff were the most passionate members of the Dojo and had the most invested in the Dojo since they were around the most. Quickly, however it became obvious that we had passionate members who were not able to staff, but still wanted to voice.

After a few iterations, we settled on our Polar Bear Wrestling meeting. Any member can propose a rule, a concrete, well defined, easily understood and enforced rule. The proposal time cuts off two days before the meeting. At the meeting, any member in attendance voice. All discussion happens before the meeting, so the meeting doesn't drag on. The rules are enforcable so voting is easy. Progress is made and we are able to iterate quickly.

no central authority

Removing the central authority figure, the staff, from the equation and enabling the members to control how open and closed the dojo, figuring out how to create the rules, other experiments in how Hacker Dojo operations work, they are all all part of a key aspect of the culture at Hacker Dojo, and that is everyone has the opportunity to change the rules and the authority to enforce the rules.

This is awkward for some people. Some people don't understand, "Just do it!" They ask permission first. They look for the authority figure to bless a project before just starting it.

(pink room )

The Dojo doesn't work that way.

If you want to paint a room pink as an April Fools joke, go buy the paint and start painting. If you want to install a giant Koosh ball or your airplane on the ceiling, have at it. If you want to have a Art Hack Day and make the Dojo cool, have at it.

Removing authority, telling people, "don't ask, just do," "just submit the patch already!" is a hard change for some people, but awesome for those who do get it.

oh but wait

Now, to tell you all the great stuff with Hacker Dojo and how it's the bright and shiny example of a physical manifestation of the open source ethos, without following it up and telling you also about the not-so-bright and shiny parts of the Hacker Dojo, would be a disservice to all of you, and quite dishonest.

Because it's not all bright and shiny. Where there are people, there will be strife of some flavor.


We have had our share of trolls.

In a physical space, this typically means someone is being disruptive or possibly abusive.

Every member has both the right and the responsibility to enforce the community set Hacker Dojo rules. The facility is, however, open to the public. We allow guests of members as well as non-affiliated visitors. We don't have a filtering process that judges people who come in, we assume everyone is good until they prove otherwise.

And, in some cases, they do prove otherwise.

We had one homeless fellow who moved into the Dojo. We don't allow storage of items, recall anything left at the Dojo becomes community property. When he was (rightly) confronted about his stuff being stored at the Dojo by a member, he became hostile. He started yelling, he started cursing, he started accusing all the members within earshot of being "With the Man" and "beating his people down."

It can be hard to be calm when someone is screaming race in your face. The best thing you can do is to ask him to leave, and help him out the door when he obliges. Which is what we did: I asked him to leave, another member moved him and his stuff to a homeless shelter.

We had another case of a member who never showered. He would sit non-stop all day in one of the small offices we have, to the point where the room smelled so bad that even the member couldn't use it after two days, so he'd move to another small office and repeat.

Technically not against the rules, but sleeping in the Dojo parking lot, and parking for more than 48 hours straight in the lots were.

Yeah. At this point, I became the bad guy.

I asked him to leave.

This is the equivalent to banning in most open source projects. A community polices its own, and in this case someone who didn't fit in, his ideas or methodologies didn't fit in with the direction the project was going. It happens.

But the cases aren't always so cut and dry, so obvious, that, okay, let's kick this member, this contributor, out..

Early in the beginning of Hacker Dojo, a lot of communication was across the mailing lists. We had one person jump on the list and ask if we could accomodate his specific project in the space. His project was outside of our expected and supported hardware and software development spaces.

Now, we had specifically said, everything was communal, no one could claim a space for himself, set up shop and bar everyone from using the space. Given that everything is communal, we couldn't guarantee his project wouldn't be touched, altered or destroyed. Worse, he couldn't guarantee the safety of the remaining membership should his experiments, um, explode or spill.

When some members said no, we weren't going to accomodate his project. When this happened, the person became a little aggressive, possibly a little hostile, depending on how sensitive you are.

Eventually, we called him on it. We gave the answer we have learned to give for people who have crazy, though potentially awesome, ideas that in the future could work wonderfully in our space: lead the project: tell us what it is going to take for your project to succeed, develop a game plan, put in the safety measures, find supporters, work up a budget, start the fundraising, make it happen.

The community defines itself. If the community decides it wants to become a metalsmithing shop or an experimental biology lab, it'll become that, because that's what the community wants.

all talk, no action

Another aspect of open source development we encountered, an aspect that is also found in just about every volunteer organization ever, are the troll subspecies "we oughta."

The we-oughtas clan is often very vocal, they know what we should be doing. When it comes to the actual _doing_ however, they aren't around, they aren't available, or that's not what they meant.

When this is the case, the response is either, that's nice, and ignore it, or, just as in open source projects, "put up or shut up." Essentially, if you're not willing to put forth the effort of leading your own project - even if that leading is just finding someone else to lead your project - we're not going to follow.


Any group over the size of one starts to have politics, the manuevering of positions to create opinion on your side of the issue.

For the most part, we believe in the anarchy with respect motto, and that everyone at the Dojo is an adult. I'm going to define being an adult as talking with the person you're having difficulties with, you don't just ignore the problem or gossip or avoid the issue until it grows into a huge problem.

Because members don't need to ask permission before modifying aspects of the Dojo, problems do arise. We encourage people who have concerns or issues or problems to talk to other party, face to face if possible, and resolve the issue between themselves. It's surprising how many conflicts can be resolved by face to face talk.

Sometimes they aren't resolved easily, and we do have others step in. It's just part of the process.


One of the biggest elements in minimizing conflict so that everyone is moving in a positive direction is transparency. Exposing data is a first step. This is not a default position for some people, and is sometimes difficult.

We address this by exposing as much of the internal workings of the Dojo as possible. We have monthly membership meetings where people meet the other members of the dojo. We have a director present the State of the Dojo, which helps us all understand the size of the Dojo in terms of membership, as well as the financial health of the Dojo.

(numbers )

All of the rules are published on the Dojo website, with the rules being updated and changed by those most interested in helping the Dojo become a better place. We used to have a log where people staffing the Dojo could report issues of the day. We don't use the log so much any more, and I feel its loss is a detriment to the parts of the community who don't know the day to day aspects of the space.

We're iterating though. We're trying to to build that back in.

Communication is a tough nut to crack

fork it

Even with all the good stuff minimizing nearly all of the bad stuff, sometimes things just don't work out on a project. Given one of the basic tenants of the open source is the ability to copy and modify the source, and given the slide I just put up, you know that I'm going to say, if it's not working, fork it.

A huge reason for Hacker Dojo's success is based on the existence and support of the SuperHappyDevHouse community. Because of that community, we were able to gauge interest level, find people who shared a desire for a hacker space in the South Bay, and generate financial commitments to the idea.

That community made Hacker Dojo successful.

It's a model that can be duplicated.

hackerdojo code

Practically speaking, the code that runs much of Hacker Dojo is available on github. This includes our membership tracking, as well as our subscription payment processor integration. It includes our events system, a number of our reporting tools, LED sign controls, and a number of other applications.

It's available for use, and we welcome any patches.


As a physical manifestation of the open source ethos, Hacker Dojo is a pretty awesome place. I encourage anyone living or visiting the area to stop by Hacker Dojo, tour it, work from it, and play at it. Depending on your circumstances, either stay and make it more awesome, or create your own.

Contributed Notes

These are the notes that conference attendees listening to me took. I am incredibly grateful to them for recording the questions that were asked, as I hadn't recorded my talk, and will need to wait until the podcast to transcribe them.

- members get access to all events, even paid
- only members can put on events (or sponsor others)
- everything is communal that shows up except food and monitors if you label them
- experimenting
    - staffing? too much commitment. didn't work. disaster.
    - need dojo open when members are here — installed maglock that you get access to after 30 days (kind of like commit access)
    - experimenting gives rapid feedback
    - defining rules
        - people freak out when you say "no rules!"
        - operating under conflicting rulesets
        - didn't want to dictate rules from on high
        - wanted to avoid disenfranchisement caused by not being able to make meeting
        - Led to: polar bear wrestling - rule making sessions
            - proposal for rules due 2 days before
            - must be concrete and enforcable
            - removes central authority
                - don't want a management group if the dojo can manage itself
                - any member has the right and responsibility to enforce the rules
                - really, really hard for some people who need to ask authority
- It's not all good, there are still trolls
    - in real life, there's risk of physical altercation
    - facility is open to guests of members, but also to unaffiliated visitors
    - assume everyone is good until proved otherwise
    - had a homeless guy show up, move his stuff in, and get upset when told that it was no communal — banned
    - things that don't quite fit the space: submit the patch. 
       (define the project, get people on board, write up budget, develop safety plan, then come back )
    - all talk, no action — tell them to do the work
- politics
    - assume that everyone at the dojo is an adult
    - as open as possible
      - rules are published on the wiki
      - onboarding process
      - monthly membership meetings
      - polar bear wrestling
      - state of the dojo
      - expose finances
      - expose member metrics
- fork it
    - you can start your own
    - code written for the space is online at
- all of this info, including a prerecorded version of the talk at

- questions
    - what decision-making process at polar bear wrestling?
      - majority wins. the people who are there are the people who are passionate.
    - how does the board work?
      - write up agenda of short-term and long-term items
      - short-term
        - board can veto any rule that's not in the spirit of the dojo
        - budgeting

    - how many people?
        - 276 members
        - 40 before noon
        - 80ish all day
        - 15 – 200 more for events
        - space holds 350
        - looking at expanding to accommodate cubicles and quiet workspace
    - what sort of work is done?
        - a lot of coworking during the day
        - small companies start there

    - access control
        - we don't check IDs, open to the public
        - non-members get slow DSL

    - what kind of space is it, and where?
        - industrial space
        - warehouse
        - giant roll-up door
        - offices with natural light
        - larger areas without 
    - space reservations?
        - space is reserved for events
        - 1 of 3 offices is reservable by a piece of paper
    - how much go guests pay?
        - $10/day suggested donation
        - (and then you get fast internet)
        - people need to sign in, but don't do other checking
        - really careful not to make rules against the one bad apple, wait for the second

    - how long has it existed?
        Aug 2009 opening
    - what's the hardware section like?
        - hardware room is an electronics lab
        - have had people ask to build larger robotics, but this hadn't worked because of no private property/reserved space
        - trying to figure out larger projects

    - why do you call it anarchy and how would other members feel about that term?
        - "anarchy with respect" tagline came from david weekly, 
           one of the original superhappydevhouse founders. 
           was his fundamental philosophy for opening a hackerspace
    - how have you prevented someone from being seen as an authority figure?
        - the community polices its own fairly well
        - people ignore getting bossed around
        - when there are issues, the board has stepped in
        - board members occasionally have been called to come in and solve something 
           (but most times it's been solved by the time they got there)
    - costs?
        - $100
        - $40 hardship month
        - work trade option (typically for established members)
    - transit? 
        - had to be w/in a mile of caltrain (15 minute walk)