Posts Tagged ‘productivity’

My Joel Test

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

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

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

The Joel Test

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

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

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

Combining the two approaches, I emerge with this:

My Joel/Julie Test

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

    Red indicates a failing test.

  17. Can I bring my bicycle to work?

What’s on your Joel Test?

Test-driven CSS Development

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

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

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

TDD for CSS. OMG!!

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

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

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

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

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

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

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

Sh*t People Say to Front-end Developers

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.

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?

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?

Productivity System Smackdown: FlyLady vs. GTD

Posted on: 2 Comments

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.