Archive for the ‘work’ Category

Wherein I attempt to get what little readership I have to fall into a deep sleep.

Nicks-iMac:~ nick$ history 1000 | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
112 cd
53 svn
50 mate
40 sudo
35 ls
25 pwd
22 ./mysqladmin
17 port
14 ./mysql
13 curl 

Ah, now isn’t that better? Sleeeep. Sleeeeeeeep. I’m sure there’s at least one hard core Unix person out there saying “what the fuck does ‘mate’ do, and where’s all the entries for ‘vi’?” I will further separate the sleepy from the hardcore by announcing this is a Mac.

I change directories a lot, huh?

I’ve been doing some work recently, trying to re-invent the index page of a really large project that I’ve been attached to for almost a year now. It’s a homepage for a community portal site that is produced by an “old media” company, a newspaper specifically. As I’ve submitted countless designs for every imaginable user interface element and page layout, I was reluctant to start again; our company in internally famous for epic and glacial “feedback loops”, and I was in no hurry to find myself defending every last inch of my work to people who may or may not have any idea why it’s important—given their somewhat ironic position of web people trapped inside a newspaper.

After a recent submission, I received a well worded and polite response. It essentially said that we were very close to having a finished candidate, but some tweaks to color would be necessary to move on. I’m fine with this, at least publicly. Internally, however, it makes me want to scream. Even though the writer is a seasoned veteran of the newspaper industry with an above average grasp of the internet as a communications medium, it still makes me cringe. As a company we’ve been tasked with growing virtually every metric we have to measure ourselves by an abstract percentage. That number is in turn based on something only a newspaper would have the sense of humor to map its success against: the penetration and market size of the average locally owned TV station—the other dying medium, besides making records to sell. Management hasn’t been given any terribly clear direction about how this might be accomplished, but many of them seem to think more display ads will do the trick. This is what I hear approximately half the time: grow business, design with ad space in mind, make it conservative. The other half of the time I hear make it ‘web 2.0’, we need ajax, we want comments and tags on everything.

Someone is lying, or wrong, or both.

So when I get feedback on a design whose brief was “bleeding edge, ajax, show-and-hide” that says “these colors are too bright” I feel as though I’ve landed on the ape planet, and there’s a giant Photoshop toolbar jutting out of the surf at right angles. But I’ve realized now that it’s just because we’re trying to do two things at once. We somehow need to keep the average 54 year old female reader—who revolts and calls us on the phone when we move the sudoku puzzle—and convince the 18 year old that we are just as cool as Digg. I’m growing increasingly dubious as to whether this can be done.

I think these dual goals are fairly common in businesses like newspapers, where it’s increasingly obvious that current technology has rendered the stuff we were once good at pointless; there’s a feeling of wanting to hold on firmly to the vine in hand while you look for the next one, even though everyone is telling you it won’t hold you and your baggage. Another example is the frenzy to extend support for IE 6. The fear of making customers unhappy by not supporting their nine year old software—or losing them altogether without more to replace them—is palpable. This fear pushes companies into announcing, with all seriousness, an intention to post positive growth simultaneously along every measurement it has for itself. It makes them spend time and effort figuring out custom newspapers that only cover your specific eighteen block neighborhood. It makes them hate Craig Newmark. It makes them announce they are competing with Google.

When we set out to redesign this site almost a year ago our team did everything it possibly could to distance ourselves from newspapers. We chose a software back-end that, up until that time, had been largely untested for that specific purpose; we designed with wild, complimentary colors and urbane type faces; we envisioned a site where almost everything was user-centric, where you never saw anything that you didn’t ask for. In the process that ensued, whittling away became incising. What is left bears enough resemblance to be recognizable to us, but I’m not sure it’s what we promised our users. We’re a different group now, and even though current events keep some of us trapped in meetings for hours at a time there are still good ideas circulating here. Newspapers want you to believe that being successful in 2008 would require them to see into the future. This is a lie. It would merely require them to see into last week. The pieces are all here, and there are thousands of people who want to do the work. It’s just that for every one of them there’s a counterpart, working hard to make sure we keep serving two masters.

I don’t know, maybe he just hates green. (And he really is a nice guy. Shame about the green, though.)

An inescapable fact of life in web development and product design is meetings. Frankly when I was first freelancing I thought the notion of the hours long info share was sort of a myth; as I began to work in teams later I realized they were not mythical, but rather nightmarish. Often, meetings would drag on for hours or even consume entire workdays. It seemed that no one was able to hold focus for much longer than an hour, but the meetings would continue anyway. In fact, these marathons stretched the meaning of the term meetings and veered dangerously toward seminars. Most of them had no real agendas, and almost everyone in the meeting was seeing new information for the first time.

I found myself yesterday in a planning session with a large group of people. We were asked to, among other things, talk a little bit about the stuff we’re asked to do too often in our office lives. Unsurprisingly almost every group mentioned meetings. So the object of this post is to share some ideas for making meetings—something I stress really are important in development—something more useful than they may be for you right now.

I. Meeting types
Meetings are not one-size-fits-all. In so many offices, meetings are held because it “seems like the right thing to do”; you want to build consensus for a project, or take the pulse of several team members about their status while on a project and a meeting with everyone involved seems like the best way. Instead, consider a ten minute standup meeting—all parties standing and looking directly at the features, code or colors in question. Another type of meeting that happens constantly is a document review, where a team might get together to go over a timeline or other shared document. The kiss of death in these meetings is twofold: letting them run over about half an hour, and not giving all attendees an opportunity to see the document beforehand. I can’t think of anything more frustrating than watching someone edit a spreadsheet on an overhead projector that I have either never seen before, or that I only occupy a couple of rows in.

In short, keep meeting relevant and short. When only three people need to talk, three people should talk. Avoid concepts and words, and seek concrete actions that you can dole out to everyone at the table. It may seem childish, obvious, or elementary at first to hear yourself saying, “Bob, crank this widget”—but when everyone leaves the room feeling like they have something real to do, they feel much better.

II. Handouts
In our office we’ve gotten as far as doing meeting agendas, and they really help. Agendas at least make participants feel like there’s a map out of the madness, and if all else fails it’s something you can point to to get back on track. One thing we don’t do is a pre-meeting info share of some kind. The pre-meet can be a short email sent to everyone invited that says:

“Hi all-

We’ll be meeting about Project X Wednesday @ 11am. The agenda is attached to this email. At this meeting the project planner, Bob, will expect the following from the team:

• Sue: Wireframes uploaded to Basecamp
• Erik: An answer from Google about the foo API
• Matt: Status update on the data import scripts from WordPress to Joomla

This gives you guys two more full days to bash these things out. You can expect another task from the list at the end of the meeting.

See you then!

-Bob”

The pre-meet puts everyone on the same page. It takes the meeting from the land of the abstract concept to the land of the concrete task check-in. We have to assume that no one is going to do meeting specific preparation, so substitute the actual work for the meeting related busy work and then talk about that.

It might also be a good idea to send along your meeting agenda, as suggested in the example. If it isn’t ready yet, try to send it along no more or less than one day before the meeting. More than two days no one remembers, and twenty∏ minutes before you might as well not bother.

III. Meeting math
If all else fails, and you literally cannot get a hold on meetings consider this formula.

E(Employees) x Pr(Pay rate) x Ml(Meeting length)

If the cost of the meeting in contrast to the profit or cost of your project makes you want to jump out of a window , someone may end up managing meetings for you.

Warning: This is a post about my job. If you think you may be offended by such a thing, now would be a good time to close this tab.

I have a friend who’s almost universally joshed for being the guy most likely to march into work early Monday morning and announce he hasn’t slept in days, because he’s been coding his way through some problem. For months I had no idea what he was talking about; I was able to turn work off if I wanted to once I walked through the door, so why couldn’t he? Slowly, given enough time pressure, almost any designer or developer can start doing the same thing. I realized this when I sat in front of my Mac Book Pro on Sunday and coded for fourteen straight hours—really only breaking for the bathroom and to eat. The reasons for this are myriad, and are the basis for an anecdote about deadlines and such.

Our company has a tendency to talk about things a lot. Given almost any project, we can find a way to have at least a dozen meetings just about how to get started. Once we’ve figured that out, we’ll have a dozen more to decide what the next steps are. The meetings we tend not to have are the ones about scope, requirements or audience. These things always seem to be someone else’s job. The head of the department I’m attached to has it far worse than me, however, as he gets pulled into essentially every meeting ever planned; it’s left to him to sit through them all offering advice and guidance where applicable, and making the hard choices about milestones and even some development issues. It’s fair to say that we have a ‘meeting culture’, and that we tend to manage by committee. This often leads to deadlines that are set by such committees.

What tends to happen when committees don’t know much about requirements or project scope is that boat docks get built in the desert; one hand is totally unaware of the difficulty (or triviality) of the tasks being performed by the other, unrealistic deadlines are set, and the end product is a mess. I found this out the hard way with my last product launch, which was governed by an arbitrary deadline that could only be met by means of several 90 hour work weeks in the dev room. The “extra time” needed to make things better after launch was almost exactly the amount of time the dev team asked for on the front end of the project. Score one for the immovable, immutable deadline. In the interest of fairness I do understand the business case for setting deadlines and/or milestones on major projects; in large organizations it’s often necessary to attach revenue to projects that haven’t happened just yet.

I guess the only advice I have for planning a project is this: understand that most of what you’ll be doing in the initial phases is really only a guess, and that you need to check your work frequently against your map to make sure you’re on track. You need to give your people the leeway to say “this map does not match this road”, and change the map. But I also understand why this is so hard to do. It’s very difficult, especially in an overcrowded and ever more cutthroat online market, to take the time to breathe through a milestone meeting where you hear things are slipping. It’s also difficult to trust that the project is worth the extra weeks of design and testing and coding and recoding; but if you show up for work everyday anyhow, then you must believe that at least a little, right?

Today when I sat in a meeting and heard all of those things happening—the deadline slipping, the map changing, the request for more time—I felt as though cooler heads had prevailed. I felt like the project managers were sticking their necks out for the dev team, and that my fourteen hour coding sprees might no longer be necessary. Even though I left the office tired of meetings I felt renewed to some degree, even if for a few minutes. Will we return to endless meetings and arbitrary deadlines? Of course we will, but for today we can pretend there is no phantom deadline. That’s worth a meeting or two for me.

Related update: I’ve just been directed to the WikiPedia entry for “Scrum“, a project management system that seems to have some really nice ideas. Your mileage may vary.