Five Questions with Jeff Starr

Avatar of Chris Coyier
Chris Coyier on (Updated on )

I first knew of Jeff through his website Perishable Press, which has long been a fantastic web design resource blog focusing on CSS, WordPress, and a lot of hard-to-find-elsewhere .htaccess stuff along with a good amount of Jeff’s personality (which I consider to be a prerequisite of any good blog) . As you may know, Jeff and I co-author Digging Into WordPress together, both the book and the blog. Jeff is really a get-things-done kinda guy and I’ve always admired that about him. I thought I’d get him to do an interview where I could ask him some things I’d never asked him before.

*Chris: Your writing style is extremely comprehensive. For example, you recently wrote an article about CSS border rules. It’s not an overview or tutorial, but more of an encyclopedic approach documenting these properties. Is this a conscious choice? Or just “your style”?

Jeff: That particular post was one of my lazy “note-dumps” with a quick intro and closing slapped on. Typically, I will take a post from that point and continue to flesh it out with as much relevant information as possible. This usually results in longer articles that cover more ground and/or go into greater depth. It’s always a matter of addressing the target audience where they’re at, which is generally an educated guess. How much do you assume your readers already know? Do you begin with how to turn on the computer and work your way to the point, or just assume they’re exactly where you’re at and deliver the goods? I think a lot of my articles try too hard at catering to the least common denominator when they would probably be just as useful if I had cut directly to the point. I think finding the balance is key to writing good tutorials.

I do get obsessive about web-design stuff and writing about it. It’s a rush to see work come to fruition, and I like to make sure that I’m not missing anything along the way. All the details need to be accounted for. All the nuances need explained. I think maybe years in school have warped my writing style to sort of echo that academic textbook voice. I personally find that style easier to digest when dealing with lots of material, but for anything else it’s probably overkill. When I first got into writing web-design tutorials/articles five years ago, I was literally writing for myself, entirely for the sake of learning. The more information I could lookup and include in an article the better. These days, I enjoy this sort of “encyclopedic” approach when it’s useful, but continue to try to “tone it down” and “loosen up” as much as possible. I still associate the idea of “quality” with well-produced, well-researched content, but don’t worry as much about being so comprehensive with everything. There’s just not enough time to keep up when you’re working on that level.

*Chris: The “target audience” issue I find interesting in our field of tech writing. It was a question we got asked a lot while writing our book: “what level audience level is it for?”, to which I typically responded, “well, uhm, sort of intermediate but there is value in it for all levels.” Then on this blog, I tend to waver around quite a bit in terms of what skill level any particular article is best suited to.

What is your approach on Perishable Press? Do you try and keep it targeted the same level reader all the time? And perhaps more interestingly, do you think tech publications in general would be more successful if they remained consistent in their skill level targeting?

Jeff: I think it depends on the topic. When I write about “blogging” or “social media” for example, I don’t mess around explaining and defining everything – I just jump right in. Writing about specific code examples or techniques is the same way — you just have to assume that, if someone is checking things out on that level, they’re probably savvy with the basics. On the other hand, when you’re exploring broader topics, such as how to secure a website, readers of all levels may be reading, so it’s more important to explain everything. Also important when writing is the idea of “breadth” vs “depth.” Stuff can be very broad in scope and deep in explanation and nobody will read it because it just looks scary, or it can be so pointed and shallow that people will dismiss it outright as spam. Personally I enjoy writing from the other two perspectives: “broad and shallow” or “focused and deep.” Either of these approaches tend to make for great articles. For example, I recently did a post that covers 76 WordPress techniques that is extremely popular. Nothing too deep there, but it sure covers a lot of stuff. You see amazing content like this from Smashing Magazine, Six Revisions, and Nettuts all the time. Likewise, there are posts that fall into the “focused and deep” category. For me, that’s where the quality is — a well-focused article that deeply explores its topic. That’s the kinda stuff that I like to read, so that’s the kinda stuff I try to write.

As for tech books, I love ’em and think they’re useful, but they all seem to follow the same general format: boring intro, cover the basics, slog through some theory and then spit out some examples. And it’s always written in that stiff “academic-textbook” voice that puts so many readers to sleep. These books can be awesome learning tools, but there’s no reason they all need to be so plain, boring and predictable. I think this is one of the reasons why we chose to self-publish and go the DIY route for Digging into WordPress. If you look at the difference between what we’ve created and how it would’ve been with a major publisher, you totally get why we made that decision. Whether or not taking risks, being creative, and changing things is right for other tech books depends on too many factors to even think about.

*Chris: Organization is another attribute I associate with you. For example there is a classic series on Perishable Press about obsessive CSS formatting. In one of them you claim to order your CSS rules by their line length, which I have to admit I find borderline insane, mostly from a maintenance perspective. Although I do also find it visually appealing. Do you still do it like that? Anything new? Where does that obsessive organization come from?

Jeff: Haha, yes compared to your single-line style of writing CSS, I can see how organizing by line-length would seem tedious. But for me, writing my CSS that way makes it easier on the eye and easier to maintain. Everything is so neat and organized that if something — even the smallest little thing — is out of place, it really stands out. A quick scan through one of my stylesheets and you know immediately whether or not it’s complete or needs work in certain places. But not just for CSS, I get obsessive about any code that I’m working with, whether it’s HTML, PHP, JavaScript, or even HTAccess. I’m just an extremely organized person, both online and off. It isn’t always beneficial in the “real” world, but when it comes to working with code, pixels, and writing, strong organizational skills make it possible to get more done in less time. I think organization is fundamental to how the digital world operates. Essentially, the Web is nothing more than a complex organization of binary data. I think that the more organized you are, the closer you get to the true “essence” of the Web.

I have to admit though, working with you on the DiW site has given me a new appreciation for writing out CSS declaration blocks in single line format. It does seem a little quicker when scrolling through longer files, and so I have been integrating single-line declarations into my own, line-length-organized stylesheets. Good examples for when a single-line declaration is going to work better than the separate-line approach include simply styled elements such as strong, em, code, a and so on. I think punctuating stylesheets with different coding styles improves readability and maintainability. Instead of just miles of similarly formatted code, you get these nice breaks that help to divide the document into readable/scannable sections.

*Chris:So what’s the “day job”? I know you work in some kind of lab. Does that involve any web work or is that relegated to freelance and side projects? Any future plans?

Jeff: Ah yes, the “day job.” When I first jumped into web development around six years ago, I did it sort of “on the side” on a part-time basis. Back then, I needed a day job to pay the bills while I learned the ropes and got things up and running. Since then, I have established a small design company called Monzilla Media, where I do web development, graphic design, and other creative work. Fortunately, things are at the point now where I could probably survive without my day job, but I guess I’ve just been too lazy or paranoid to let it go. Having that regular, full-time job provides health insurance for my family and provides a little extra “cushion” each month. But when the time is right, I’m looking forward to moving on and focusing entirely on web design, writing, and other creative pursuits.

Future plans include anything and everything. For now, I am just going with the flow and working as much as possible. Eventually I would like to focus more on writing, and maybe even teach a few classes and try to help some folks here in the local community. But that’s far-future thinking. Until then, it’s all about doing my best online and enjoying life along the way.

*Chris: As we both know, and most people in our community know, managing your time is no trivial skill. Responsibilities and commitments can pile up to the point of being overwhelming very quickly. You are juggling our book, your online business and blog, your day job, your family, and I’m sure much more. Do you just take it day by day and react as needed? Or do you have a master plan for keeping things in check?

Jeff: Great question. I Mostly just take it day by day, but I do some planning as well. With the dynamic nature of the Web and working online, most of what I do is either spontaneous or reactionary, depending on the situation. I just sort of know what to do intuitively without too much explicit planning. I know what I want to accomplish, and just sort of direct my daily activities toward my long-term goals. The book is a great example. I don’t recall sitting down and saying anything like, “okay, now let’s figure out a plan for getting this done.” Instead, the goal of completing a WordPress book was there, and everything else — writing, editing, design, printing, etc. — just got done during the course of things. If one of us had wanted to try to schedule and plan everything, much time would have been wasted. By keeping things fluid and flexible, we made a better book in half the time.

For me, the flexibility of flying on “auto-pilot” enables a much greater degree of multitasking and scheduling flexibility. I hate planners. I have never used any calendar or scheduling program. It would just take too much time to try and figure everything out and fit everything in. Rather, I get things done by keeping everything as wide open as possible. Along the way, if I have an appointment or deadline, I will add it to a sticky note and then work everything else around those static things that cannot be changed. This enables me to flow everything else on the fly, as needed, according to opportunity, and as desired. Beyond staying fluid and flexible with my time, I also like to take care of all the “little things” and miscellaneous tasks and errands before doing anything serious. I find that it is much easier to concentrate on design, writing and coding when I know that all the little stuff is taken care of. A good day is when I get up early, take care of all the daily tasks by 9:00am and then spend the rest of the day doing what I truly enjoy: well-focused web design and content creation.

I guess if you are doing what you love, you just do it. When I get to the point where I am constantly scheduling stuff and trying to figure out how to get everything done, it’s time to switch gears and pursue a different passion.

Thank you for the interview! :)

Big thanks to Jeff for taking the time for the interview. He’s also on Twitter @perishable.