Archive for May, 2012

what the fuck is an entrepreneur

Thursday, 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

Tuesday, 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

Wednesday, 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

Thursday, 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)

Tuesday, 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?