Blog Action Day (#BAD13): Workers Are Human, and We Have Rights

One morning this past summer seemed like most others: I left my house at 7 AM, to start my two-hour commute to my contract job in a Bay Area exurb.

The BART train arrived punctually. I was glad I had a reverse commute, which required a nearly hour-long ride across the drab, de-industrialized stretches of southeast Oakland; I nearly always had a seat going to work. The passengers headed the opposite direction to San Francisco, didn’t have this privilege, even at this early hour.

To while away the time, I reviewed the stream of tweets on my phone. There was quite a lot of indignation over the recent strike by BART workers, not much directed at BART management–the Twitterverse seemed appalled by the benefits and salary protections demanded by blue-collar transit employees. Meanwhile, the train dutifully stopped for the students, retail clerks, construction guys, and home health aides getting on the Fruitvale, Coliseum, San Leandro, and Bayfair stations. A few passengers dozed. Sometimes a young guy would enter the car, looking at us half-asleep drones with apparent distaste, and hastily exit, as if we threatened him with some contagious disease.

I checked the news from back home in Arizona. Fire season. A photo of the twenty Granite Mountain Hotshots posed in front of an ancient alligator juniper they’d protected from wildfire. Now the hometown news included the story of a Hotshot’s wife denied benefits because her husband wasn’t classified as a permanent, full-time employee. He was, however, permanently, full-time dead, killed on Yarnell Hill with eighteen others.

At Castro Valley station the train passengers started including more people carrying computer bags. By the end of the line–Dublin/Pleasanton–most of us leaving the train looked to be white-collar tech workers. We moved through the BART station in quiet, somnambulant order, every movement calculated to bring us to the next stage of our commutes to distant office parks–to the buses, the shuttles, the sidewalks and bike paths. All this uninspiring travel, just for our paychecks.

The organizers of Blog Action Day prompt me to write about “human rights.” There’s plenty of cause for outrage–the rights of women, of the non-heterosexual, of civilians, of people of color; all of these denied in some way, somewhere, every moment of every day. I’m confident a blogger will address them eloquently. What I’ll treat instead are the rights we seem to have forgotten in our grubby, half-awake, workaday lives. Those are workers’ rights.

Workers’ rights are human rights.

As workers, and as human beings, we have:

  • the right to complete compensation for our work, including pension and health insurance benefits;

  • the right to compensation for every minute we spend working;

  • the right to reliable transportation to our job sites, the costs sustained by taxes on the corporations which benefit from our labor;

  • the right to join other workers to bargain with management, and the right to strike;

  • the right to be hired and retained based on merit, not on racial, gender, or class identity;

  • the right to employer loyalty in exact proportion to the loyalty we show the employer. The right to protection from “rightsizing,” moves, and offshoring when we have kept up our side of the relationship;

  • the right to be paid and treated the same as our native-born colleagues, no matter which visa arrangement brought us to work in this country;

  • the right to compensation when our jobs have maimed or disabled us; the right of our survivors to compensation when our jobs have killed us;

And, to my mind, the most important:

the right to discuss these rights, in public, worldwide, without retribution.

Ada Lovelace Day (#ALD13): Anca Mosoiu

Erika and I entered the wrong door at first, learning only by the flash displayed on the walls that we were in the tattoo parlor, not the conference room where we’d meet our client. Once within the appealing 1920s store front adjacent, we met a serenely smiling young woman welcoming us to Tech Liminal, Oakland’s first co-working spot. The space was so newly opened a fan blasted on “High” to disperse paint fumes. The décor was a mix of sleek tech and East Bay thrift; we felt right at home. Met the client, concluded our business, finished the project–and I kept returning to Tech Liminal.

I came to evenings about jQuery, Python, and WordPress. I watched a fascinating presentation about the Internet as used in Iran and Estonia. During the Occupy Oakland hurly-burly just a few blocks away, I went to a Meet-up all the same, even if a police helicopter felt obliged to follow me as I rode up Alice Street on my bicycle. When the Indiegogo campaign for Tech Liminal’s move to swanky downtown digs started, I didn’t hesitate to contribute.

Heck, yeah. Anything to help Anca Mosoiu.

Let me tell you a little about Oakland, California. We’re just across a bay from San Francisco, we’re about a third its size, and about half its population. News stories about Oaklanders tend to paint us as fearful crime victims picking through the rubble of a de-industrialized wasteland, California’s Detroit. In the last three or four years, though, Oakland’s received some positive attention for its lively restaurant scene and its (relatively) less overpriced real estate. The hipsters have conspicuously moved in. Oakland! San Francisco’s Brooklyn!

Those of us who’d been living here all along already knew this, of course. I wasn’t the only one who’d given SF life a good try, but came to Oakland to stay. We knew Oakland had wonderful qualities–redwood forests in the hills, reusable factory buildings on the waterfront, and inventive people all over town.

But what matters is what we did, which, for most of us, was pretty much nothing.

Anca had the courage, vision, and stamina to stand apart. She didn’t want to recreate the self-absorbed SF tech scene. She studied who works in tech in Oakland, and found a group distinct from the lookalike bros blathering about this month’s trendy JavaScript framework in South Park: people who work for small businesses. People who maintain blogs for their churches or non-profit agencies. People concerned about maintaining content in multiple character sets. People who are performers or artists, and need a higher level of digital literacy to promote their work. Oakland people.

I’ll never know how discouraged Anca felt as she struggled to establish a tech business not just in Oakland, but in the depths of the Great Recession. I’ll never know if she ever doubted her vision of Tech Liminal as community center, as more than rental space. One of Anca’s most admirable qualities is her steady, reassuring unflappability. Around someone like that you feel sure the future’s going to be fine. Maybe it won’t be slick, maybe it won’t rain VC money, maybe it’ll be next door to a tattoo parlor. But it’ll bring in other people, their energy and ideas, and soon enough the whole thing has greater momentum than a skateboard flying down Keller Avenue.

Thank you, Anca.

2013: the year we stop using PSDs

Today I’m deep into preparing my slides for the HTML5 Developer Conference. Topic: “Making Peace with Twitter Bootstrap.” I have forty-odd minutes to soothe everybody’s ills with this ubiquitous framework. Since it’s a developer’s conference, I’ll emphasize solutions for people like you and I: front-endy things about SASS and Bower and whatnot. This will be the reasonable-sounding part of the presentation. Then, in real time, I’ll fight the temptation to disintegrate into full-on rant mode.

Here’s what I’ll try to say with terse, politely worded slides, rather than foaming at the mouth:

No more PSDs.

Stop it with the goddamn PSDs already. Fer Chrissakes, it’s the year 2013. High time to stop pretending to simulate Web applications with twenty-three-year-old image editing software.

Okay, so you’re a visual type, and you like to sketch your ideas in Photoshop? Fine. But for the same reason you don’t hand a page torn out of your Moleskine to your developer, you shouldn’t hand her a freakin’ PSD either: both formats communicate very little about what you intend for the application interface.

As Mule Design Studio puts it,

A PSD is a painting of a website.

If your interface links to framework stylesheets, and your application’s stylesheet bristles with !important rules overriding those styles, it’s a definite sign your project isn’t using the framework’s styles effectively. There are a couple of sources for this problem: 1) a developer not understanding how to use CSS selector specificity to create new styles; and 2) a design completely, totally detached from what the framework offers.

Want to drive Web developers insane really fast? Require them to cram Twitter Bootstrap, ZURB Foundation, or pretty much any CSS framework into a design dictated by PSD. In this workflow the designers and developers never discussed nor established viewport breakpoints, element widths, line heights, and such ahead of the design and development process, and fashioning something resembling the Photoshop comp out of pre-built components becomes an exercise in crazy-making CSS stunts. Meanwhile, the really necessary work of creating responsive design goes undone–what really happens is more like Reactive Design, when somebody glimpses how awful the interface looks like on somebody’s phablet, and then there’s a mad scramble fifteen minutes before the client meeting to patch over the rough spots hoping nobody notices.

My freelance rate is by the hour, and this kind of unanticipated rush developing can be lucrative. But it enrages me instead, because it’s entirely unnecessary. These days a Web design is properly devised in markup and CSS. Don’t like the associated learning curve to do this by hand*? Then use any of the following alternatives to Photoshop:

  1. Adobe Edge Reflow. Even Adobe wants you to stop delivering paintings of Web sites.

  2. Easel. Design for the browser–in the browser!

  3. Jetstrap. Get rid of that whingeing front-end developer and make the interface yourself.

Why are you still designing Web applications in Photoshop?

* A link to a design blog post from over three years ago.

My Joel Test

This year, the Joel Test marks its thirteenth year (does it get a bar/bat mitzvah?) For all the publicity and parody it gets in developers’ media, it seems little-known elsewhere–I still get panicked stares when I ask about it in job or project interviews (“The JOLE Test? Is that one of these HTML5 things we’re supposed to be doing?! Maybe it’s that responsive design stuff! Must–nod–head–sagely…”) So, here’s what the Joel Test is, if this is the first you’ve heard of it:

In August 2000 software entrepreneur Joel Spolsky listed several questions he thought would reveal the quality of a software development team. Observers noted the list could become something a developer should ask a potential employer before accepting a job offer, because Spolsky’s questions focus on aspects of a programmer’s working environment that make enormous differences in job satisfaction, yet are rarely described in detail even at the interview stage. Each question can be readily answered “Yes” or “No”, and the complete list of answers could help a programmer determine whether a particular job offer includes things important to her.

Here’s the Joel Test below, but I encourage you to read Spolsky’s justifications for each list item.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

I’ve never worked on a project that would pass the Joel Test. I’ve worked on some projects that rated only seven Yes answers, but they were indeed better experiences than the ones who rated even lower. My 2013 resolution is to join a project that garners at least eight Yes answers on the Joel Test–doesn’t even have to be an A+, just eight skimpy “Yes” answers.

A useful supplement to the Joel Test is software engineer Julie Pagano’s response to recruiter spam unsolicited queries, which doesn’t just list what she values in a job, but weights each in importance to her: is the job far away? Involving Windows? Assumed to be the only thing in a developer’s life? I see many items on Pagano’s list which could be on many of ours; I hope recruiters do see her post and take note of what’s really important to candidates (short answer: it’s not foosball).

Combining the two approaches, I emerge with this:

My Joel/Julie Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you have a bug database?
  4. Do you fix bugs before writing new code?
  5. Do you use an issue tracker?
  6. Do you have requirements before writing user stories?
  7. Do programmers have quiet working conditions?
  8. Do you have testers?
  9. Do you purchase the exact tools your programmers request?
  10. Do you use Agile methodologies?
  11. Do you use only open source software in your application stack?
  12. Do your developers have their own tech blogs or present at meetups?
  13. Do your designers work only in Photoshop/graphical editing software?
  14. If I dropped in here some random weekday night at, like, 8:30PM, would your developers still be at their desks?
  15. Would you give me a hard time if I wanted to telecommute one or two days a week?
  16. Can I get to your office from Oakland by transit within 45 minutes?
    Red indicates a failing test.
    Red indicates a failing test.
  17. Can I bring my bicycle to work?

What’s on your Joel Test?

Test-driven CSS Development

I’m not the only one to have searched this phrase. Many front-end developers (including, it seems, a statistically significant number of people named Simon) crave the benefits of a TDD-like process when devising stylesheets.

The dream: define styles at the beginning of a project, test them for validity, performance, browser interpretation, then continue development feeling assured that you’ve satisfied all requirements and that you won’t meet any nasty browser surprises upon launch.

The reality: a process, not yet susceptible to automation. You’re still using your own eyes and hands to evaluate whether your CSS meets your project requirements. The good news is that there are a lot of people discussing this, and building tools to help out with it.

TDD for CSS. OMG!!

Start with the stylesheet, not markup. This is becoming common as more of us use CSS frameworks for tasks such as grid layout or responsive design. As you add markup, keep assessing whether you’re really using all the rules in your CSS. Prune the ones you won’t use. Tools to make this assessment include:
* Chrome Developer Tools. Under Audits>Web Page Performance, run Web Page Performance to obtain a report of which CSS rules have gone unused by your page.
* Firebug CSS Usage add-on. Click Scan, and see all your CSS rules evaluated for relevance to the page loaded. The tool will even export a cleaned CSS file that prepends the unmissable string UNUSED to rules found useless.

Validate your CSS as you go along. The solution to that wildly inappropriate heading styling might be as simple as a neglected closing brace, or an invalid rule (go on, claim you haven’t typed font-color:... at least once). Don’t wait until the moments before deployment to discover how many of your style rules are invalid.

Create a style guide page with samples of all element styling. Jade Zahnster promoted this concept for easy CSS refactoring without adding rule bloat. Did you have blue submit buttons on your project’s first iteration, and now you have green ones as well? Keeping an inventory on a single page will remind everyone which rules are already defined and require only extension for the new requirements.

Optimize your CSS. Even if you’re a finicky, careful, solo developer, there will be places in your stylesheet with duplicate, verbose, and unnecessary rules. The best way to discover these is pasting your CSS into the CleanCSS tool, and noting where properties were streamlined.

Check your stylesheet’s performance. What’s keeping those styles from rendering? Why does that puffy-font, rounded-corner, gradient-fill form button not just, like, pop up first thing? Though no less than Steve Souders argues for less concern over CSS selector efficiency, it’s pretty interesting to see which rules in your CSS are creating bottlenecks. Review Paul Irish’s thoughts on performant CSS, the use Andy Edinborough’s CSS Stress Test, which evaluates CSS rules for performance by removing each one from the stylesheet, and noting changes in rendering time.

Keep looking at the browser. The days of having numerous browsers and multiple platforms engaged as you work are, regrettably, not yet past, but there are a couple of tools to help you check for display problems before you open five different user agents.
Simon Kenyon Shepard’s CSSUnit will report how rules are interpreted by a browser, which is useful when you’re trying to understand by how much browser X differs in opinion from browser Y. Mogotest is a commercial service which reports discrepancies between perfection (your favorite browser’s display of your page) and other browsers’ rendering of it.

It’s still all a lot of work; automation and robots can’t do all this yet. Consider it job security.

Sh*t People Say to Front-end Developers

  1. We really don’t need a designer.
  2. What’s an information architect?
  3. Nobody will be looking at this page with a mobile device.
  4. This style guide from 2002 is still good.
  5. We really don’t need localization.
  6. This Excel spreadsheet is our issue tracker. Works great!
  7. Using Flash would make this so much easier!
  8. HTML5 is too risky and experimental.
  9. What’s a validator?
  10. Browser support? All of them, of course.
  11. We really don’t need a copywriter.
  12. Of course our users will sit through this thirty-second auto-play splash video.
  13. We really don’t need JavaScript testing.
  14. The database guy already did the HTML and CSS, so you just have to add a few tweaks.
  15. Of course our users will submit this twenty-question form before seeing our content.
  16. This will be a short project.

Letter to Gino Lee

Dear Gino,

I’d hoped the news was untrue. Surely it was unbelievable: how could you die? You were only forty-nine. You are only forty-nine–I’ll keep using the present tense. You’re still alive to me.

I have vivid memories of you from over ten years ago. There you are, apparently one of the last smokers in California, cupping a cigarette in your hand, trying to keep the wind tunnel outside the Metrius office on Brannan Street from killing your smoke, your characteristic, urbane, thin-man’s slouch a welcome profile in those garish, clumsy, overconfident, dot-com boom years. I remember your voice, deliberate, drawling, as you think aloud, treating every workday as one big Harvard grad seminar. I love the cultivated, wry tone of your e-mails and chat messages, proof that a keyboard doesn’t enforce simplistic language. Your one-line musing about the impact of the Rapture on the scrapbooking industry makes me laugh to this day.

I was too coarse to appreciate that we should’ve taken all the time in the world to talk, deadlines be damned. I know we disagreed when you seemed to think my staying late at the office was so that we could discuss Evelyn Waugh’s The Loved One . I profited from our acquaintance all the same.

From you I’ve learned that so much of our world can be made appealing. Your attitude towards the ugly and poorly designed isn’t snobbish condemnation, but gracious bewilderment: why use bad things? Why make them? You handled fountain pens in a world of dry erase markers.

But I and everybody saddened by this news have to let you go today, arm-in-arm with Miss Thanatogenous. I promise a longer conversation next time.

Tears,
Melanie

Stop arranging developers like the typing pool

A couple weeks into the project, and despite my access to the issue tracking system, the project wiki, and the code repository, I still felt uneasy–there was something I was missing, but since I didn’t know what that was, I couldn’t ask for it. Coffee? Water? Multiple monitors? Appealing snacks? Had all those. I stood above my workspace, and then figured it out:

We were seated all wrong.

All of us on the development team were placed into cubicles arranged into a herringbone pattern pointing to one side of the room. Our faces turned about 25° towards one other person. I became familiar with the backs of many of my co-workers’ heads, since that’s much of what I saw of them all day. It was a bizarre arrangement for the kind of work we expected to do, since it discouraged interaction: you didn’t want to walk up behind someone and tap him or her on the shoulder for just any old thing.

Of course, interruptions are ruinous to developer productivity, but so is
isolation. There was a lot of context missing for me on this project, because it wasn’t available through the commit comments, and asking for it on chat would’ve required my knowing who to ask for what. I was slower to contribute because I couldn’t overhear relevant chitchat and couldn’t catch the eye of the project lead when I had a question, the most urgent one being: why were our workspaces arranged so stupidly?

I envisioned some workmen arriving one morning with a bare sketch of a floor plan in hand, and a general work order: “Build X number of cubicles from this pile of parts.” They weren’t told who’d work in the cubes, nor what was important to us. They acted from assumptions that seemed reasonable, but were still flat-out wrong.

One was that we all needed to have visual contact with one certain thing at one end of the room. Most of us have experience with this kind of arrangement, since it’s how we sat when we attended school. It’s also how clerical workers’ desks were often placed in early open plan offices. Management enjoyed this arrangement, since it permitted easy surveillance of those notorious insubordinates, schoolchildren and women. Placed side-by-side, we have less interaction with our peers, and more with the authority figure at the end of the room. But here in a twenty-first-century cube farm, there was no teacher on a dais to please. Why were we all facing the same way?

To watch a movie? Or perhaps a more sinister activity?

We have always been at war with SVN

The project never required the Two Minutes Hate–well, as far I could tell. Who would’ve tapped me on the shoulder to let me know?

Thrills! Chills! It’s InstallFest!

Last weekend brought the latest RailsBridge workshop to San Francisco (man, these workshops are really gaining momentum–there’s yet another one already scheduled for December 3-4. And, yup, it’s waitlisted). This time I ventured beyond my usual semi-skilled volunteer roles by offering to help workshop participants install the software required for the workshop. At last I felt comfortable enough with the process of getting Rails up and running that I wanted to assist novice programmers with the heinous chore fascinating challenge. Never thought I could do this–and it was thrilling when I did.

“InstallFest” is the happy-face designation we give the Friday night slog before each Rails for Women workshop. All participants must attend so it can be verified they have the appropriate dev environment set up on their laptops for Saturday’s curriculum. I attended InstallFest myself at the very first workshop over two years ago, and I still remember how frustrating it was for me: what are all these commands? Why do I keep getting error messages? And how come we can’t just install Locomotive or InstantRails and get it over with?

"Railsbridge installfest," by Romy Ilano

I’ll take the last question. Workshop attendees, here’s one reason why we don’t want you just pointing and clicking into a working Rails setup: we’re selfish.

Yeah, you might’ve thought all these volunteers watching over your shoulder as you type a lot of gibberish into a console window were selfless angels propelled by righteous sentiment to help you gain entry to the exclusive community of Rails developers. Well, sure, we are, but fundamentally, we’re…

Rails problem vampires.

Didn’t you notice how exciting we found the error messages in your terminal window? How about when we hopped up and down, shouting about malformed Gemfiles? And when two or more of us elbowed each other to peer at that mystifying line of code on your laptop screen–rake aborted (is that legal?), maybe you suspected.

“Hmmm,” you thought. “These people really want to expose me to all the gears, widgets, and thingamajigs that make up Rails, even if those don’t always work.”

My gosh, you saw through it, didn’t you? Your intuition is valid–at InstallFest you were surrounded by people who wanted to know where the installation process breaks down. You couldn’t even see all of us problem vampires–some were watching from afar, via discussion lists. We yearned to see where the instructions confused you and which of those d*mned Ruby gems didn’t load. We can’t make the installation a point-and-click process: there are technical constraints, for one thing, but more importantly, it would deny us that rich diet of error messages we crave and require.

You won’t need to bring a necklace of garlic or a wooden stake to attend InstallFest again. No, perhaps instead you will volunteer, twice, many times. Gradually, painlessly, unnoticeably…you, too, might also become a Rails problem vampire.

“Gazelles” eat hay, not grass

On Good.is the popular posts today include “15 Percent of Americans Are Now on Food Stamps”. I’ve visited the site twice this Monday, once just after the New York Stock Exchange started trading this morning, and now after the market close, as the story of our dismal economy’s enduring lifelessness makes headlines everywhere. In today’s more optimistic forenoon, I read Tim Fernholz’s “Hunting Gazelles: Figuring Out What Makes Companies—and Jobs—Grow”. Some of the points in that article bugged me then. They really irritate me now.

The post is an interview with scholar Tim Kane, who proposes that new jobs in the U.S. economy come from “gazelles,” quick-moving, fast-growing, young businesses. I don’t quibble with this entirely; I’ve seen how many Bay Area tech businesses seem desperate to hire enough people to support their rapid expansion (though–ahem–not desperate enough to modernize their hiring practices). Yet just after sharing convincing data about the remarkable contribution “gazelles” make to the employment rate, Kane veers into territory more familiar to subscribers to Reason than to Good.is:

Photo by Swamibu

There are real structural impediments to starting a firm…Labor regulations can make it difficult for entrepreneurs to even leave, and difficult for firms to hire more people.

The [Sarbanes-Oxley accounting law] is particularly galling because it seems like its[sic] killing off our IPO industry. Without an IPO or the promise of an IPO on the horizon, why start a tech company?

Alright, where to begin?

Let’s start here: one man’s regulation is another’s unemployment insurance, worker’s compensation, and minimum wage law. Your “structural impediment” is my workplace safety standard, whistleblower protection, and equal opportunity legislation. Think Sarbanes-Oxley is galling? Try having your retirement savings wiped out overnight by corporate fraud.

There’s a stubborn belief in the startup world that it’s 100% self-made, boot-strapped, that the “gazelles” broke away from the encumbrances of the herd and now thrive on the nourishing wild grasses of the entrepreneurial savannah. If this were so, why are there so few, if any, gazelles in places with fewer regulations? Why do tech bubbles form again and again here in the Bay Area?

You could re-read Richard Florida, or you could remember this:

“Gazelles” eat hay, not grass.

Meaning: “gazelles” rely on the infrastructure all of us provide. This isn’t just WiFi, Blue Bottle Coffee, and a spot on the CalTrain bike car. It’s also those “structural impediments” like environmental regulation (can you drink the water out of the tap?), public health initiatives (when’s the last time you worried about polio?), and anti-corruption laws (do you have to bribe someone to launch your product?).

Yes, it’s admirable to watch gazelles leap gracefully to such heights. But let’s not forget the haystacks we shore up to feed them.