Posts Tagged ‘work’

Here we go again

Shells, 2010. Charcoal on paper.

In the current issue of The New York Review of Books is “To Monday,” by W.S. Merwin:

Once you arrive it is plain
that you do not remember
the last time

you are always
like that
insisting upon
beginning
upon it all beginning
over again
as though nothing had really happened
as though beginning
went on and on…

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?

Why You Can’t Hire a Front-end Developer

Posted on: by mejarc 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?