Posts Tagged ‘career’

Ada Lovelace Day (#ALD14): Garann Means

Was it on css-discuss? A List Apart? I’m not really sure; that seems so long ago. I remember, though, being impressed by these detailed, well-written discussions of various aspects of front-end web development. The author was Garann Means.

She kept a useful blog that I relied on, and I always looked forward to the slide decks she posted from her conference talks. She wrote a practical book, Node for Front-End Developers. And, then, around 2010-2012, Garann Means really found her stride, and what she wrote and posted was more relevant to me than how to create ellipsis dots in CSS.

Her subject became women working in technology. She examined how women enter the field, how we struggle to remain in it, how we could improve it. And, to my regret, this summer she discussed how we leave it.

I read that post on a foggy Bay Area morning, and couldn’t stop thinking about it for the next couple of weeks. I’m also at that mid-career point where many women drop out of the tech industry. What happens when someone as accomplished as Garann Means “leaves” the tech industry?

(I’m keeping the verb in quotation marks until I find this out: did she jump, or was she pushed?)

It’s time to stop asking, “Why?” Somebody must benefit when Garann Means and other women leave tech–why else would such horrendous attrition rates be tolerated?

I think the task now is to inform women at the beginning of tech industry careers that we have only a decade or so to work them. We are like football players or fashion models: we have tiny windows–more like pet doors–of opportunity. We should be planning our inevitable exits all along, saving up our money for that dread day when nobody will hire us, nobody will promote us, or…we just flat-out can’t take the bullshit anymore.

What I’m reading into Garann Means’s account is that she left her tech career on a high note. I really hope that is the case. She and I have never met; now I’m not sure how our paths would cross. Were we to meet, I’d thank her again for her freely given advice, guidance, and opinions. Start to finish, hers is an example I will always find inspiring.

Discussing the men in tech problem

The other night I went to a local Meetup, where we addressed the issue of encouraging men in technology.

Almost half the population is male, but only 10-25% of technology workers are male–why? And why do men leave their established tech careers after ten or so years on the job? I sat down to listen to a panel of experts discuss this important topic.

All four represented well-known startups in San Francisco. One was a VP of Engineering, another a tech lead. Of the two men on the panel, one was a manager sort (Project? Product? I don’t exactly remember), another held the title of “People Person!”, which I guess is some kind of recruiting/HR amalgam. The Engineering VP, Sheila, started things off.

“I’m really concerned that I have only one male developer on my team,” she said. “I know we’d really benefit if Robert weren’t the only man.”

“His name’s Matt,” interjected Tom, the “People Person!” for the same company.

“Oh, my bad,” laughed Sheila. “Yeah, Robert was the other one.”

Next was Lisa, the tech lead for a developer team of ten. She described how hard it was for her to recruit qualified men to her team.

“I’m trying everything, boys. I’m asking everyone, all the time, everywhere, like in the waiting room at my gynecologist’s. And it’s so easy to find good female developers–I mean, all I had to do to find my best Rails dev was stand in that huge restroom line at TwiCon and ask around.”

Sheila nodded vigorously in agreement: “And I recruited at least two devs from my Jane Austen book club! Jeez, guys, it’s not like we have a sign that says ‘No boys allowed.'”

Tom seemed rather curt as he interrupted.

“Have you never thought this ‘cultural fit’ stuff was filtering out men?” he asked.

“Well, cultural fit with the team is essential. We need developers who feel comfortable with each other. I’m not willing to break that up to fill some quota,” responded Sheila. Light applause from the audience.

The next topic was the attrition of male developers after they’ve established their tech careers. Jonathan the manager guy offered his own story for discussion.

“I was a pretty good Python dev for a few years. I worked wherever they sent me, whenever. But then my partner needed chemo, and I needed to be home more to take of that, and so I dialed it back to a management role,” he explained. He sounded rather wistful to me.

“We worked with Jonathan on this,” responded Lisa. “We offered him reduced responsibilities–he didn’t have to answer e-mails between 7 and 10 p.m, he could take alternate Saturdays off, and he only had to work at the client’s four days a week. For some reason, that wasn’t enough. So instead, we promoted him to manage the development team!” She seemed very proud.

“Now see, boys,” Sheila followed. “We’ll meet you halfway–you just have to lean in and do your part to meet us.” Sustained applause.

Questions from the audience. A scowling man stood up.

“I’m beyond ‘a pretty good Python dev,’ but I can’t get a job,” he mourned. He sounded so frustrated I thought he’d cry right there. He continued:

“I have the degree. I have the portfolio. I have the conference talks. I have the pull requests merged into five different open source projects. But I can’t get past the phone screen. What the hell else do you people want for evidence?!”

“Try six pull requests,” Lisa quipped.

“And try smiling,” Sheila added. The man sat down, still looking dejected.

The discussion over, we sauntered out to an after-hours knitting circle. Men in tech–can they really do what it takes to be here? Should we care?

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?

Sh*t People Say to Front-end Developers

Posted on: 4 Comments
  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.

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

Posted on: 1 Comment

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?

Posted on: 1 Comment

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?

A Timeline for Treating Burnout

Posted on: 6 Comments

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.

Photo © americusian

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?

My First Web Page

Posted on: 4 Comments

Some digging in a dusty file box the other day yielded no fewer than three floppy disks. What wisdom might these ancient tablets convey? Fortunately, there was at least one device in the house which still had a floppy drive. Result: mostly disappointment. The files were either first drafts of things I’d sent off to magazine editors in the late 1990s, or grouchy letters to my landlords of the same era. However, there was, archived with apparent pride, my first effort as a Web developer.

Step into the WABAC Machine. The year is 1997. I was the admin assistant for a team of software engineers. I was also something of a mascot; if the guys (yup, all guys, except for me) had a noncritical technical task they thought I could handle with a little instruction, they threw it to me, because I guess I looked really grateful to be doing something besides ordering lunch and taking the abusive phone calls of the company CEO. The most enduring instructions they gave me was how to use FTP, IrfanView, and NotePad to develop the team Web site. Of course, these tools seemed insufficient once I made a few changes–I wanted colors! Silly typefaces! Dizzying background images! And HTML seemed so hard to learn…

I remember downloading a lot of trial versions of the trendy WYSIWYG software of the time: an early version of Frontpage (which had me puzzling over these things called “stylesheets”), Adobe PageMill, and the editor which came with Netscape Gold. The one I used the most seemed to be NetObjects Fusion, which I notice is still available. It was a big, handholding, friendly giant of a program; it set everything into tables and FONT tags, and we were buddies. I felt masterful.

Nobody I worked with was a Web professional–no designers, no information architects, no UI devs. Creating Killer Web Sites had only just been published, Web Pages That Suck was treated mostly as a humorous diversion, and even Jakob Nielsen was as yet rather obscure to the average person making a Web page. It was in this Wild West environment that I devised this:
My First Web Page

I’ll enhance that retro atmosphere with a sample of its markup:

<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (WinNT; I) [Netscape]">
   <META HTTP-EQUIV="Page-Enter" CONTENT="revealTrans(Duration=1,Transition=6)">
   <TITLE>ES Home Page</TITLE>
</HEAD>
<BODY BACKGROUND="amoeba.jpg">
<CENTER>
<H1>
<FONT FACE="Wide Latin"><FONT SIZE=+4>Engineering Services</FONT></FONT></H1></CENTER>
<CENTER><IMG SRC="grey_dots.gif" ALT="grey_dots.gif (6699 bytes)" HEIGHT=47 WIDTH=890></CENTER>
<CENTER><FONT FACE="HELVETICA"> </FONT></CENTER>
<UL>
<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">ES
Quote Status</A></FONT></FONT></LI>
<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">Current
ES Status Report</A></FONT></FONT></LI>

Yeah, go on. Snort, carp, whatever. But this is how we did things then, back when browsers “innovated” with crap like BLINK and MARQUEE. A year later I was back to using text editors–haven’t touched a WYSIWYG since. Just a year later I was using CSS and disdaining FONT, and a year after that I was riding the dot-com boom as it crested. So it’s worth examining your old work product, if only to swell with pride over how far you’ve come since then.

What was your first Web page like?