Why we’ll stop using ID in our stylesheets

Seemed like everybody was talking about CSSLint a couple of weeks ago. I waited for the hype cycle to slow its rotation, then dutifully visited the online linter to pay my respects.

It didn’t repay them.

“Will hurt your feelings” is CSSLint’s tagline. Heh, heh; I’ve written stylesheets for thirteen years now. What faults could CSSLint find with my CSS?

Plenty, it seemed. Chief among the linter’s nagging judgments was my use of the ID selector in so many rules. Now, what’s so wrong with that? How is it that my practice for all these years is suddenly considered wrong?

I found this blog post proposing that the hip, up-to-date stylesheet of today contains no ID selectors. Intrigued, I posted the link on Talentopoly, where it generated a thread of comments from people who seemed indignant with the premise. Why discard a totally valid technique which can make one’s markup and CSS more succinct?

I think one reason we were so uneasy is that we’ve had to work with so much bad markup and styling written by people with poor understanding of the cascade. The result is overdependence on classes for style rules–a classic example would be a navbar with a couple dozen <a class="navLink"> bloating the markup. Expertly written CSS distinguished itself with terse rules attached to ID’d elements. But if you prohibit that, don’t you end up encouraging that stupid “class”-itis?

Perhaps. CSSLint can’t determine if your style rules rely too much on classes. But you can satisfy the linter’s criteria and also target specific elements without resorting to attaching class attributes to every node in your markup. For instance, you could show off your handling of CSS3 selectors instead.

Like JSLint, CSSLint is a tool based on its makers’ opinions of what constitutes good style. It’s not a validator, but an evaluator: it can suggest improvements (as did earlier linters). Using the linter is like getting the opinion of a haberdasher as to how wide your lapels should be: you’re not obligated to act on his advice, but you might look a little strange alongside your more fashionable peers.

But why has the ID selector fallen into disfavor?

Looking at the explanations on the CSSLint About page, I notice a pronounced concern for portable, modular styling. The linter discourages intensely specific selectors such as IDs and “qualified headers” (h* tags within a cascade, or with class attributes). There seems to be less focus on styling an entire, discrete page, and more on styling blocks of content which may be sent or received in an API. This is a reasonable emphasis: think of all the markup you’ve done in the last year. How much of it was for standalone pages? And HTML5 prods us to think of Web content in articles or sections, each with its own h1–our markup and styling are scraps, not whole cloth. It’s efficient to make them fit with others.

Well, so what–it’s just between CSSLint and you, right? No. A less obvious reason for abandoning the ID selector is so that your style rules pass CSSLint when somebody else submits your CSS to it. And this will happen. In a profession with no licensing and very little certification, front-end developers have few means of convincing potential clients that we know what we say we do. If our clients had the skill to inspect our CSS for quality, they’d probably wouldn’t need to hire us to write CSS for them. Tools like CSSLint, despite their basis in subjective opinions of good practice, reassure these clients: they know you’re following certain rules if you pass. They want the work you do for them to be rule-following and interchangeable, not idiosyncratic and difficult to reuse. Yes, a lot of terrible CSS can pass CSSLint–just as it can pass the W3C validator. That’s no reason to avoid using it.

What the Web industry could learn from my Tower Records jobs

Minimum wage. A good chance you’d have to work until after midnight on New Year’s Eve, and then at 8:30 AM on New Year’s Day (happened to me). Boring, unglamorous duties. Dealing with clueless, irritating, or just plain drunk customers. So what was it about working at Tower that makes us former employees so nostalgic about it?

There’s a lively group on Facebook just for veterans of the San Francisco store at Bay and Columbus. The wall refreshes almost daily with someone’s anecdote, relevant link, or “whatever happened to…?” query. I don’t remember my stints working at Tower stores as nonstop fun, but I share these people’s eagerness to talk about it, decades after the experience. What was so magical, then?

  • People really shine when they’re allowed to specialize. Russ Solomon’s most impressive innovation with Tower Records was to stock a few copies of many titles, in many music genres, rather than stock a lot of copies of a few titles in only, say, rock ‘n’ roll. Customers came to believe that a recording didn’t exist if it wasn’t in stock at Tower. The huge inventories meant that Tower stores ballooned into multi-story, multi-department shrines to music retailing, staffed by people with deep knowledge of particular genres.

At the Tower store in Washington D.C. we had the king of the soul music department upstairs, a nebbishy white guy with years of data on singers, musicians, and producers committed to memory. Downstairs in Imports we had Neal, who pored over record company newsletters to sift out which nearly unobtainable European releases he could order for the store. Both of these guys had a number of fans among the customers, who would seek them out as kind of personal shoppers. Nobody ever suggested moving these guys to other departments, so they could get more acquainted with other kinds of music.

In the Web industry we’ve come to dismiss specialties for creating “silos.” We demand that people “cross-train,” “take responsibility for the full stack,” as if specializing creates some kind of weakness. But whose customers seek out the generalists on the team?

  • Money isn’t everything… Wages at Tower were lousy. You started at minimum wage, and obtained tiny raises at infrequent intervals. There wasn’t much room for negotiation: if you didn’t like the arrangement, tough–there was a waiting list of people eager to take your place. So what was the draw?

On the job at Tower D.C. Photo by Madeleine Morrissey.
At Tower we felt we could be ourselves. We could wear pretty much anything, style our hair any way, talk passionately about the music, books, or movies we really cared about–we didn’t have to pull back to fit in with someone’s idea of the workplace’s culture.

  • …But it is something. As grateful as we were to Tower for providing us such a cool, accepting workplace, none of us would’ve worked there “for equity.” For one thing, a lot of us were deep into other non-paying pursuits like playing in obscure bands or writing terrible poetry, and to pull our attention away from these tasks Russ Solomon et al. had to pay cash. For another, working at Tower involved–work. Employees were still required to do things we thought boring, stupid, uncool, and beneath our adolescent dignity. Compensation was a motivator.

  • Working part-time is okay. Many of us at Tower were still university students. May through August, hey, pile on the hours…and come September, not so much. Rather than deal with massive attrition every fall, Tower managers adjusted schedules to fit employees’ lives (not vice versa). There were sufficient full-time employees to staff the less desirable weekday shifts. Nobody was accused of lacking “passion” or “commitment” for requesting a part-time schedule, nor demoted when it was obtained.

  • Company culture must reflect the people currently working there. When first opened in 1967, the Tower San Francisco store at Columbus and Bay had groovy, Summer of Lovin’ employees who probably said things like “Deep!” and “Far out!” without irony. Twenty years later, it was staffed by edgy kids in leather and Mohawks who slapped a video of Woodstock in the store VCR to watch for laughs. Had Tower insisted on keeping its original flavor of tie-dyed mellow, it would’ve repelled prospective hires with fresher ideas about music.

It’s common in Web companies to whine of “growing pains,” which usually turn out to be resistance from earlier employees to requests for working space, documentation, and professionalism from newer ones. By this point, the company is radically different from what it was at its founding, so why retain that atmosphere?

  • Even companies that do these things can still fail… Tower dwindled into bankruptcy by 2006, undone by online music sales. It did scramble to build a Web presence, but there was little to deter customers from buying instead at Amazon or iTunes–after all, where was the personal touch of people like Neal?

  • …but this is no reason to avoid trying them out.

What bugs me about third-party recruiters

Here at last, the summer doldrums. I’m in between vacations–back from the U.K., planning to go to Arizona–and just completed a project. I need work! Yet I’ve turned off InMail on LinkedIn, haven’t tweeted about looking for a new gig, and don’t have my résumé or telephone number on my Web site. Why? Because I hate dealing with third-party recruiters.

Barce really hit a nerve with his post on the SF Ruby Meetup mailing list yesterday summarizing his recent job search experience. He’d uploaded his profile to Dice, Monster, and CareerBuilder, sites notorious for generating spam from bots or unscrupulous jerks posing as staffing professionals. As expected, he received a great deal of unwanted attention from desperate salespeople rather than authentic employers. On the mailing list, our responses to Barce’s amusing account have ranged from “+1” to pondering how to teach recruiters better pattern matching. Clearly, many of us consider recruiters, especially third-party ones, bothersome. Here are my reasons:

What bugs me about third -party recruiters

  • They don’t bother to find out anything about me before they pitch something.
    I have this Web site, my LinkedIn profile, my Meetup profiles, my Quora profile, my Twitter account, my GitHub account, and more about me quickly retrieved in a Google search. Like many tech professionals, I make it pretty easy to find out what I do for a living, how I do it, where I do it, how long I’ve done it, and who pays me to do it. So it doesn’t just bug me, but enrages me when some huckster cold calls about some completely inappropriate “opportunity.”

My response: 1) block that person’s telephone number from calling me again; and 2) block that person’s e-mail as spam. I don’t waste my time with a personal response anymore, since I’ve learned that only results in more annoying cold calls.

The ultimate in recruiting!
photo by johanohrling
  • They don’t represent projects I want to join.
    I’m a freelancer, so I’m only looking for contracts–that makes me disinterested in about 93% of the positions both legitimate and fake recruiters are seeking to fill. So stop sending me e-mails about “full time opportunities” already!

More profoundly, I admit to holding a bias against projects which can’t be staffed without third-party recruiting. I can understand how a startup or corporate unit would retain a recruiter to find and vet suitable candidates, but can’t fathom why a tech business worth joining can’t broadcast its need for developers through mailing lists, meetups, or Twitter.

One of the more irritating constants of third-party recruiter spam is a lengthy description of a job which doesn’t actually exist. Searching on some of the phrases in the “job description” usually results in an archived view of a months-old posting on Craigslist.

Not getting a response to your cold calls? Stop cutting and pasting. We know about that one.

  • And my biggest complaint: They do massive harm to the good recruiters.
    There are staffing professionals–emphasis on “professional”–out there who I would never block from calling or e-mailing me. I will always give them my attention. I might not be able to help them myself, but I will always try to think of someone who can. I’ve been meaning to write a blog post about annoying recruiter behaviors for ages, but hesitated when I recalled how well these good recruiters have treated me. I didn’t want them to think I was unmindful of that.

Mention recruiters on the typical developer forum, and you’ll get a round of caustic, negative, exasperated responses–and at least one person piping up with something to the effect of, “But So-and-so is a good recruiter!” This is the result of So-and-so working competently and ethically. So-and-so ingratiated him- or herself with the development community by participating in it, asked what job seekers were looking for–then listened–and didn’t antagonize employers by sending a blizzard of unsuitable resumes. So-and-so acted more like a talent agent than a shill.

Meanwhile, there’s this mass of clowns ruining it for everyone else. Company job postings end with the stern warning “NO RECRUITERS!” and job seekers refuse to deal with recruiters, bad or good.

My proposal: let’s keep this unregulated term “recruiter.” But let’s apply it only to the sleazy spammers. For the rest, anyone acting like a professional, someone who does the more difficult job of caring? Some other term–matchmaker. Agent. Mensch.

Why You Can’t Hire a Front-end Developer

So much for that depressing unemployment rate, all those people supposedly looking for work–you might be muttering–why is it I can’t get someone to do that HTML/CSS/JavaScript project?

Why You Can’t Hire a Front-end Developer

  1. You want only full-time, salaried employees. I admit my bias as a freelancer on this one, and, frankly, I’m mystified why restricting your development team to only full-timers exerts such an attraction, especially for mid- to senior level roles. Why not use freelancers, part-time employees, job sharing teams, or a combination of all these? I welcome your discussion in the comments.
  2. Your requirements are out of whack. To be fair, I think this isn’t as pronounced a problem as it was a few years ago; maybe it’s the growing acceptance of MVC frameworks which has made it obvious just what a front-end dev does.

    But if you’re requiring someone “expert” in the full Web stack, interaction design, logo creation, QA, server administration, social media, copywriting, etc., then be prepared to talk to a lot of candidates who are either lying about their credentials, or with uselessly shallow capabilities in these vastly different skills.

  3. You’re only considering young, white guys to be suitable candidates. In the United States, it’s illegal to discriminate in hiring for these qualities, but hiring entities evade the law by masking their narrow preferences in phrases like “recent grad” and “good cultural fit.

    I admit confusion on why a recent grad is so desirable as a front-end developer, since university curricula are rarely as up-to-date as the knowledge an experienced Web dev would acquire from real-life projects; again, I welcome your explanations in the comments.

  4. It’s too obvious you’re a slave driver. The organizer at one of the tech Meetups here in the Bay Area takes a moment at the start of every meeting to read job postings employers send to him, hoping to interest the attendees in applying. One evening he read a post requesting a developer who would commit to working “60-70 hours a week.”

    We sat quietly for a moment. Then one attendee remarked,”Raise your hands if you’re interested in working ’60-70 hours a week’!”

    All of us laughed. Nobody raised hands. And, I suspect, nobody answered this job posting. That employer lost out on a room full of fifty or more potential hires.

    Not persuaded? Here’s something to consider: there’s a reason why a book titled The Four-Hour Workweek was a bestseller, and one titled The Sixty-Hour Workweek was not.

  5. You’re trying to cram a tech team into an entirely different kind of organization. A telling symptom of this kind of cultural disconnect is a policy requiring all employees, even tech workers, to use the same operating system, e-mail client, Web browser, and so on. A related problem is trying to graft a front-end specialty onto what had flourished, or at least endured, as a server-side team. The results in both cases include confusing job requirements, unsatisfying interview questions, irrelevant performance criteria, and low interest in your project from experienced front-end developers.
  6. You and your people don’t seem to get out much. Are you physically present at any local tech gatherings? Anybody on your team a participant in a Meetup, a BarCamp, a *DevHouse? Anyone there have an active GitHub account?

    When I don’t see much evidence of these extracurricular activities, I assume your team is exhausted from working too much. Who wants to join that?

  7. Your benefits aren’t, well, all that beneficial. If you really want to hire extra-special people, go beyond the clichés of foosball tables and Friday keg parties.Do you offer matching 401(k) funds? Cover your employees’ health insurance premiums? What kinds of paid leave do you offer both parents and the childfree?

    At the very least, re-examine your paid vacation leave policy. If it’s the dismal U.S. standard of “two weeks” (really just ten working days) a year, it’s not enticing anyone who has a choice of workplaces.

  8. You’re requiring onsite work, but your office environment is terrible. I remember my interview at a big, then-prestigious Web company a few years back. I don’t remember any of the interview questions, nor even my interviewers; all I remember about this company are the dispiriting rows of beige cubicles, the glaring fluorescent lighting, the looming, low drop ceiling, the smell of the microwaved burritos employees were eating at their desks, the complete absence of natural light and airflow, and my recurring thought: Man, oh man, I can’t wait to get out of this place.

    If memory serves, I think I actually ended the interview early–there was no way I was going to be interested in working for this company. Rule of thumb: if you’re requiring people to work in what looks like a set for The Office or a Dilbert cartoon, please call in a design consultant for a revision.

How did you hire a front-end developer?

Where is San Francisco?

The mailing list for a local tech Meetup sometimes includes posts from recruiters. Here’s a typical one, received this Monday:

Subject: Looking for a rockstar Ruby Developer in Brisbane
Message: Our client is looking for a ROR developer for a contract opportunity in San Francisco for shopping cart features.

Well, following that was the customary dogpile about the word “rockstar.” Tuesday’s digest was full of amusing responses, and it was almost worth getting such a carelessly worded near-spam to generate that discussion. But something else really bothered me about this recruiter’s post–and, well, about a whole bunch of tech recruiters’ posts:

Where is San Francisco?

Here’s where I think San Francisco, California is:

San Francisco

And here’s where I think Brisbane, California is:

Brisbane by way of Oakland

I have to get directions to Brisbane since I don’t go there much–notice how heinous it is to get there from Oakland on transit? Google suggests I take three trains and one taxi to arrive on a weekday by 9AM. Like, as if.

A lot of recruiters seem afflicted by the ignorance of geography demonstrated in the quote above. A few years back one assured me that I had an interview at the “San Francisco office” for her client–and then directed me to downtown Mountain View. Whoa, whoa–not so fast!

Mountain View is not San Francisco. Nor is Palo Alto. Nor are Sans Bruno, Mateo, Carlos, José. Not even South San Francisco is San Francisco. And Brisbane sure as heck isn’t San Francisco.

Like resorting to the “rockstar/guru/ninja/pirate/cowboy” clichés in a job posting, assuring candidates that the job site is in “San Francisco” when it really isn’t only makes a recruiter look incompetent and/or untrustworthy. Please re-read that last sentence. Got it? Good. Don’t make me post about this again.

Here’s a quick tip on how to assess whether a job site is in the real San Francisco or in recruiters’ “San Francisco”: if there is a landline for your client’s job site, what is the area code?

The area code for the city of San Francisco, as well as for Marin County, is 415.

Yes, there is a danger of Sausalito or San Rafael masquerading as “San Francisco,” but tech hasn’t been exactly a white-hot industry up there, so the volume of misdirected cold-calls and near-spam is tolerably low. If the area code formula above isn’t something you can memorize, I’ve prepared this table you can print out and carry with you:

Is this job really located in San Francisco?
Area code for the job site’s landline Is in San Francisco
650 NO
408 NO
707 NO
510 NO
925 NO
916 NO

What’s the furthest “San Francisco” from San Francisco you’ve seen in a job posting?

What not to buy in 2011

This is the time of year when the Interwebs are flooded with “what to buy…” consumer guides. In contrast, the things I discuss below are much cheaper, saving you both time and money, because in the end you won’t be shopping for them at all.

(An aside to Web services freelancers: you know, if we stop offering these things, people will stop thinking they can obtain them. Give it a thought.)

What not to buy in 2011

  • Support for IE 6. Freelancers–put a clause in your contracts that requires a $10,000 deposit before you even start up IETester or the like.
  • Meetings requiring developer attendance.
    "Sunday," © Peter Paul Jacques
    Described variously as “toxic,” “a disaster,” and “the biggest productivity killers for programmers,” meetings are relics from the twentieth century which have as much relevance to your technology projects as do carbon paper and stenography.
  • The cost of a stern “butts-in-chairs” policy. Savvy, experienced developers know what conditions make them productive, and these are various. Nobody lists compulsory enclosure in a cube farm among those conditions.
  • Huge office spaces. Since you’re not having meetings, and you’re letting your team co-work or telecommute, you don’t need all that much space anymore.
  • Fake work.
    Fake Work: Why People Are Working Harder than Ever but Accomplishing Less, and How to Fix the Problem

    This should be obvious, but somebody had to write a whole book about it to expose the problem.

  • Expensive conference fees. As Rebecca Murphey noted, the most useful conferences for Web technology seem to be ones organized by and for practitioners, who aren’t always bankrolled by deep-pocketed corporations.
  • Tag soup, nouvelle cuisine style. Regrettably, HTML5 provides just as many opportunities for lousy markup (“<div>-itis,” overuse of class and ID attributes) to the novice and/or the unconcerned, as  did earlier HTML standards.

What’s dropped off your 2011 shopping list?

A Timeline for Treating Burnout

You’ve reached a state of burnout when:

  • you can’t socialize after work, or on weekends, because the only thing you’re prepared to do in your state of numbness is to get drunk alone;
  • you hear about layoffs at your workplace…and are bitterly disappointed you weren’t among the people let go;
  • you’re riding your bicycle to work, all the while wishing a car would hit you, because then you wouldn’t have to go to work that day.

A Timeline for Treating Burnout

0-3 months:

  • Don’t feel ashamed.

    Burnout is common in the tech industry, yet still regarded as some kind of shameful personal weakness rather than a normal human response to irrational working conditions.

    Fortunately, some courageous people are starting to discuss burnout openly.

  • Say “no.”

    Stop “learning to say no.” Just do it. Do NOT say “maybe.” People think “maybe” means “yes,” especially when women say it.

  • Stop volunteering for now.

    Yes, there are worthy causes all over relying on volunteer efforts. But when you are in burnout, you are in crisis mode. You might have arrived here by giving away your time and expertise. While it’s certainly flattering to be told a project will fail without your unique, uncompensated work on it, remember that anything depending on a single person is unsustainable.

4-6 months:

  • Step away from the screens.

    I know I’ll sound like a crank, but I really do believe there’s something physiologically harmful about lengthy exposure to computer monitors, and we burn out more readily when working with them. It’s been established that light shining in our faces affects our circadian rhythms, which is probably why, after hours, days, weeks, of this treatment, you feel as jumbled as you would from the jetlag of a nonstop flight from LAX to Heathrow.

    Get away from the TV, the laptop, the iPad, and so on to reset your clock.

  • Get your house in order.

    I’m not using a metaphor–I mean your actual, physical dwelling place. A dirty, cluttered living environment is both a symptom of burnout (you’re too weary to wash the dishes or hang up your clothing) and a contributor to it (your place isn’t relaxing or pleasant to be in). Counter your packrat or slovenly tendencies with some re-education and a fresh, wetted sponge.

7-9 months:

  • Simplify, simplify.

    When a painter reaches an unsatisfying point in her work, she might recharge her enthusiasm by painting with a reduced palette. Removing the burden of choice frees you from yet one more thing to do–and exposes how many of the options posed to us make no difference in how our days proceed. Stop dithering over things which don’t really matter.

    You don’t have paint en grisaille, but you must set yourself more confining limits than usual to realize the benefits of this practice. Type “voluntary simplicity” or “minimalist living” into a Web search engine to receive much more information than you really need to start living with less.

  • Risk being called “unsupportive.”

    Many of us, especially women, reached our limits by taking on the burdens of others. We’ve been the caretakers and companions of people who dumped on us…because we let them. For some reason we fear being called “unsupportive” for not concerning ourselves with these people’s endless problems. I’m not talking about being unsympathetic to genuine tragedy, but rather about defending yourself from these vampires.

    You know how the flight attendants on commercial flights instruct parents to put on their own oxygen masks before attending to their children’s?

    Consider your recovery from burnout just like this scenario–you’re of no help to anyone else until you have your own air supply secured.

10-12 months:

  • Take on one well-defined project.

    By “well-defined,” I mean a project with a start date, a definite list of tasks, and (this is important) an end date. Just as you recover from a physical injury by assuming only gradually heavier duties, you recover from burnout by taking on shorter projects with less complexity, then gradually moving into either longer or more complex projects–so long as you still feel enthusiastic about the work.

    Do not join a vaguely defined project. What you need at this stage in your recovery from burnout is reassurance that, however stressful a particular moment can be, that moment passes. Open-ended projects can persuade us that nothing changes, time has stopped, this reality is the only one, and the stressful moments are endless–sending us right back into burnout.

  • Schedule a regular digital sabbatical.

    Get away from the Web, IM, e-mail, RSS, blog, podcasts–all of them. To update Timothy Leary’s slogan, turn off, tune out, and drop in. If you’re so addicted to constant electronic distractions you can’t envision an entire weekend without them, then begin with shorter absences–thirty minutes, an hour, two hours or even twelve.

How have you recovered from burnout?

So long, Vox.com

We were so proud. It was through such a vale of tears that we, the engineering group at Six Apart, traveled to get to that wonderful point at which Vox.com, the world’s niftiest hosted blogging service (prove to me it wasn’t), went live.

All those hours of mandatory overtime. All those foosball games and trips to the office coffeemaker. All that back-and-forth between the Perl dudes, the JavaScript kids, the CSS ladies, and the visual design goddesses. All those fake blog posts made on the testing server (weary of typing “lorem ipsum,” I resorted to scraping content from Hungarian Wikipedia pages, which provided nice long strings to test word-wrap in layouts). All, it seems now, for naught.

Vox.com will go offline on Sept. 30, 2010. It had been withering for years; I know my posts to my own Vox blog dropped off in frequency around 2008. When I did post, most of the comments I received were obvious spam, not filtered by the server (of all the great ideas we put into this product, why not something like Akismet?) What’s left of Vox now seems like one of those grotesque, abandoned amusement parks you’ll see in dystopian sci-fi movies: a brightly colored playground that somehow feels menacing. Are those zombies hiding behind the Ferris wheel?

Vox-er Patty Mitchell captures how this apparently necessary closing is more than releasing a domain name:

The loss is one of community and connection. That was the magic of Vox. The way this platform used to make it so easy to post with different privacy levels and to share our lives as we chose with friends, families and even…gasp!…strangers. The magic was in how trust was built and how sometimes those “strangers” became our real friends over the course of time and circumstances.

Why this? How could such an easy-to-use, attractive, AJAX-charged product not contend successfully with old-style clunkers like Blogspot and WordPress?

Chris Balz, one of Vox’s JavaScript maestros, has this insight:

Vox finds its home with the NPR set and similar demographics. Yet with a shrinking middle class, the audience for these types of ventures is smaller and not as spendy. So “social” went almost wholly to brief “status” messages and not to Vox’s social blogging.

In both Patty’s and Chris’s remarks are hints of what I think the real problem for Vox was. That problem was the rapid expansion of Facebook’s popularity outside its original niche user population of affluent college students. When we were building Vox, the refrain seemed to be, “let’s build a blogging service for grown-ups.” And–I don’t just believe, I know–we succeeded. For a time. For a rather short time…until the Baby Boomers, the Gen Xers, the parents of Millennials all turned to Facebook, despite that service’s apparent disdain for such uncool olds.

I remember two phone conversations I had in August 2005. One was with an engineering manager desperate to hire a front-end dev. The product was unfamiliar but intriguing to me, and I already knew one of the engineers. Everything sounded great except the commute–it would’ve taken me two or even three hours’ travel each way. Sorry, no dice. So I was more enthusiastic about my second phone call, to a recruiter for a blogging software company. I wouldn’t know anybody there, and the product was not fully defined, but the commute was reasonable. I took that project.

Yes, the first conversation was with Facebook, and my second, with Six Apart, about Vox. I’ve asked myself, “What if…?” ever since.

Productivity System Smackdown: FlyLady vs. GTD

Many of us, it seems, meet day’s end with disappointment, not satisfaction. We started ambitiously, worked steadily–at something. But what is there to show for that? A barely diminished to-do list, and a burden for tomorrow.

I confess that my favorite way to procrastinate is to read productivity blogs. It’s by way of this habit (bad or good? Let me know) that I’ve learned about the following productivity systems. Readers familiar with both might be astonished that I’m comparing these, since they’re oriented towards such different audiences and spheres of activity–but having used and experienced both, I think they’re ultimately about the same subject, which is reaching that thrilling moment when your to-do list is blank.


GTD

Contender #1: Getting Things Done, a.k.a. GTD

Who:
David Allen
How:
the book (Getting Things Done ), the seminars, the applications, the fans.
What:
GTD© is the productivity system outlined by David Allen in his 2001 bestseller. Allen proposes that a profound gain in one’s productivity follows from writing things down, rather than keeping them in one’s memory. Much of GTD centers on organizing that written data into recognizable prompts for action.
Ritual object:
Many items hold great importance in the GTD system, such as daily calendars, notebooks, and PDAs, but when I read GTD, nothing seemed more crucial for the system’s implementation than the File Folder.
Pros:
  • As you can see from the options above, there are many sources of information about this system. Any practitioner seems ready to pounce on your least little question about how to use the system.
  • Held in great esteem in the US corporate workplace. Casually mentioning your reliance on GTD practices in a job interview will probably score you points.
  • Several of the principles are quick to implement and easy to remember (I expect Allen would prefer we make notes about them down instead).
Cons:
  • Though Allen does include non-workplace examples, his is not a system to apply in all situations. I can’t imagine how blue-collar or domestic workers would use some of the GTD principles.
  • Generates more physical artifacts than I find comfortable. For instance, Allen suggests making file folders to organize even unique documents. Having joyously reduced my own files to just one letter-size box, I’m reluctant to add to their bulk again.
  • Has no apparent built-in protections against tipping into obsession. Taken to its limits, GTD could easily absorb all that time one used to spend in leisure or paying work.

FlyLady

Contender #2: FlyLady

Who:
Marla Cilley, the “FlyLady” (the moniker comes from her love of fly fishing)
How:
the Website, the online discussions, the publications, the occasional workshops
What:
The FlyLady’s system treats domestic concerns almost exclusively. Practitioners receive daily emails from the FlyLady reminding them to undertake various household chores in small (5- or 15-minute) chunks of time. The emails include testimonials from grateful participants, and homespun pep talks from the FlyLady.
Ritual Object:
The Shiny Sink, maintained nightly by faithful practitioners, though the Timer, the Calendar, and the Control Journal assume almost as much importance
Pros:
  • Very easy to implement and follow. Much of the system establishes routines. One can begin them at any time.
  • Corny as they are, the FlyLady’s pep talks do address self-defeating behaviors such as perfectionism and procrastinating.
  • Many of the FlyLady principles can apply to other than domestic work.
Cons:
  • The very feminine and very folksy tone of FlyLady messaging is likely to irritate most men and not a few women
  • Nearly all FlyLady emails will contain exhortations to buy one or more of the housecleaning tools for sale through the FlyLady Website
  • Since it is a system used by one of the most despised, “uncool” sectors of the population (middle-aged, middle-class, nonurban women), you probably won’t garner job interview points for mentioning it.

The Winner

The FlyLady.

Yes, really. Why? Because her system is simpler, doesn’t leave a lot of stuff behind (among her frequent themes is reducing clutter), and really addresses why we don’t Get Things Done: it’s because 1) we think we have to do them perfectly; and 2) we think they will take more time to accomplish than they really will. Though Allen does have the rule about working immediately on any task which will take fewer than two minutes, FlyLady combats procrastination by not even requiring one to assess which tasks those are.

As other systems are discovering, one’s best tool for productivity is a timer. Set the timer for an easy-to-accommodate sliver of your day, and work on one task, whether it’s decluttering your sock drawer, making cold calls, or even writing blog posts. The timer rings; you stop–and there’s one less thing to do.

How to demoralize your front-end developers

Stop failing at this apparently necessary chore; I’m here to help.  I can verify that all the following techniques have worked on for me.

How to Demoralize Your Front-end Developers

  1. Constantly change requirements. It’s, what, the day before the scheduled launch?  And the product doesn’t include that absolutely requisite feature you didn’t think to require until now?  Well, shoot, just demand it!  And make drastic changes to the visual and interaction design as well–where’s the glory in completion?
  2. Constantly change the visual design. You took that one-day course in CSS and remember only that it was a way you could change all of a site’s visual elements from one file.  Okay, then, let’s start by making all the blue things red, and all the red things green–but only on Tuesday–wait, change them back again, make the old red things red again–and oh, all the gray things white and the white things gray, and the grayish-white things brown, on alternate weekdays.  And all the wide things “smaller” and the narrow things “a little bigger” and the tall things “a smidge shorter” and… just marvel  how enthusiastic your front-end dev grows.
  3. Give them a lousy setup. Cram your developers into a spot at an unergonomic table in between the gal who has the obnoxious sound themes enabled on her workstation and the guy who spends his entire work day shouting into a speaker phone. Don’t let your devs use their preferred operating systems or software–point out that you’ve generously provided work computers exactly like your own, with that reliable ten-year-old OS and the proprietary groupware that cost you a bundle.
  4. Decide midway that you need pixel-perfection in IE 6 after all. So you visited your hermit, anti-consumerist brother-in-law living in a shanty with a hand-me-down Gateway 2000 accessing the Web over intermittent dial-up, and you looked like a putz because your beta site didn’t render perfectly in Internet Explorer 6.  Well, crack the whip so he can enjoy those rounded corners, PNGs with alpha transparency, and painstakingly mitered grid layouts.
  5. Critique the browser rendering against one in a different medium. Different media, you say?  Hardware?  Pshaw!  Do as I’ve actually witnessed:  hold a paper print-out of the intended design up to the monitor, and compare the rendered page unfavorably to the PDF print-out.  Remark on the differences in proportion and color.  Watch your devs writhe in either agony or amusement at your request to make the two formats identical.
  6. Assign visual design tasks to your developers. Get rid of that pesky professional, and go with a leaner team equipped with mere adequacy in Web design.  Start with vague instructions to your front-end devs (“This area of the page needs to really say ‘breathy,’ but not ‘vaporous'”), and end with your looming over them, jabbing at the display of a competitor’s site on a monitor, and shouting, “See? See?!  Like this–only different!”
  7. Pit your developers against each other. Break up that predictable day with a bout of office politics as bloody as any combat in the Colosseum!  Let one developer bully another, favor the least productive developer over the others, and disclose important project details only to the dev most likely to hoard the information.  When one dev leaves at 6pm to tend to the rest of his life, assign all his duties to the other one still in the office. Whatever you do, don’t let these people end up liking each other.
  8. Constantly interrupt with phone calls, e-mails, IMs, or in-person meetings. You know, if you give your developers the chance to concentrate, to get into the flow of working, there’s no end of disaster which could happen:  they might  finish the tasks you’ve assigned to them, or write bug-free scripts, or finish a work day with a sense of accomplishment.  Then you’d all miss an important feature of the Development Drama:  the climactic battle in which each side slays the other in murderous frenzy.
  9. Ridicule their professional opinions. Don’t listen to the nay-sayers when you describe that pop-up with autoplay Flash, animated GIFs, and blinking text you’re confident will add loads of appeal to the application.  Show them your teenaged son’s MySpace page and pointedly ask why they can’t make something like that if he can.
  10. Don’t use a bug tracking system. Sheesh, you already send all those e-mails.  Why repeat yourself in some persnickety little data entry form with those dropdown things which force you to prioritize the issue?  Just repeat: everything’s critical and of highest priority.  See, easy to remember.

Hmmm, something’s missing.  What have I left out?