join the internet, see the world

September 4th, 2012

When I was hired by Chevron, it was to work in a brand new gas station they were building. Since they had a shiny new station, they wanted a shiny new staff to go with it, meaning that instead of just showing up and being told where the three-ring binders were kept, we spent a couple days attending paid training on their contents. The training was held in the small pastel conference room of the local Best Western. Every day at noon, we were given lunch. Free lunch. And we weren’t even really working! At 19, I was completely amazed by this.

I’m honored to be speaking at two conferences – Lisbon JS and JSConf EU – in the next month-and-some-change. I mention the Chevron thing because, in addition to the honor of speaking at any conference, it’s a big deal for me personally. I’ve left the continent I was born on exactly once. I’ve been on work-related trips, for conferences and general business stuff, but going overseas is a work-related perk I couldn’t even have fathomed 15 years ago, or even five. And I get to do it because I do this.

Working on the web is unlike any other sphere of development I’ve worked in in that we all have the chance to participate. People who speak at JavaScript conferences aren’t employees of the company that makes JavaScript; we’re all expected to make JavaScript. The distributed nature of this responsibility, and the context it pertains to, means that we don’t just share ideas with people in our region, or on the same continent. Ideas can come from anywhere, and they can travel anywhere, and if someone likes our ideas, maybe we get the chance to go with them.

I know a handful of developers who travel outside the borders of their home countries a bunch, but (as much as I hate flying) I wish more of us did that more often. Especially right at this moment, since I very recently saw one of the most inspiring videos I’ve seen in researching one of my talks: Trygve Reenskaug’s presentation “Object Orientation Revisited”. This is one of those things I wish like crazy I’d been lucky enough to see in person. This gentleman (the inventor of MVC) speaks with humility and humor about the fundamental philosophies that have informed the way a lot of development gets done these days, and it’s awesome. It made me remember what I loved about Computer Science way back when I was a student, and the sense that we are all contributors, not rockstars but scientists who can do no better than find a simpler explanation or a more elegant architecture. Seeing someone who does not fit the normal startup-y archetype speaking about things that affect all of us really drove it home for me: there’s a chance for anyone to make this field better, from anywhere, and for as long as they want to keep doing it.

So yeah. I’ll be in Europe in two weeks. I’ll travel to Paris, Marseille, Barcelona, Madrid, Munich, and of course Lisbon and Berlin. If you read this blog, I hope we’ll get a chance to say hello at one of the conferences. If you live in or have visited any of those cities, like I said, I’ve never been to any of them and would love some suggestions as to things to do and see (not the tourist stuff, everyday stuff that gives you a real picture of a place). And if you’ve never been to Europe, either, maybe you should start working on a talk, cause the world is full of good ideas.

sometimes community sucks

August 19th, 2012

My impression is that if you meet enough people in your developer community who are organizers of things – be they conferences, meetups, trainings, or anything else – you will at some point hear them bemoaning the fact that everyone hates them, or similar. I’ve listened to it several times. I’ve felt it (but kept it largely to myself) a few. Tonight I find myself, finally, in the unpleasant position of having evidence to back it up.

It’s generally understood that people taking on community organizer roles are just as flawed and prone to being wrong as anyone else, but are trying to do a good thing, and so we get given a lot of passes. For the most part – especially when the organizer in question is someone else – I think that’s a good thing. It’s difficult to put these things on, and nobody does it for the money, or even the fame, but out of a genuine desire to see their community grow and be better. I’ve learned over the past couple years to try and be delicate in my criticism of things other people organize, so it’s clear that I mean to suggest ways to improve an event or group, and not to criticize the efforts of the organizer, and certainly not to criticize the organizer as a person. Because over the past couple years I’ve become more aware of how hard it is not to take even the most gentle and well-meaning criticism to heart and feel you’ve failed.

If you’ve never done any organizing, you might wonder, so what if you failed? So you tried to do something for the community, and it didn’t work out, so what? If you’ve ever been on the other side, though, I think you begin to understand immediately. Before you even set up a website, or book a venue, or send out invites, I think most of us hesitate. There’s an element of impostor syndrome I think we’re exposed to at that point. I think a lot of us pause and ask ourselves, who the fuck am I to organize a _______, as though I had any authority on how a community _______ should be run? Maybe we wonder if someone famous shouldn’t do it, or someone with a really successful open source project, or someone who’s just, you know, better than we are. And maybe some of us stop right there because of that feeling. I spent years wanting to contribute in some way, not just with code, but to the community, before I was finally brave enough to start All-Girl Hack Night. It was that feeling that stopped me. So when someone tells you (what you hear as) you’ve done badly, you don’t just feel like you’ve made a mistake – you feel like a liar, a fraud, a snake-oil salesman whose arrogance has driven people away from the community, never to return.

So like I said, I am very much feeling that as I sit here writing this. I know that I failed at least one person, and may have caused them to become more skeptical about participating in a group I organize, and in other groups like it. I guess in a way I’m writing this blog post to myself, even though I started off writing it to all my friends who I know have felt this way in the past, or who are doing brave things that may expose them to this feeling in the future. Maybe I’m writing it to everyone in these communities. Maybe I’m just writing it.

You can’t make everyone happy. You just fucking can’t. Sometimes the well-intentioned approach that seemed great in your head, and worked great the previous three times, fails fucking abjectly. Sometimes someone is livid at something that other people begged for. Sometimes you meant it as a compliment and it gets taken as sarcasm. Sometimes you hang the banners and arrange the flowers and set out the chafing dishes and nobody ever shows up. We can try to make people happy, and to provide value, and that’s all we can do.

Bringing your A game isn’t always going to be possible. The more you try to do things, the greater the odds that you will fail at some point. That’s the risk inherent in trying. If there’s never been a time in your life where you were trying to make things work out, trying to get all the pieces to fit together, and yet could see that the situation was just rapidly falling the fuck apart, and all the people were rolling their eyes, and suddenly half your vocabulary disappeared from right off the tip of your tongue and you seriously considered just running out of the conference hall and into the nearest forest.. I envy you.

Anyone who gives up on a community because one organizer fucked up was probably already looking for an excuse. Sometimes people will treat you like the hostess at the Cracker Barrel. Those people have most likely not decided to jump into the community with both feet. And yeah, maybe you did have the opportunity to convince them to, and maybe you did waste it. That sucks. But it’s still ultimately a decision they have to make, to give the community permission to be wrong and to try and improve whatever they felt was lacking rather than just write it off as not worth their time. Even if you did the best job in the world, you still couldn’t be assured they’d come out of it that invested.

There are damn few institutions of community in this industry. The long-running conferences tend to be corporate things employees get sent to so companies can market to them. The long-running mailing lists get increasingly off-topic until finally they’re just slower versions of Reddit. I don’t think I know of any meetups that even existed before the mid-aughties. If you manage to make something hold together more than a couple months you are basically magic already. And, really, it’s better that way. We bring strangers together under the guise of community, and then we lose strangers to communities of friends they met while standing awkwardly at an open bar in a brightly lit hotel lobby wearing a plastic nametag. And if we organized that open bar, or even just the nametags, we have something there to be proud of. Attrition can bad, but it can also mean that it’s working.

Anyway, if you were wondering, hey, why is it that every community organizer I know gets so hilariously emo sometimes, I think I have your answer. We do this shit to do good and make things better, but there’s always the chance we’ll do a bad job, or even do a good job but still let someone down. That can make you feel really badly about yourself. Yet people still do it, cause if they didn’t someone else would have to, and then it would just sometimes suck for someone else.

etsy oauth in node

June 30th, 2012

If you take one thing from this post, let it be: never believe anyone who says, “Oh, it’s easy, you just use OAuth.” I say this because we were in a meeting talking about how developers in the JavaScript hackathon I’m at today would authenticate to Etsy’s API and someone, looking at the docs, made a similar statement. What I’m sure he meant was, “Oh, it’s easy, you just use this OAuth library.” The library in question, however, is in PHP. Luckily, there are similar libraries for Node, but they don’t work exactly the same and no one had actually written sample code to let developers use them easily in their projects.

In the past, I’ve dealt with OAuth by using Everyauth, which is awesome when it works. However, the past couple days when I looking into this, it did not work. I forked the project and ran npm install and discovered several problems (possibly because I’m using 0.8.0). I tried to get around them and create an Everyauth module for Etsy anyway, but I couldn’t get the damned thing tested so, though it looks right, I may never know if actually functions.

Everyauth is just a robust, consistent wrapper around another oauth module, however, so I didn’t have to code the back and forth and passing of tokens and all the nonsense entirely manually. (Which I started to do before I realized I don’t really have anything I need to punish myself for.) It was actually pretty simple to fix up a module using that to abstract the flow of getting the authentication token from Etsy, and probably would be the same for your site (assuming your site isn’t OAuth2 cause then I don’t even know).

create a skeleton module and make an oauth object

I actually started with all this crap in the server.js file and then moved it into a module once I knew it worked. Don’t tell anyone. But when I did that second, responsible step, this is what the module file looked like:

var oauth = require("oauth").OAuth;

var etsyAuth = function etsyAuth( key, secret, domain, callback ) {

    var that = this;

    return this;
};

module.exports = etsyAuth;

I guess that’s a pretty lazy module, but this is an academic exercise, and it gets the job done. The thing to note is that the only real setup necessary is including the OAuth module. That allows us to instantiate an OAuth object:

    this.o = new oauth(
        "http://openapi.etsy.com/v2/oauth/request_token",
        "http://openapi.etsy.com/v2/oauth/access_token",
        key,
        secret,
        "1.0",
        domain + ( callback || "/auth/etsy/callback" ),
        "HMAC-SHA1"
    );

Since this only has to work for Etsy, not every API under the sun, the host URLs can be hard-coded right in there, as well as most of the other initialization settings. The consuming app will obviously need to supply its own credentials, and might optionally change the route the application should redirect to once it receives the access token, but those are the only customizations offered. Well, that and the domain, but only because there might be some weird fuckers out there who intend to move their apps off of local.host:3000 at some point.

consume the oauth module

It probably makes sense to look at how this gets implemented. I used Express, but mostly just for easy session management. Aside from the routes, this server just imports Express and the OAuth code I wrote and instantiates and configures the Express app and the OAuth object:

var express = require( "express" ),
    etsyAuth = require( "./lib/etsy-auth" );

var app = express.createServer(),
    api_key = "your key here",
    api_secret = "your secret here",
    entry = "/auth/etsy",
    callback = "/auth/etsy/callback",
    o = new etsyAuth(
        api_key,
        api_secret,
        "http://local.host:3754",
        callback
    );

app.configure( function(){
  app.use( express.cookieParser() );
  app.use( express.session( { secret: "example secret" } ) );
  app.use( app.router );
  app.use( express.static( __dirname + "/public" ) );
});

This has all been sort of copying Everyauth, but it diverges a little bit at the routes cause I feel like entry and callback routes are really a part of your application, and OAuth is just a thing that happens there. So the app creates those, and passes control to the OAuth module within the request handlers:

app.get( entry, function( req, res ) {
    o.getRequestToken( req, res );
});
app.get( callback, function( req, res ) {
    o.getAccessToken( req, res, function ( req, res ) {
        res.redirect( "/success.html" );
    });
});

app.listen( 3754 );

In this case, the request handlers are both stupidly simple, but they could be doing data transformations, conditional templates, or generating Fibonacci sequences – whatever fits the needs of the application. They call two functions that are properties of our OAuth object, and the final bits of code I implemented/moved.

get some tokens

The first function, getRequestToken, uses the URL we provided when the OAuth object was instantiated and our API key to request a token, which is saved to the session object. Then the response redirects to a custom URL sent back where the user will approve our request to operate on their behalf:

    this.getRequestToken = function getRequestToken( req, res ) {
        that.o.getOAuthRequestToken( function( err, token, token_secret, results ){
            if ( err ) {
                console.log( err );
            } else {
                req.session.oauth = {};
                req.session.oauth.token = token;
                req.session.oauth.token_secret = token_secret;
                res.redirect( results[ "login_url" ] );
            }
        });
    };

The next function is called once the user clicks the big “Authorize” button and comes back to the callback route in our app. It uses our existing request token and the verifier to get an access token, which gets saved to the session like the request token. If the application passed in a callback, we go ahead and execute that, and we’re done:

    this.getAccessToken = function getAccessToken( req, res, callback ) {
        if ( req.session.oauth ) {
            req.session.oauth.verifier = req.query.oauth_verifier;
            var auth = req.session.oauth;
            that.o.getOAuthAccessToken(
                auth.token,
                auth.token_secret,
                auth.verifier, 
                function( err, token, token_secret, results ){
                    if ( err ){
                        console.log( err );
                    } else {
                        req.session.oauth.access_token = token;
                        req.session.oauth.access_token_secret = token_secret;
                        if ( callback ) callback.call( this, req, res );
                    }
                }
            );
        }
    };

If you want to see how it all comes together, it’s on github. Hopefully that’s useful if you need to authenticate to Etsy or setup OAuth for your own API.

ladies, speaking

June 16th, 2012

Between TXJS, which happened this week, and weareallaweso.me, it’s a good time to feel optimistic about women speaking at dev conferences. TXJS had something like six women speak out of sixteen speakers, which is a more impressive ratio than any other conference I’ve been to, and weareallaweso.me is trying to collect ways to make that a more common occurrence. Not too shabby, web developers. It seemed like a good time to reflect on the difference female speakers make, and maybe a little bit about how a female speaker might differ from a male one.

Obviously this is just my own observation and YMMV and all that, but seeing women speak is a big thing for me. And TXJS this year made me aware that’s it’s not only seeing women speak. Seeing them speak about their own projects and their motivations for their code makes me feel like open source is something I can do. That might sound disingenuous coming from someone who has participated a little bit in open source and has some of her own very small projects, but I am 100% serious about it and it was 100% needed. Watching women discuss projects that aren’t necessarily the biggest deal on github or used by everyone, but are nonetheless rigorous, important, and awesome made me feel like I can do those kinds of things too. I’d worry about leaning too far toward sexism in postulating as to why, but it’s different than seeing men do the same thing, and not just because I shared a gender with these speakers.

Actually, fuck it, let’s go ahead and postulate. While individual women are obviously as different as individual men, we do talk about how companies and industries can benefit from a more “feminine” way of conducting themselves. This means values that we associate with women and expect to see rewarded more in girls than in boys. Things like modesty, sharing credit, listening well and talking only when there’s something important to say, and sublimating our competitive drives when it’s to the benefit of a larger group. Things that we consider feminine traits are, broadly, things that place groups before individuals.

That’s what was so inspiring about these talks I saw. These women needed to solve real problems, so they quietly stepped up and filled that role of project maintainer when they created these projects. On larger projects, that role is almost always a man. Not only are these women capable of being brilliant developers (hopefully no one really needs proof of that anymore), but they’re capable of doing things women are often raised to leave to the boys. I was also struck by the way they spoke about their code, though. There was so little hyperbole, no sweeping dogma or expectations that the audience would automatically see why these projects were so cool. They carefully explained, and focused on the technical aspects. I can’t really explain it perfectly. It felt different. More academic. Less like someone was selling me something. Certainly I’ve seen men talk about their work this way, as well, but not very many. What would be really amazing would be if these speakers had inspired not just another woman with their approach to development and open source, but the men in the audience, as well.

With all that said, I found one thing wanting, and that was the technical nitty-gritty. While I loved seeing these women defend their work and think that happens in our communities all too rarely, I also wanted to see the code. I wanted them to scare me with their brilliance, and wow me with their code, and talk about how the use of this loop here instead of this switch there made all the difference in the world.

I know one of the things TXJS did to get so many ladies on stage was to invite less experienced speakers. That’s crucial for seeing more female speakers and changing gender diversity in general, because Rebecca Murphey and Lea Verou can’t be everywhere at once. I hope to see more of this, but I hope that conferences will coach these greener speakers, as well. It would be wonderful for conferences to send out a detailed sketch of their audience, even if it’s just the organizers’ best guess. (This would probably help female attendees feel more comfortable, too.) I think knowing that there will be people in the audience who’ve been to ten or more JavaScript conferences, for example, would make me feel more comfortable showing tons and tons of code, whereas if I thought the audience was likely to have only 1-2 years experience I’d want to talk more generally and limit the amount of code I showed. This only came up for me because I was dying to see these ladies’ code and I think last year when I spoke at TXJS I made a mistake in speaking too generally because I’d attended the conference as a serious-JS-n00b the year before. I can see how that cycle might kind of perpetuate itself without intervention from the organizers to get people to promote content at a certain level of detail. Standard disclaimer about having never organized a conference, though.

I hope people feel that coaching is worthwhile. Speaking from personal experience, it can be difficult to find the confidence to speak about something you’re still learning yourself, and even more difficult to feel like your own work is interesting. Knowing not just what to submit or prepare talks on, but what aspects to discuss and who to target the content to could potentially make a huge difference in getting new women speakers onto conference stages. Or maybe not. But bravo to the organizers of TXJS and all their speakers (male and female), and to the folks behind weareallaweso.me. I hope these are signs of more good things to come.

answering the wrong question?

June 3rd, 2012

It seems like there’s a really good opportunity for someone to do something very helpful and make a site that compares and tracks JS frameworks. As far as I can tell, though, no one has, so maybe I can be excused for my ignorance if what I’m looking for already exists. What I’m looking for is a framework that deals with webpages as webpages, and deals with elements within an application as elements.

I kind of go back and forth on my feelings about MVC, but they average out right around apathetic skepticism, or ::rolleyes:: if you want. It’s because there are a shit-ton of them and MVC is pretty easy to write code for, cause things have these very clean relationships. That’s great for your data, it’s great for your backend, yada yada yada. But it’s pretty much shit for complicated interfaces. Views and models don’t always line up. Views without models exist and still have state. Some states are important to the application, some are important to a given object, some are important only to a widget. You can shove all the shit on your page into the MVC idiom – and people do – in order to use an MVC framework, but I don’t think that solves the real problem.

If you know of a framework that’s primary concern is with organizing DOM elements and DOM interactions, please stop right now and go down to the bottom and leave a comment telling me about it. As far as I know, such a thing doesn’t exist. jQuery’s great for working with the DOM, of course, but doesn’t make any attempts at organizing things or offering a hierarchy of objects. We now consider DOM interaction a bad thing, so more “serious” frameworks tend to shove the DOM stuff under the rug, deigning to interact with the page only when necessary.

I don’t want to say a bunch of shit I’ve said before here, but that’s just fucking silly. Structuring your code around abstract objects instead of the mechanisms by which things are actually made available and manipulated – DOM elements – is like having a perfectly organized closet while the rest of your house looks like something from the TV show Hoarders. It’s low-hanging fruit, and it skirts the issue that’s the most difficult to deal with and the most inseparable from the idea of a web application.

I’ve looked at a bunch of these frameworks. I’m not going to lie, I’ve only attempted to write apps using a few, and quickly got frustrated by the tradeoffs between limitations and simplifications they were offering. You don’t have to agree, but I’m just saying: I’m a computer science major, one of not very many I know, and I find their approaches way too computer science-y. Writing an interface programmatically is one of the most painful things I’ve ever had to do (repeatedly, in VB), and that’s what the frameworks I’ve worked with all devolve to once you’re beyond the tidy CRUD model where MVC can give you genuine shortcuts. But, again, I’d love to know if I’m missing something.

I read a blog post about how fashion designers should learn to code recently and was kind of horrified by it. To me, it’s a perfectly example of why not everyone should learn to code. Not because the solution was bad – I think polaroids are about as elegant as you’re gonna get, personally – but because part of how a programmer has to train himself or herself to think is this kind of obsessive, examine the problem from every angle, think of every possible optimization pattern. We do need people who can think that way within certain contexts. It’s useful when you’re building an application. Or, say, a JavaScript framework. But it can and does bite us. We know what happens when we’re wandering around unchecked with a hammer looking for things to use it on. (We use it inappropriately.) I feel like it’s time to stop letting classical CS patterns inform the way we build JS frameworks and embrace the way the DOM actually works and is used and has been used, and build around that. When someone truly does that well, I think JavaScript will take another big leap forward, and we’ll all wonder why it took so long for us to address the right problem.

what the fuck is an entrepreneur

May 31st, 2012

I swear, if I read one more thing about how lucky we are to have so many entrepreneurs in Austin, I’m going to scream. This week has been especially annoying, what with a tone-deaf video promoting a group called We Are Austin Tech and an article gushing about a brand new pro-entrepreneur clubhouse in the middle of downtown. You could be forgiven for thinking, based on these media sources, that all it takes to build a thriving technical business is a plucky entrepreneur and a dream. Not exaggerating. Some choice words of wisdom from the video:

“We’re actually creating the future. And if it wasn’t for entrepreneurs, it wouldn’t get created.”

If that quote right there isn’t enough to keep you from going to work for anyone who calls themselves an entrepreneur then I don’t even know what the fuck.

I’ve made a decision not to work with or for anyone who self-identifies as an entrepreneur. It’s a little arbitrary, yes, because there are some good ones who’ve boldly decided to lump themselves in with the dickbaskets, but I trust myself to know when to make exceptions. But in a community that rewards people just for hanging that mantle on their little noggins, the term loses credibility across the board. Here’s why:

1. I make things. I want to work with people who make things.

My major problem with entrepreneurs under the current definition is that the only thing they appear to “make” is personal wealth. They move capital between entities, they buy low and sell high, they’ve created a very crafty way of purchasing “talent” (or, as we used to call them, people). And this makes them rich, and it makes investors rich. Unfortunately, all the cycle usually leaves in its wake is second-hand IKEA furniture you don’t have to figure out how to assemble yourself and a pile of XS and XXL branded t-shirts. These things don’t have to be tangible, but they do have to be valuable to everyone using them, and useful in their own right. Otherwise you’re not creating anything, you’re just using technology to skim a little off the top.

2. I want to invest, too.

I’m not talking about money. I’m talking about my time, creativity, credibility, and anything else I have to offer as a developer. I’ve been at companies where I always had one foot out the door because no one there seemed super interested in the long term feasibility of what they were doing. I find that waiting-around-to-get-bought feeling gross. It’s what I imagine it must be like to be inside one of the cartoon suits as Disneyland. You spend all day putting on this performance and then you go home and spend your paycheck in some dive bar, wishing your life had some meaning. Or maybe people really like working at Disneyland, I don’t know. But working for a company that discourages or disregards your effort fucking sucks.

3. I am not a prize to be won.

The other problem with companies whose end goal is to get bought is that as an employee you’re literally a commodity. My understanding is that the itemized bill of sale for a startup is like:
14 – office chairs, Aeron
18 – laptop computers, Macbook Pro
5 – laptop computers, Macbook Air
2 – engineers, database, good health
3 – engineers, front-end, questionable health, cool haircuts

And if you think even making this a bullet point is silly, know that I’ve worked for more than one entrepreneur who literally collected engineers, doing nothing with them except maybe attempting to use them as bait to lure in other engineers, and at worst treating quality developers like office decorations. In the end (if you stick around) you get treated like a medieval princess and married off to Facebook even though you’re in love with Tumblr.

4. I want to work for people who know what a dollar’s worth.

The thing entrepreneurs seem to be really good at is acquiring money. Once they have it, though, they seem to be confused about what to do with it. I’ve known more than one to spend lavishly, then suddenly realize they’re burning through a lot of cash, dial it down, then get frustrated by what happens to morale sans both interesting work and a fully stocked kegerator, so attempt to recover by spending wildly again. The problem is, that’s fucking stupid. Not only is it wasteful for the business and a tiring cycle to be trapped in, it doesn’t accomplish what it should. It takes a confidence I associate with non-startups to pay employees the highest salary the business can afford and trust them to see through the more gimmicky competing offers they might get elsewhere.

This isn’t exclusive to entrepreneurs, but I also become suspicious when someone tells me, “We’re going to make you a really good offer.” That’s like the “high-roller” at the restaurant who, midway through an evening of boorish behavior and nursed bottom-shelf cocktails, assures you you’re going to be “taken care of”. People who know the value of the service you’re providing will demonstrate that in the only way that counts. Anyone trying to get you at a discount or on spec is deserving of your skepticism. Entrepreneurs still looking for that “first round” can fall into that category. I’ve had people seriously try to negotiate my salary expectations way down with, “but we’re a startup!” The fuck do I care if you’re a startup. All you’ve just told me is that you’re not my future employer.

5. A person who believes in their business identifies themselves by their business.

Calling yourself an entrepreneur instead of “CEO of Internet Fabulous Products, LLC” is like going to a party as your spouse’s date and introducing yourself by telling people what a good kisser you are. If you don’t take your company seriously enough to tell people your job is running that one company, why should an employee or anyone else take it seriously? And if you’ve always got one foot out the door, ready to sell, fuck over your employees, and move on to the next company, who’d expect the next company or its complement of hapless employees to fare any better?

6. People with no technical knowledge don’t belong in the technology industry.

It’s not enough just to have a good idea. If your good idea has a shitty implementation, other people will be along soon to eat your lunch. And your good idea will have a shitty implementation if the person in charge doesn’t know a single thing about how it should be implemented. It’s not merely laughable when a “technical entrepreneur” has no technical knowledge – it’s offensive. I’ve worked for businesses all my life. I don’t call myself an executive. If you merely use technology as a means to end, rather than creating technology, fine, you get a pass. But if what you’re creating is technology, if the limitations of hardware or software have any bearing on your design decisions, if there’s ever an installation, configuration, or download step, and you don’t understand it, I don’t want to work for you. Who built Facebook? Who built Google? Who built Microsoft? Those people, whatever else you want to say about them, deserve to call themselves technical entrepreneurs. By comparison, there are a large number of entrepreneurs barely competent to call themselves middle management.


Here’s a quote from the article I linked to at the beginning:

“The No. 1 challenge for tech startups in Austin and around the country is hiring critical engineering talent,” Baer said. “We are going to bring the best talent here for all these events we will be having.”

The best talent, huh? That’s a pretty big promise. Maybe it would be easier to bring in the best talent by publicly showing a little more respect for the work that they do, and a little more modesty about using other people’s money to purchase other people’s skills. Maybe there’s more than one of us who wants to work for a technically skilled boss who’s building the business he or she wants to grow old at and gets their hands dirty right along with us – not just another self-styled “entrepreneur”.

giving greenfield stuff to newbs

May 22nd, 2012

I’m coming up on two months at my new job (feels like a lot less), and with the amount of code we have, that means there’s still plenty I haven’t seen or worked with. There are certain processes (e.g., deploying) that have become automatic, but others I haven’t yet done. I still get automated emails and have no idea what the hell I’m supposed to do with or about them, if anything.

No matter how far along you are in your career, integrating yourself into a big system takes some effort. Flexibility and lack of process in a smaller system usually speeds things up, but it can be hard to deal with in a bigger system, maybe because it’s hard to trust that there aren’t hidden processes or toes to step on in some part of the system you haven’t stumbled into yet. I had a thought about how it’s easiest for me to deal with that uncertainty, as well as to work toward becoming familiar and overcoming my newbishness; I wonder if anybody else feels the same. I kind of think that, maybe against all sense, the best thing an employer can do with a new employee – especially in a big engineering group – is give them a greenfield project.

I’ve almost always started out fixing bugs. Tiny, trivial things. A couple of pixels of missed padding, some content tweaks, an IE6 issue half the team has looked at and no one’s been able to reproduce. Dude, that shit is frustrating! Not only do I spend sometimes entire days just trying to find the code I’m looking for to insert debugger statements or whatever, and have to learn how things are built on the backend and what the organization is, but once I finally do that, all I have to show for it is a paltry and brainless task that someone familiar with the codebase could probably have completed in five minutes. Conventional wisdom is that this is how you become familiar with the codebase. I’m not so sure, though. I think you become familiar over time, as you gain context. The patterns become predictable to you. You know that one of these three people will have worked on it, so it will be coded and organized one of these three ways. But your time to learn those things is measured in months, not tickets closed. Trying to hurry it along, I think, may be fruitless.

Contrast this with a small greenfield project. You’re still going to need to touch a hell of a lot of code. You’ll still have to go exploring, and learn the little bits of style guide that evolved from an oral history of alert()s and never quite made it into the wiki. But instead of leaving breadcrumbs through a confusing maze as you try to fetch a pebble, you’re building a tiny monument using the stones you find closest to you. And you may do it wrong. It’s almost certain that something about the task won’t match up with the standards of your new employer. But then you can have a code review, and hear about those standards in context, while you have an open buffer to save them to. Having a project composed of tasks, instead of a project with a single incidental task, gives you a place to begin and a way to attach more meaning to the structures and processes you discover.

I don’t think I’ve ever started and been given a greenfield project. Or maybe I have, but without understanding that they were truly mine to take ownership of. It hasn’t mattered as much at the past three places I’ve worked, since the code was so much more segmented, and there was less to learn. Here, though, with one pretty substantial codebase, I’m finding that I really want a home base in all of it to start exploring from. Do other people feel like that when they’re starting out somewhere?

javascript hotline

May 16th, 2012

I don’t know Rails, and that may be why I hadn’t heard of Rails Hotline before last week. If you’re not a Rails dev and are also unfamiliar, it’s pretty much what it sounds like: developers volunteer to take a shift answering the phone if anyone calls, and other developers can call in and ask their Rails questions of a real person, absent the distractions of IRC or typing in general. Though I rely on IRC pretty heavily when I run into questions, this made immediate sense to me, because sometimes I run into things I just don’t have the words for, or I need a longer, more abstract explanation than is comfortable to type into a chat window.

So, long story short, I set up a JavaScript Hotline. You can hit my hip right now (for some definitions of right now) at (877) 300-2187. But I’m not the only JS dev I know, so I’m hoping that before long, it won’t be just me. If you want to volunteer to answer some questions, there’s a button right there on the site that’ll sign you up. Pocket Hotline, the company that provides this service, has a cute intro video about volunteering if you think you might be interested. If you’ve never done any teaching or mentoring, this seems to me like a really awesome way to get started. You’d be amazed how much you learn answering other people’s questions, and obviously it’s a great way to meet other devs in the community.

If you don’t want to contribute time, there’s also a button on that main page to contribute money. ;) The service is free for the first two hours, but it’ll take money to continue it after that.

Finally, of course, if you need the sort of JavaScript help that jsfiddle and IRC alone sometimes can’t provide, now you have someone you can (literally) call.

authority and paying your dues

May 10th, 2012

I’ve tried consulting a couple times. The most recent of those, I tried it with a partner. He didn’t know much about web development. I had to teach him a lot. He got significantly better, but he was still what I’d consider junior. At some point after we gave up on consulting, he was applying for a web dev job..

Him: “They asked me to rate my CSS skills. I told them I was probably at about a 9 out of 10.”

Me: “You’re kidding.”

Him: “No, why?”

I told him I’d been doing CSS for around a decade, compared to his single year, and I’d only give myself maybe an 8 out of 10. I told him it seemed intensely arrogant to be hand-fed knowledge by someone else, without ever having had to fend for yourself within that skillset, and decide that your own knowledge had become equivalent. I told him the things I’d been wanting to say to overconfident developers for years.

Thing is, it’s not primarily arrogant developers who annoy me. It’s the industry that rewards them. I can’t count the number of times I’ve seen dipshits be elevated to positions of authority on the strength of their bluster alone, while people who’ve paid their dues and acquired the rare and genuine ability to discern their ass from a hole in the ground continue going around in circles, being tested over and over again and never being credited with the substantial work they’ve already done. I’m finding myself exhausted by open source projects that attempt to solve the same problem again and again, attract a lot of attention, yet do nothing to move the craft of writing code forward, just provide a shorter shortcut. I’m more exhausted by seeing the young white men who often helm these projects, fresh out of school or some completely different paradigm, exalted. For nothing. For deploying buzzwords. I’m exhausted by conversations with people who aspire to be and probably someday will be those exalted young white men about how they’ve thrown over the previous trendy shortcut in favor of the flavor of the month and it’s improved their development process so much.

Like a lot of people who’ve been doing this for fifteen years, I feel I’ve paid some dues. When that’s not recognized, it’s frustrating. When the rules I followed don’t seem to apply to other people, it can be maddening.

“but we’re special”

I read a lot of bullshit about how engineers are so much better than other industries, or are so similar to revered creative classes. We like to paint ourselves as though we are, no seriously you guys, exempt from the rules the rest of the working world abides by. I can even sort of imagine how a person ends up believing that. I imagine growing up in a big middle class home, someone else feeding me and cleaning up after me, no pressures in life except to go to school every day and get good grades. I imagine being rewarded that whole time for my staggering intellect because OMG I was able to type a computer program into a big beige luxury abacus. I imagine graduating high school with community recognition, the connections that people in middle class society seem to develop with no more effort than breathing, and a degree – a key that opens a door that’s never been locked to me to begin with – being completely optional. I imagine moving from my parents’ home to my own apartment, easily affordable on my “starting” salary of $50k/year. I imagine this being my first job. I imagine the successive accolades, salary increases, and headhunter wooing seeming like the most natural thing in the world. And then I wish like hell I were in any other industry.

Of course, the number one privilege of privilege is being ignorant of it, so it’s probable that no one to whom that paragraph applies actually read it, or they read it and believe it doesn’t apply to them because they completed half a liberal arts degree but felt unfulfilled, or have credit card debt, or some other hardship. So whatever. Of course I’m not talking about you, dear reader. I’m sure you didn’t just show up in this industry out of nowhere five years ago and expect it to lay its wreaths at your feet. I bet the summer you spent troubleshooting modem problems part-time in your uncle’s friend’s computer shop were really eye-opening, and are a completely adequate substitute for a formal education in computer science history and software patterns when you jump into MVC debates.

For real this time, though, I’m sure that’s not you. I can tell because you’re still reading.

I write a lot of stuff about gender diversity here, but I think this is more an issue of class, if that wasn’t evident. Sadly, though, you don’t avoid the glass ceiling just by being a rich girl. There are a lot of factors that seem to leave people out of the group of engineers entitled to positions of authority, because while we’re usually at least superficially happy to embrace engineers of all stripes, we retain the expectation that the best engineers will be young, straight, white males from a middle- or upper-class background. That’s what authority looks like in this field. Those are the people capable of innovation. Those are the people whose open source projects can be relied upon to be informed by the most current best practices. Those are the eccentric geniuses. Other people can come along and, you know, fix their bugs or something.

There was a woman at hack night last night who’s making a career change. She was taking programming aptitude tests. We asked what they were measuring, and she said there were a lot of general logic problems. It’s ironic that an industry of people who value our aptitude for logical reasoning so highly would fail to notice that there’s a completely illogical conviction that we’re a meritocracy, yet our leaders fail utterly to represent anyone in the industry outside of a very narrow demographic.

Also, I don’t want to hear any shit about how women are represented. Speaking at conferences is one measure of authority. Most conferences have one or two women speak in a nod to diversity and then feel free to relax and fill up the other slots with men. After all, they don’t want to look like they’re picking women instead of the best person for the job. If you ask anyone to choose the best developer in their particular niche, absent the context of what I’m talking about here – ask them to choose just one person – I think the name you’ll always be given will be a man’s. Because it’s fine to throw a few women in to be PC, but come on, if the future of JavaScript rested in the hands of one person, we want the most qualified, right? And we don’t challenge the assumption that’s it’s natural for the most qualified person to in all cases match the profile above.

In the context of all that, it becomes unsurprising that paying your dues means fuck-all. There are people who will pay the same dues their entire careers, and there are people who will never pay any. There will be exceptions, but over the lifetime of a person’s career the industry will probably correct for that. And, to a degree, it explains the at-times staggering arrogance of newbie developers. If your heroes had succeeded without ever having dirtied their hands with legacy mainframe code, you might expect the same to happen to you. The only heroes you’re likely to see when you’re starting out, of course, match that same young-straight-middle-class-white-guy profile. If they wrote mainframe code, it was for funzies.

the industry has to fix this

We have an old-boys club, but with young boys. We keep people down. We frustrate people who want to and are uniquely qualified to do great things. We ignore their contributions and their knowledge. They do leave because of it. We should want to stop that.

As an industry, we need to learn to mistrust arrogance. We need to stop being afraid we’ll be remembered as the person who said no to the next Steve Jobs. Most people are not Steve Jobs and are never going to be. And if you treat all those people like Steve Jobs, you’re going to get a lot of spoiled brats without the discipline to check themselves or the humility to take criticism. That’s extremely bad. It means circle-jerks instead of progress. It means we don’t learn from our own short history.

We also need to reward the paying of dues. Yeah, it’s snarky when someone says something like, “NoSQL? Oh, you mean what we did before we had SQL?” It’s also a fair fucking point. People are going to shit all over your parade sometimes, and sometimes they’re going to be right. The solution is to not go planning parades through streets somebody else paved without asking them for directions. Seeking out established expertise is something that happens all-too-rarely. Rather than finding and asking someone from outside our teams who’s already solved a problem, we often ask the person with the greatest authority within it. Hilariously, it tends to be the most skilled people who make the biggest point of asking for the experience of others before diving right into a problem. They don’t necessarily emphasize that fact to their bosses, however, which leads to the perception that one young cowboy or cowgirl can be just so goddamned smart that he or she is right about literally everything, even with no experience. He or she probably is not.

the industry is made of people

I can’t make your boss stop hiring people who spew buzzwords and talk about how they were too smart to get a diploma. I can’t make conferences start booking the person who fixed the most onerous bug to speak, instead of the author of the library. I probably can’t even get a post about what writing COBOL for the state taught me about how you should run your stupid fucking startup at the top of Hacker News. But if I managed not to lose you yet, maybe I can get you, personally, to stop encouraging this shit. Don’t degrade yourself and your profession with dick-measuring contests with your peers. Especially don’t do it with your juniors, who may take the example to heart. By the same token, don’t “test” other engineers. Don’t condescend to them. Shit, assume that they know more than you do. They almost certainly do, about something. I mocked people from a certain demographic up above, and you probably recognized instantly how foolish that was. Those people have paid dues, too, just not the same ones I have. They can learn from me, but I can also learn from them.

As individuals, we need to stop expecting shortcuts. We need to learn to reject rewards we haven’t earned. When someone asks us something we don’t know, we need to be confident enough to say so, and suggest someone who might. Because we all want a meritocracy, and the only way we get one is by being brave enough to believe it can actually happen. If we keep acting like an industry of frauds who would be thrown out were it not for our self-aggrandizement and our politicking, we will have exactly that industry. As individuals, we’ll be better hustlers than we will developers. Fuck that shit. Pay your dues, and ask the same of your peers. When they do it, offer them the same respect you’d want. Simple.

from mockup to code (efficiently)

May 1st, 2012

Lately I find myself in the once-familiar position of taking mockups and converting them to markup and CSS. This is generally a pretty simple task, one you could optionally pass off to a junior dev. But that assumes there’s a clear process for it. Obvious divisions of labor, patterns, and best practices, I’m finding, make a hell of a lot of difference. Without those things, it becomes even more painful than it has to be. Join me, won’t you, as I go back in time to when I last did this stuff and try to figure out what made it work well:

1. you need a visual

It doesn’t matter if it’s a fully rendered mockup with all the colors and borders and padding decided on. It can be just a wireframe. However, you need a picture of the final product you hope to produce. If your website was a novel, you’d draft an outline. If your team is just you, maybe you can make it work with no documentation. Once there’s even a single other person, however, you need some representation of the end goal in order to begin doing work. From a mockup or wireframe, you can start getting a feel for the data you’ll need access to, which is something you want as early as possible.

2. dummy markup

If you’re both visual designer and frontend dev, this and the step above may be one in the same. But if those roles are handled by separate folks, the work of the first needs to be translated into the domain of the second. The way elements fit together visually is different (obvs) than the way they fit together in markup. Separations and groupings not evident in an image become much more clear with HTML tags around them. It’s easier to see where an array of data will be looped through, or where a condition will determine visibility, an error state, or some other presentational change. Translating to markup should leave you with a fuzzy sketch of the data you’ll need to receive from the server.

3. dummy data

If you’re working on a dynamic page, you’re using some sort of template. Whether it’s client-side or server-side, you should replace the dynamic pieces of your dummy markup with template tags. Creating dummy data at the same time will let you test your template, even if you’re not the backend developer, or you’re waiting on something in your application’s data layer to be ready. While dummy data obviously won’t help you catch edge cases like unescaped characters or data that’s longer or shorter than what you’re expecting, it will firm up the picture of your viewmodel so that whoever’s connecting it to live data can do that work without a lot of back-and-forth.

4. real data

This is the awesome part where whoever’s doing the server-side code swaps hard-coded viewmodel values for dynamic stuff and everything just magically works.

J/K. This is the part where you find the bugs. Not just the data bugs mentioned above, but bugs in the design, such as, “that just doesn’t look very good with text in it.” So you back-track to whichever step contains the bug and go through the steps again. If you can show me a development process that avoids that sort of repetition, I will print out this blog post and eat it.


Pretty simple stuff, but notice there are a bunch of different roles in there, and this allows those that touch the frontend to proceed on their own schedule without holding each other up. It also prevents people in those roles from being engaged too early and floundering trying to make guesses about what the eventual shape of a page or application will be, letting everyone waste less effort.

It also delivers work products biased heavily toward YAGNIBSW (“You Ain’t Gonna Need It But So What?”). It builds in a thoughtful amount of rigor and separation of concerns at the point where it’s easy and cheap to do so, which will save you time down the road if you go through a lot of revisions, and will at worst seem less cowboy-ish and cool if you don’t.

Are there any other steps you use, or an entirely different, better way of doing it?