totes profesh

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?

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.

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.

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?

The double-edged sword of trying to address the lack of women in technology as a woman is that, if you manage to get a group of technical women together, you’re going to end up creating what’s called a girl ghetto. A girl ghetto is where you stick the women you’re keeping around to show you’re in favor of diversity, but don’t actually want to interact with. Girl ghettos fucking suck.

Girl ghettos end up making women even more powerless because if they complain about the status quo, they’re looking a gift horse in the mouth. Girl ghettos end up pushing women away from each other when women realize that if they hang out with more than one other woman, men who were making an effort to reach out and include them begin to disappear, they’re not getting invited to participate in things because it’s assumed they now have their own things, and they begin to be invisible. Girl ghettos keep us treading water on the issue of gender diversity because we corral women into them and then abandon them.

And yet, they have their value. I’ve read things in the past that suggest women should avoid girl ghettos, and not get sucked into the trap. That’s missing the point. I’ve had the chance to hang out with a bunch of really smart women over the past few weeks and it got me thinking about all the years I spent styling myself as “one of the guys,” avoiding other women because I secretly believed they weren’t as smart as the men, worrying about feminist guilt by association, and having no one in my industry I could actually talk to. I don’t mean no one to talk to about women stuff, I mean no one to talk to period. Why? Cause while people might be civil to me and even like me, they didn’t really respect me. Would you respect a woman who secretly agreed that most women were probably lesser programmers? If you’re still in that mindset, let me tell you something: you are not the one special woman who gets it. You’re selling other women down the river, and selling yourself down the river by extension.

Anyway, so these several conversations with brilliant women have been especially amazing for me, because I spent so much of my twenties missing out on exactly that. But also because it underlined the tragedy of girl ghettos: groups of women are something we should be excitedly seeking out. Not because women need a refuge from the demands and competition of professional software engineering but because hanging out with other women software engineers is fucking awesome. I love hanging out with my male professional friends. But there is a certain battle most of them have never had to fight and will never have to fight. It obviously doesn’t happen with every woman, but when I meet a female dev who I get along well with, being veterans of that war deepens the connection in a certain way. It’s nothing tangible or discussed, but there’s a sense I get that my male peers go home whole at the end of every day, whereas the women in my industry had to give a chunk of themselves – some mix of pride, sensitivity, femininity, modesty, and caution – had to leave it on the battlefield and will hopefully go home with money and acclaim and creative satisfaction where that other part of their identity used to be, but will never be the same as a result of sticking with this profession. I continue to form, seek out, and join girl ghettos because of this. I want to know those other women.

As an industry, we need to stop apologizing for groups of women, and we need to stop turning them into girl ghettos. In order to do that, we need to stop expecting them to fail. Because although it’s nice to meet other women in your gender-imbalanced profession, these groups are one of the ways people try to correct that gender imbalance. You know there’s a problem when every time you hear about one of these groups it’s being described as though no one had tried to do anything similar before and the problem it’s attempting to solve is described as though it were revelatory information. If I were a cynical person, I’d say the industry even wants these groups to fail. If it gets appropriately excited whenever a new one crops up, waits for them to go off and solve the problem without bothering anyone who’s OMG busy coding, and then there are still not very many women, well! That must mean women don’t like/aren’t cut out for software engineering in the first place. For those who aren’t in them, this is the function of girl ghettos – they “prove” that women aren’t actually peers.

This is a hard thing to talk about because as much as it means exposing cynical douchebags, it also means shitting all over people who are trying to help. If we want to stop assuming women in tech groups will be irrelevant in a year, if we want to actually increase the number of women in this industry, not use a progressive set of disappointing mirages as a tool to sift them out of it, we need to support the ones we have. If you have personal or political conflicts with the people in an existing group, join/support a different one, or just be an adult and suck it up. If you’re geographically isolated, don’t go off on your own and start something new, bring an existing group to your town, or take an online group offline. I made that mistake myself with All-Girl Hack Night and, while the group that came out of it is great, it would have been just as great if it were DevChix Austin or something, it would have probably attracted the same great group of ladies, but starting a new branch of an existing group wouldn’t have meant starting from zero. Again. Just like basically ever girl ghetto ever.

This applies even if you’re not a group organizer or a woman looking for professional camaraderie. If you want to do something about the lack of women in technology, the best thing to do is partner up with a group of women. Not only is this the most direct way to help women, but it sends an important message: that you are not invisible in the girl ghetto. That you as a female developer are not worthy of assistance only when you’re completely alone, without peers male or female supporting you. That hanging out with other women is not the bunny slope, that it doesn’t demonstrate lack of professional skill or seriousness, and is not evidence that you can’t “play with the big boys”. When organizations overlook the girl ghetto, that is the message that’s sent: you better stay away from other women and succeed on your own, or alone in a crowd of men, if you want to be noticed and taken seriously. It’s a bunch of fucking bullshit.

Honestly, I don’t give a shit whether other women join a women’s group or not. I think they’re great, and I’ve met incredible people through them who, statistically, I’d be unlikely to otherwise. I believe in paying it forward and making my support available to women who aren’t yet on the other side of this industry’s inherent Concord fallacy, but whether that’s a role she wants to play is a decision an individual has to make for herself. But don’t shit all over the girl ghetto. You’re not into it? Cool. You don’t like hanging out with other women? That’s probably not cool, but I’m not your therapist. No one should be condescending to or failing to take seriously any group of developers just because it doesn’t include men. And certainly no one should be claiming to support women while using women in technology groups as a way to ignore them in bulk.

You ever find yourself feeling unreasonably protective of JavaScript? I do. For a long time, JS lacked a lot of sophistication. It was vulnerable to being trampled over by bigger, more powerful technologies like Java applets or Flash. There was nothing to really commend it to anyone who didn’t, for whatever crazy reason, already love it. Eventually it was able to do things for itself, but there were many years where it was pretty much defenseless and it sounds dramatic only in hindsight to say it wasn’t clear whether it was going to survive to maturity.

Maybe I just like underdogs, but I’ve rooted for JavaScript from the beginning. Probably unsurprising then that I was really pissed when I first encountered CoffeeScript. JavaScript had finally developed the power and utility people had mocked it for lacking, and now they were going to complain about its appearance? Bullshit. But lately I find that I don’t care as much about CoffeeScript et al.

JavaScript isn’t a little baby language anymore. It’s full-grown and it’s going places I never expected and it’s got fat arrows and other things I probably don’t even want to know about. Dropping the analogy, seriously, do you ever take a step back and consider how much it’s changed? JS used to be a very personal language. You didn’t share it with a compiler or a test suite and, if you were like me, you were the only person on your team who understood it and thus the only one who looked at it. It feels very public now, and I don’t mean once you put it on github. I mean that there are best practices, and they aren’t the secret handshake of a few embattled front-end developers stepping all the way out of the closet for the first time. Hell, sometimes they don’t even come from JavaScript developers. I repeated something I hadn’t fact-checked in nearly two years at work last week and some corrected me with a jsperf. For a minute, my unspoken reaction was, “It can’t be wrong, I learned that at a JS conference!” And then I realized that you don’t have to go to those conferences to understand things anymore, and that over the past year I’ve seen at least as many conference talks taking stock of state of JS as I’ve seen unveiling new or revelatory information.

As JS developers, we don’t really move JavaScript forward anymore. Browser vendors do that. Library authors who used to be the only people making our jobs possible without risk to our sanity are now just providing consistent abstractions around techniques that are built in, backward-compatible API calls that let our code remain the same while the logic moves from something written by us or developers like us to a part of the platform we’re writing for. And that’s what I actually want to talk about.

At SXSW this year, someone predicted that jQuery would not exist – at least, as we know it today – in two years. It was kind of one of those things where your mouth goes, “What?! That’s ridiculous!” while your brain goes, “Whoa, of course.” Obviously jQuery continues to improve, but in terms of the stuff that people desperately needed it for, it seems to me it’s been stable for some time. When I began my job last week I found out that there are a few parts of the site we’re in the process of upgrading from jQuery 1.3.2 to 1.6.2. I asked why we weren’t upgrading to the latest version. Part of the response was that the upgrade had begun when 1.6.whatever was the latest version. The other part was that the difference between the slightly-older and most-current versions didn’t seem compelling enough to justify starting over.

The idea of an optional jQuery upgrade is somewhat fascinating to me. People got stuck on 1.3, that’s understandable. There was a legitimate risk of things breaking, and how many sites had a full suite of regression tests at that point? But when did it become an option to not upgrade for lack of perceived value instead of threat of destruction? I don’t know, but I feel like it was recently. And although I think the changes since jQuery 1.6.2 are pretty fucking slick, I have to agree that the world isn’t going to end if we don’t upgrade immediately, or even if we never do.

My impression is that we’re in a brief window right now where jQuery still has a brilliant team of people working on it, but is stable from the perspective of most users. The most advanced might care deeply about event delegation and the features of deferreds, but someone who merely wants a reliable cross-browser click handler probably doesn’t give a shit. And they no longer have to. jQuery and others solved the problem so well that we can all safely forget there was a problem. Unfortunately, I think that means once there are no more improvements to make to event handling and no more features to add to deferreds, the brilliant team will begin moving on to other projects. I think the same will happen to Backbone, and Socket.IO, and whatever goofy-ass transpiler is cool right now. The things we had to do manually moved into libraries and tools, and the things we needed libraries and tools for are moving into the browser. It’s just a matter of time.

So if you agree that the sky is very slowly falling, what do you do about it? Two things. First, you begin to insulate yourself. Second, you take an active role in making sure the things you need most survive as open-source software and don’t get tied to larger projects whose futures may not include the relevance they enjoy now.

I’ve been about insulating yourself from plugins for some time. That’s cause I worked for a company that had three different dialog plugins in use and getting them standardized was a pain in the ass. When one was discovered to lack some important feature, no problem, someone would download a different one, implement it on a new page with new site-wide CSS to make it appear similar to the old one, and now there would be two ways of creating a dialog. Clearly that’s fucking stupid. But many places settle for standardizing on one dialog plugin, or one UI library that contains a dialog widget, and leaving it at that. I think you should go a step further. Don’t rely on developers (present and future) to know that you use jQuery UI for everything except this one super-special dialog. Instead create a library namespaced with your site or company’s name and put everything under there. I don’t give a shit if CoolCo.dialog has a signature that matches the plugin’s exactly and contains only one line where you pass the plugin its arguments. Wrap everything up, put it in the same namespace.

Once all your shit is insulated from the tools you’re using, begin looking at the methods you rely on. Are you using jQuery selectors but only targeting cutting-edge browsers? Maybe that’s something you could replace with querySelectorAll. Is that necessary? Will it everything super fast? Is there a big risk that jQuery selectors suddenly become monstrously inefficient? Probably not. But, on the other hand, it protects you from Bizarro John Resig. Bizarro John Resig is a theoretical maintainer of the jQuery project who will emerge in the post-apocalyptic future of web programming and decide to rewrite the library to optimize it for WebGL, and remove everything else. When that happens, you will be glad you’re using CoolCo.qsa instead of the dollar sign.

To put it another way, there’s excellent broadly applicable code in jQuery now that – for the things the library’s known for – gets the job done remarkably well. Once jQuery reaches a point where you’re very excited about the features a segment of the code provides, freeze that method yourself by copying it into your code. When a change to that feature that you need comes along, swap the code out. If you’ve insulated yourself well, hopefully the way your library uses the functionality doesn’t have to change.

I can see that you think I’m totally crazy and living in the nineties and a bunch of other perjoratives. That’s fine. Copying and pasting code is bad, isn’t it? Well yes. But as we move toward a point where all the JavaScript developers are getting bored and antsy and making things like freaking CoffeeScript, it’s smart to begin thinking about where you plan to get off the bus. Cause mark my words, this bus is headed to Crazy Town. The obvious practical problems are solved. Solutions to the difficult and subjective architectural problems are cropping up all over the place and converging on a few different philosophies. Eventually the geniuses of JavaScript are going to have nothing more amusing to do than make shrinkrays and giant homicidal robots, and you’re still just going to want your selectors to work in Chrome 1643 the way they did in Chrome 18. You see what I’m saying?

So in addition to building a fortress to protect you from the giant robots, there was a second point, and this is about avoiding copying and pasting wherever possible. Let’s go back to dialogs. You know what’s awesome about jQuery UI? It’s modular. If you just want dialogs, you can just get dialogs. We need everyone to do that. We need the pieces. Instead of downloading a package of everything including the kitchen sink we need modules. I think about this a lot when working on node stuff. Node lacks many things that are very monolithic. A lot of people are annoyed by this. The more I think about it, the more I like it. Your application should be written to run your application. There’s a new version of node? Of course there is, it’s Tuesday. Does it give you anything you need? No? Fuck it. Wait until you have a reason to move. More importantly, if a project progresses in such a way that it’s introducing dependencies that aren’t relevant for your app, consider whether it’s appropriate for you to maintain a fork without the dependencies that provides a subset of the functionality.

I feel kind of awful saying these things, but I believe them. It sounds like I’m saying write JavaScript that’ll live on a mainframe in a basement. That’s because that’s what I’m saying. Your application will either die or it will live on a mainframe in the basement. That field ain’t gonna stay green forever. Eventually your JavaScript is going to get old. Somebody should start planning for its future.

The first presentation I ever gave at a conference was on templates. jQuery templates, specifically. It’s weird – it’s a topic I’ve never presented about again yet one that, if anything, I’ve become more obsessed with. So it stands to reason then that I still find myself in conversations about templates with other JavaScript developers, and sometimes with developers who’ve put off using them, or put off actually making a choice and have just gone with whatever their favorite framework uses as a default. So I sometimes hear people asking how you choose a template engine.

Well! I’m so glad you asked. It’s a giant pain in the ass because almost all of them do the same things, in the same way. The performance differences among those that are similar are nominal. The syntax is almost always mustaches or ERB-style <%...%>. Almost none of them run exclusively on the client-side anymore, even those that take a DOM-centric approach to rendering. To try and tease out the subtle differences, I put up a simple GitHub page I hope you good folks will contribute to allowing you to select your priorities and do process of elimination on the existing, supported, non-framework-dependent options.

But, I mean, going and clicking a bunch of little radio buttons is the easy answer. If you don’t know where to begin, good enough. I think the more interesting discussion is about what developers need from template engines, and whether they should continue writing new ones. There are a few big criteria I see (and that’s what’s reflected in the initial version of the tool):

speed

It seems like two years or so ago, performance was all anyone cared about. We’d figured out all this shit like loading scripts at the bottom of the page and concatenating everything to make pages load faster and that was the new frontier, motherfuckers. It feels like the pendulum is beginning to swing back the other way now, and I hear people reference Moore’s Law more often as justification for things not being super speedy. Complicating things are the way the most modern browsers work. The optimization of traditionally slow approaches flips what we thought we new about performance on its head, so what does “faster” even mean, really? Generally, it means “faster” for your users. It’s good to start with the fastest template engine. It’s better to optimize for performance the way your users need it.

strings or DOMs

Pretty much no template engines deliver a representation of a DOM hierarchy anymore. This is good, because it’s objectively, inarguably faster to build a string, not a representation of DOM elements. But what do you do with that rendered string? We can assume naïvely that what we’ve rendered, once rendered, won’t change, but come the fuck on. This is the dynamic web! We’re going to have to go fishing through our giant, quickly-rendered string, pull out individual elements, and do stuff to them. Specifically, we’re going to have to change their rendering. You could optimize the hell out of your templates so that those child elements have their own templates included as partials in the parent template that renders a larger block, but you are giving yourself an awful lot of credit for organization and diligence if that’s your plan. There’s really no perfect and sane compromise. It’s another one of those things where you need to evaluate how your app will work and how large the chunks of the page suitable for re-rendering can be.

religion

I’ve already said on this blog what I think of rabid focus on separation of concerns, but there are plenty of other opinions, almost all just as strongly held. There’s a belief many people share that getting all logic out of HTML will lead to a perfect nirvana of web development. And I’m not saying this to be a dick, but it really is like religion – that’s the end in and of itself. There is an argument with regard to template engines that’s basically one of morality and, in choosing one, you have to either take a stance or decide that the whole thing’s silly and just decide based on your architecture. Which is what I’d actually recommend, because sticking all your logic in your template can result in just as big a pain in the ass as moving it all to a view model if it’s not appropriate for your needs. How to decide? To my mind, a page that’s representing some data model very directly is a better fit for a logic-less approach, while one that’s doing a ton of transformation and computation for presentation is a good fit for something like microtemplating that’s unadulterated inline JavaScript.

But hey, please don’t take my word. I’d love it if you played around with the GitHub page, and love it even more if you contributed issues or pull requests to make it more useful. I’d especially love it if you contributed to one of the existing template engines before making your own slightly-different one, cause choosing one is already difficult enough.

Maybe it’s just me, but it feels like lately diversity is falling out of fashion as a goal in this industry. I made a tweet seeking sponsors for All-Girl Hack Night’s SXSW event earlier and was surprised by some of the responses. It seems like recent conferences have fewer female speakers, or are more defensive about having none at all.

I thought we were getting better? I thought we’d beaten the dead horse of Why It’s Important To Make An Effort To Include Women and were now in the Fixing It stage? I thought we were safe not talking about this anymore? What the actual fuck, you guys.

Setting aside my dismay at the appearance of backsliding, let’s revisit that imperative Why. Yes, we do need to actively seek out women and people of color as employees, contributors, speakers, and other participants in developer communities. We need to do this because:

• we’re hemorrhaging women and people of color at the earliest levels – if you ignore them, they will probably be gone by the time you’d expect them to be “qualified”
• speaking of “qualified”, if your meritocracy rewards white guys almost exclusively, your meritocracy is a fucking joke
• if you truly care about making this industry better, you try to get all the help you can
• it is – bluntly – wrong that women and people of color were so pointedly excluded for so long, and treating the resulting diversity debt as “the way things are” when it’s a status quo people put effort into creating is utter bullshit

So, yes folks, you need to seek out diverse participants in whatever your endeavor is. The excuse that you’re choosing the best people regardless of gender or race is a fundamentally stupid argument. You’ve already ruled out more than half the population by targeting the population you’re targeting when you target developers. If you want the best developers – not the people who best fit the good ol’ boy developer archetype – you have to work harder, you have to look specifically for the people you know the industry will not automatically support. Women and people of color do not rise to the top level of this industry without someone acknowledging that they aren’t white guys. I know people – women and people of color – who probably hate me for saying that. Sorry. But it does not matter how brilliant you are in this industry if you’re not a white guy until someone in a position of power looks at you and chooses to look beyond your sex or the color of your skin. I want to throw shit when the best women in this industry make claims like, “I did it and if you were as good as me you could do it too” because it’s not just about being good (nevermind that you shouldn’t have to be literally the best of the best to get a seat at the table if you’re not white and male). It sounds like people who inherited money telling poor people to work harder to change their circumstances. There’s luck involved. At some point you had to be lucky enough to be noticed by an insider who took the time to realize you were brilliant. We’re defending a system where achievement and recognition comes not from hard work and genius – merit – but from circumstance.

And before anybody says it, I want to address what I know is coming: “But women get more opportunities! They get considered before equally qualified men!”

1. You’re whining about what’s fair to a group of people who dominate this industry to the exclusion of anyone else? Really?

2. Women do get pushed to the front of the line. That’s affirmative action, and affirmative action is the worst way of achieving balance, except for every other way that’s been tried. Doing nothing has a 100% failure rate. Affirmative action is frequently the only way we see anyone who’s not a white male in the next cubicle or on a stage or a list of core committers. Fucking sucks that we need it, but we are nowhere near the point where we can stop using it.

3. The assumption that if you have an equally qualified man and woman it’s unfair for the woman to get preferential treatment is lulz. What entitles the man to be the default?

I’m sorry I’m being mean, but goddamn it, you guys. I’m sick of hearing this same tired bullshit, as though it occurred to no one to actually look the fuck around and see that this defensive attitude toward ignoring the fucking problem and hoping it goes away is making shit worse.

An article was published yesterday in one of Austin’s local papers about Austin’s tech talent shortage. I was job hunting just a couple months ago and get a lot of calls from recruiters and hear about friends’ companies who are hiring and I think it’s pretty damned accurate. And by accurate I mean that it points out how fucking ridiculous some of these companies are being. Flying out to SF to try and steal engineers away but not being willing to match their salaries? Seriously?

Dear Austin companies: It doesn’t matter whether you think developers are a commodity. You can’t treat them that way. You don’t get to set their market value – the market does that. You can’t compensate them with pool tables and tacos. You can’t ask them to spend an extra 20 hours a week making up for your shitty management decisions or commuting to some isolated office park that was cheaper to rent than something on a goddamned bus route. There is a give and take and nobody’s obligated to come work for you. Balance is necessary in all business relationships, even relationships with less business-savvy nerds.

money doesn’t matter until it’s not there

One of the most damning quotes in the article is, “I’m not going to pay the California wages, which can be 30 percent higher.” I’ve had a large number of bosses who believed for some reason that the chance to contribute to what they were building should be more important to me than my compensation for doing so. That’s fucking ridiculous. If I’m making you rich, you pay me to do so. You’re the one getting the big payoff at the end, not me.

Austin companies should be thinking in terms of how much further a California salary will stretch here and using that as a negotiating tool when they offer talented engineers what they’re already making – minimum – to relocate. If those engineers are relocating from the damned Yukon, same thing, because I can fucking guarantee you that if they’re open to relocating they’ve got an offer from somebody in SF, too. A higher salary is going to cost you less than hiring shitty people or not hiring anyone. There are a gazillion blog posts about this from people who actually run software companies, not bratty engineers, so, hey, don’t take my word for it. But if you think you should get some kind of discount cause your business is based in a town that’s figured out how to put scrambled eggs in tortillas, better disabuse yourself of that shit.

your office is not magical productivity land

There’s nothing that makes me sadder than talking to an awesome company about a job, knowing that they want me to move to San Francisco or drive to north-goddamned-Austin every single day and I’m not gonna do that. Is that stubborn? Yes. But I have a challenging housing situation I can’t get out of and commuting goes against the way I choose to live my life. If it was just me, that’d be one thing, but it isn’t. Lots of people can’t move, or don’t believe that spending two hours on the freeway every day is a healthy lifestyle. But guess what! We don’t expect you to move your whole office to wherever it is we happen to live – we’re generally happy to telecommute!

If I could relocate, Austin sure as hell wouldn’t be my first choice. I moved here when I did because my ex-husband and I had blown most of our savings on our wedding but were desperate to get out of Seattle, and I knew the lower cost of living here would make it possible for me to support both of us if he couldn’t find a job for a while. If I’d been single, more confident in my skills, and sans wedding debt I would have moved to San Francisco or New York. Austin’s lovely, but I like being able to get a decent bowl of ramen. And take public transit. Of course I’ve since fallen a little bit in love, but when I moved here everything was brown and ugly and covered in strip malls and I had to keep reminding myself of the spectre of Seasonal Affective Disorder waiting for me if I turned tail and went home. Anyway, it’s not objectively everyone’s cup of tea. Maybe somebody wants to live in middle-of-nowhere fucking Montana all River Runs Through It. Maybe they’re the best Python dev the world’s ever seen. You don’t know.

There’s a popular theory that people are most productive when they all sit together in big echoey rooms at communal tables with no dividers between workspaces. I think that’s horseshit. The only people who are “productive” in those settings, in my experience, are the type of management people who feel compelled to come over and interrupt you in person rather than send you a fucking email you can look at once you’re done tracking down a bug six levels of callbacks deep. YOU KNOW? If your company lacks the tools to communicate remotely, it’s highly probable it can’t communicate at all. As for exposing devs to their peers, I agree it’s a pleasure to work next to other JavaScripters, but I also see better peer interaction between people who don’t work for the same companies every day on IRC than I have in any office I’ve ever been compelled to go to.

Companies who don’t demand that engineers come to them have power right now. Over the past two years I’ve switched jobs a number of times and have interviewed a shitload. I’m not the best, but I’m good, and I’ve only been turned down twice. Guess what both companies had in common? If you think your company is getting the shit end of the supply and demand plunger, try opening your hiring up to remote employees.

do something interesting

This is harder. There are a lot of companies using the latest, hottest technologies that probably won’t exist in a year. There are lots that do pretty boring shit, are tied to legacy code, but are stable and responsible. This is an Austin-wide problem, but also a problem for individual companies to solve. To attract technical talent, a city just has to have cool technology happening somewhere. It just does. Nothing is exciting when all you and your friends have to talk about is the best jQuery plugins to use in building a fly-by-night groupon clone. People get excited when one of their peers is implementing Node in production or switching over to NoSQL or whatever. It makes nerds feel competitive, it makes them more engaged because they don’t want to be left out of playing with the latest coolest thing, so they go home and put something on github if they can’t do it at work. But if all the companies in town are focused on money first and technology never, too many “tech” conversations are about funding and other business-y shit which gets really boring, at least for this engineer.

If your company makes something entirely uninteresting, that’s fine. We need useful software to fill niches, or our whole industry suffers. If you make a boring thing, there are two things you can do to still attract good talent. First, if you don’t need a senior dev, don’t hire one. Hire a junior person, give them the chance to architect small changes to the system, help them grow as an engineer. If you do need a senior person, hire them, but carve out 10% or 20% time for them to do open source stuff or personal projects or whatever. And don’t get all butthurt about paying them to do things that “don’t create value”. You probably use open source software. Your devs’ skillsets need the support of a larger community to stay current. And bored developers quit producing and, well, quit. If you can’t make your product interesting, that doesn’t mean you can’t make your engineers’ jobs interesting, and you’ll benefit indirectly.

It’s hard not to read an article like this one and feel smug, but it’s also hard not to feel frustrated. At the end of the day, we’re workers. We’re some of the only workers in this economy with any control over our professional lives, who don’t have to live in fear of unemployment. It shouldn’t be possible for companies to bleed talented people dry in exchange for the minimum possible compensation and bullshit perks like foosball tables, yet somehow it is.

A former boss of mine is quoted in that article, and I know he’s one of the good ones, and treats his engineers as respected employees who play a huge role in the success of his company. There’s an opportunity in this for executives like that, clearly, because so many more bring only a mediocre idea and a pile of VC cash to the table and expect to pick up developers as though we were all standing around idle on the corner outside Fry’s. There’s no more sense in competing with those people for bargain-basement talent than there is in working for them, and I think it’s pretty easy to avoid having to do so for companies who can be a little more flexible.

I just watched a short video called How to Get More Women in Tech in Under a Minute. The speaker, Caroline Drucker, is making a point about the toxicity of the word “girl” and how it hurts the cause of women in technology. Her argument is that every time we refer to ourselves as girls, or allow others to, we lose ground in our profession. I’ve got two problems with this. First, it wildly oversimplifies a super complex issue. Second, it’s in opposition to the goal of including more women.

I admit it sounds good on the surface, and it would be wonderful if all we had to do to close the gender gap (she’s not literally saying that) was to stop calling ourselves girls. You could say I’m predisposed to disagree, having started an organization that uses the word “girl” in its name and organizing the Austin chapter of a second. And I do disagree, but not just cause I don’t want to think of myself as the kind of woman who undermines the power of women collectively. Nope. The word “girl” in Austin All-Girl Hack Night is there quite intentionally.

I know women who are driven just as crazy by the use of the word “girl” as the presenter and the other women she references, and they have every right to feel that way. But I’d like to speak for the other side, as someone who frequently refers to herself and other women as girls, and is much less likely to refer to “men” than to “boys”, “dudes”, or “guys”. As a feminist walking what I perceive to be a damned thin line between making my point and making people uncomfortable, I choose casual language over formal pretty much every time.

Ms. Drucker touches on something I think is worth expanding on, which is the difference between us when we’re being women and when we’re being girls. And I think she implies that all of us – as adult women – are sometimes both. We never stop being grown-ass women, that is, but that doesn’t prevent us from acting like girls. Exactly like our male counterparts when they’re being boys, we’re fallible, we’re vulnerable, we’re sometimes immature and entirely too human. We might wish it would, but this doesn’t stop we we cross the threshold into our offices. Like it or not, sometimes we’re girls at work, too. Being a girl sometimes is part of being a woman.

But, fine, certainly male professional associations wouldn’t highlight those weaknesses. I have a question for women in tech organizations, though: where has all that careful naming gotten us? Have the organizations, conferences, articles, and movements that use the word “women” instead of “girls” or “chicks/chix” been markedly more successful? Anecdotally, it seems like no. At minimum, the two distinctions succeed in different ways.

Cause here’s another thing about women: for a long time, women weren’t supposed to hang out with men. Girls, by contrast, have in almost all cultures been lumped together with boys. Girls and boys are temporarily sexless, they’re treated more similarly than they probably will be for the rest of their lives. One good thing about the words “girl” and “boy” is that each implies its complement. When it comes to organizations that exist to integrate women with their male peers, I’d argue that “girl” is exactly the right word.

So those are the logical reasons I reject Ms. Drucker’s argument. The subjective reason, and what I was alluding to when I said I think her argument has the potential to hurt rather than help, is this: women are not all the same. Even feminists are not all the same, nor are people who choose technical professions. You can’t tell other people what to call themselves. There’s a long debate over whether you can change the power of a word like “bitch” by reclaiming it and using it in a way that’s casual and not derogatory. If we can’t settle that, we can’t tell other women which neutral, relatively unweighted word they get to label themselves with. Not all of us feel comfortable as women. Some feel more comfortable as girls. While “girl” may be a diminutive, a girl is also someone who climbs over fences and shaves half her hair off before someone catches her and draws on the walls.

I’m very much against the idea that women need to behave more like men in order to succeed, but there’s one thing men definitely get right: they respect each others’ independence. As women, we seem to be raised to do the opposite. There is no Catcher in the Rye for us, no On the Road. To me, telling women they’re fucking something up if they don’t call themselves women is like telling them they’re shitty moms if their kids go to school in hand-me-down clothes. The western tradition of passing mores down matrilineally and holding women to a standard we’d never expect of men seems to me to be making an appearance here, and that’s not constructive. You don’t tell other women who to be. You support whoever they choose to be. That’s how we get more women. If you don’t believe me, consider the “geek room” study, and how our industry’s been affected by the stereotype of the nerd. We already have women ignoring their technical calling because they feel they don’t like D&D enough. Let’s not make the ones who get past that barrier feel bad for being insufficiently earnest feminists.

In closing, I want to explain my personal use of the word “girl” in Austin All-Girl Hack Night. There’s a Salt-N-Pepa song – Expression – that contains these lyrics:

Yes, I’m blessed, and I know who I am
I express myself on every jam
I’m not a man, but I’m in command
Hot damn, I got an all-girl band

That’s why Austin All-Girl Hack Night is called what it is. Cause I listened to a lot of Salt-N-Pepa as a teenager and that’s where my picture of feminism comes from. It doesn’t mean every woman who comes to hack night has to agree, but it is in some way meant to suggest a more casual relationship with feminism and professionalism and a stronger emphasis on community and camaraderie. And, yes, even immaturity. It’s hard work being a grown-ass woman all the time. Sometimes it’s nice to get a bunch of girls together and draw on the walls. Maybe we get more women in tech by telling them they’re allowed to be girls sometimes and don’t have to be perfect women.