For quite a while, I’ve wrangled with the challenge of physical books versus eBooks. On one hand, physical books just look nice on a shelf, especially if they are nice books to begin with. Plus, physical books are easy to lend when someone asks me if I have a suggestion on a good book on social media marketing, or content strategy. On the other hand, I can carry thousands of eBooks on my tablet and have them anywhere, any time. As time has gone on, eBooks are slowly winning out more and more for me. Read More
I know you don’t want to admit it, but we all know that you love Kitchen Nightmares as much as I do. I actually enjoy cooking shows of all sorts and like applying their lessons to my somewhat limited selection of Kansas delicacies, which are generally limited to cuts of select beef in different shapes. Seriously, ask about my steak sushi sometime. Nevermind. My point is that while watching Kitchen Nightmares today, I had a thought about the web development trade and just how much it parallels the cooking world. I want to share these thoughts.
Allow me to borrow some definitions from Wikipedia, the clear authority on all things culinary.
This person is in charge of all things related to the kitchen, which usually includes menu creation, management of kitchen staff, ordering and purchasing of inventory, and plating design. Chef de cuisine is the traditional French term from which the English word chef is derived. Head chef is often used to designate someone with the same duties as an executive chef, but there is usually someone in charge of them, possibly making the larger executive decisions such as direction of menu, final authority in staff management decisions, etc. This is often the case for chefs with several restaurants.
In many restaurants, like many web shops, this is where the story can begin and end – for better or worse. Sometimes you’re just stuck flipping the burgers on the grill by yourself. Good head and executive chefs are not only great cooks, they generally have a keen understanding of the business world as well, because at the end of the day, if the financials aren’t right then the restaurant won’t make money and then people get fired. Likewise, a good web lead will understand the business they work in, and how it ties in to things like marketing, customer service, etc. If a person is just a really good cook, that doesn’t make them a chef, and if a person is good at writing HTML, it doesn’t make them necessarily right to lead a web office. In the end, we can also distinguish between head and executive chefs in the web world. It’s similar to comparing a CWO to a Director of Web Services. Most organizations lack that level of granularity though, and like with restaurants, the duties and responsibilities will be ran from a single touch point that could be described as either or both simultaneously.
The Sous-Chef de Cuisine (under-chef of the kitchen) is the second in command and direct assistant of the Chef. This person may be responsible for scheduling and substituting when the Chef is off-duty and will also fill in for or assist the Chef de Partie (line cook) when needed. This person is responsible for inventory, cleanliness of the kitchen, organization and constant training of all employees. The “Sous-Chef” is responsible for taking commands from the Chef and following through with them. The “Sous-Chef” is responsible for line checks and rotation of all product. Smaller operations may not have a sous-chef, while larger operations may have several.
When thinking sous chef, think art or creative directors. You can also put product and project managers in this category too. These people should be fully capable of doing any of the tasks that they oversee in a pinch, but more likely they’re somewhat more managerial in nature in the office. They communicate and coordinate. They’re the ones who will go to the project meetings so the web version of the chef de parties don’t have to.
Chef de partie
A chef de partie, also known as a “station chef” or “line cook”, is in charge of a particular area of production. In large kitchens, each station chef might have several cooks and/or assistants. In most kitchens, however, the station chef is the only worker in that department. Line cooks are often divided into a hierarchy of their own, starting with “first cook”, then “second cook”, and so on as needed.
Our chef de parties are the role-specific people. Our front end developers, our interaction designers, our graphic designers. Each has their station “on the line,” and best serves their team when they are working properly in concert with the others. Over time, they’ll usually pick up the skills from other stations to augment theirs, allowing them to move in and out of spots as necessary to help out. This gives them flexibility, a broader skillset, and an understanding of team building. It’s okay if they can’t do every station well, as long as they understand how each station gets them from prep to table.
A commis is a basic chef in larger kitchens who works under a chef de partie to learn the station’s responsibilities and operation. This may be a chef who has recently completed formal culinary training or is still undergoing training.
Interns. Nuff said.
What I think is the most important part of the striation of responsibilities in the kitchen is the principle behind earning your stripes. In a serious kitchen, you don’t just come in and become sous chef without the requisite experience. No, you start as the commis, and you work your way up. By the time you’re a sous chef, or ready to become the head chef in your kitchen or somewhere else, you know and understand the roles under you because you’ve been there. It helps you respect and understand those that work for you. Folks who have worked with me in the 24 Hour Plays have heard me give a very similar speech as it relates to theatre – that I find it very important that if you want to direct, you should spend some time as an actor, and a technician, etc. Be the ball.
Ask any ten chefs what skills are most important to being great at the craft, and you’re likely to get a broad spread of answers. But like with any trade, there are a few very atomic skills that are fairly consistently important. For instance…
A chef with a bad palate is like a web developer that uses Frontpage. Having a well trained palate is imperative to the process of selecting and procuring quality ingredients for meals. We aren’t buying beautiful rockfish or delicious cuts of beef, but we are selecting CSS frameworks and jQuery plugins. We have to have a good sense of color and design. We need to know if WordPress is the best platform for a new site, or Drupal. Our ability to “taste” the environment we’re developing and pick the right components to combine into it can make or break a project. You know you’ve developed a good palette when you can look at a website and tell what CMS it uses. Likewise if you can make the CMS you use disappear entirely to the user. They know it’s there, but you know how to keep it all perfectly balanced. This also gives you the instinct to tell when something is going wrong. When ingredients have “soured,” or you’re using too much of something, or not enough of something else.
Mise en place/Hygiene
Mise en place is a French phrase which means “everything in place.” It’s used to refer to having all your ingredients and tools ready and where they belong. I’m grouping this with hygiene because good mise en place skills inherently reinforce kitchen cleanliness and maintenance as well (I’m not just talking about washing your hands after peeing). Web mise en place would be everything from making sure your workplace ergonomics are well planned, to making sure that you lay out your software and tools in a way that makes sense and encourages good development. Just because our “countertop” is digital, doesn’t mean you shouldn’t think about how you have windows open and arranged, for instance. Web hygiene means coding clean – maintaining comments, keeping HTML semantic, and not leaving old code out to rot on the countertop, so-to-speak. A sloppily coded and presented website can be a turn off to visitors. Good web hygiene is a trait of good attention to core user experience on your site.
This is a pretty direct metaphor. The chef’s knife is an extension of their hand, arm, and body – as is our Wacom stylus, magic touchpad, or mouse. It’s all about core skill competency and practice. A good chef can dice an onion blindfolded in a tenth of the time you or I would take. You should be able to spin up a Git repo, fork, and commit just as effortlessly. Mysqldump and LESS are your bitch. You can recite CSS selectors and attributes like a multiplication table. The knife needs to be sharp, and the knife is an extension of you. Those skills make your job easier, and they show to the visitor. The competency and effort that shows through is something that users will see and appreciate. Being adept at your skills won’t always change the “taste” of your end product, but the craftsmanship is something that will show through and visitors will respect and peers will admire.
When all a chef’s skills meet in the center, it makes for a magical sixth sense. Put a good chef in a room with some ingredients and give them a couple hours, and more than likely they will magically appear at the end with a beautiful dish. That’s the entire practical value in so many of the cooking competition shows – can the cook work under pressure with unknown variables? Knowing how flavors mix, understanding cooking principles, and solid plating techniques are all integral to producing fantastic dishes in a pinch, even if they don’t know what they are necessarily walking into. Because noweb developer has ever had to build something on the fly at the last minute, right? This is also how we grow as designers and developers. Anyone can follow a recipe – they’re just a Google away. But it’s what you can do with that recipe to make the end product your own that will really set you apart. If all web development was about was following a recipe, we would have been out of a job long ago, because solutions would all be simple cut and paste jobs a monkey can do. There are times when you can even get away with that, and certainly we all have. But those are times where you’ll never stand apart, and never produce anything unique.
Oh, and then there’s…
…that important fact about the sheer way work gets done. If you get nothing else from my rambling above, take this away with you. You know one of the common, recurring themes on Kitchen Nightmares regarding why restaurants are failing? Menus and procedures that are forced upon the chef without regard or respect for the chef’s role and abilities. People playing in kitchens that don’t respect ingredients. The head chef is rarely the top person in the restaurant – someone else probably owns it – but successful restaurants know how to put the chef in charge of the menu and allows them to run the kitchen their way to coordinate the production and distribution of food, taking orders from the wait staff and cycling out the finished product. A president, dean, or director of marketing should be able to trust in their head web person implicitly – and it’s that inability to trust that I see repeated over and over as a core complaint from our peers at other institutions.
It’s that faith and commitment to excellence that makes the difference between a truly successful kitchen and restaurant, a perfectly mediocre one, and one that ends up with its doors closed.
The LATCH principle believes that there are only five ways to organize information, and anything else is a subcomponent of those five. Do you agree, or is that idea to rigid for today’s data structures?
Several days ago (or more, seeing how long it actually took me to get this finished, whoopsie), Twitter user @stomer brought up a question to the Twitterverse regarding a common tool we use any time we work in social media these days: “This a fair description?: categories are like table of contents items, tags are more granular like items that would be in index?” I happened to be on right when this hit the feed, and replied: “Categories are for organizing, tags are for identifying.” It was a simple exchange which prompted a third comment from @jdwcornell asking for some expansion on this idea, to which I am happy to oblige.
Categories and tags are two functional elements that many of us who use things like blogs, Flickr, YouTube, or many content management systems are familiar with using on a day to day basis. It’s easy for us to see how they work and what they are for because we have such a high level of exposure to them. But that’s us. I know that I’ve found myself on more than one occasion explaining the tag cloud on our university’s home page. These systems are very smart, and apply these things in cool ways, but users can tend to be, well, not so savvy. To some people, functionally, they seem very similar, which is exactly why I came up with my simple description that categories are an organizational tool while tags are for item identification. Generally this helps people get over the hump of understanding them. YouTube does a pretty good job of exemplifying this, where they have just over a dozen categories (like “Pets & Animals”) that you choose from, and then a blank field where you could freely tag a video (like “dog, boxer, barking, trick”). The first tells you where it goes, the second tells you what’s in it. Flickr lets you tag photos as well, and you categorize them through the use of sets. In that case, you get to name the sets (as opposed to YouTube where they are predefined by them), but they are basically serving as a category the same as anywhere else.In our case, we use both categories and tags in the university CMS (we use dotCMS). When a user creates content for the university in the content management system, we ask them to do both of these things. The first question that usually follows is: “What?” This is quickly followed by the second question: “Huh?” In all fairness, I can’t blame them on this. Both of these fields can be used on the front end of the web site (or not, depending on what it is), but we also use them in the CMS to enhance internal searching for content. Under this setup, categories form the basic structure of the college: office names, departments, organizations. Tags then allow specificity in identification. The result of this is searching for content categorized as the “Admission Office,” and then tagged with “checklist,” or “forms.” Or if you needed more generic information, you could search for content tagged as “contact information” and pull it from all the areas, or categories. This exposes the idea that the tags are simply identifying what is in the content. We use a similar mechanism for the calendar, categorizing by area, and tagging by topics. Then, any department or office can get a customized event feed of their category, or more general areas can pull from them all by tags. Seeing this type of stuff in action usually really helps people understand the difference when they didn’t before.
To make further comparisons, categories are kind of like folders. They are designed to help users located related content based on the implied relationship of the category name, usually based on a theme or topic. Generally, categories are predefined by some kind of administrator ahead of time, and aren’t added willy-nilly. For instance, there’s the “Admission Office” category in our CMS. It’s there in a list for the contributor to select from when they make content, and so they couldn’t make a new category called “Admissions Office” or “Undergrad Admission Office.” They are bound to what we have set up. This makes them useful for building things off of because they are predictable and structured.
Tags are almost never preset like that. Instead of folders, these would be like contextual post-it notes you stick on papers in the folder. You might agree on a policy to use some kind of convention (like always pluralize words, never capitalize, don’t include spaces, etc…), but generally there are no restrictions on their use, and authors can create and assign them during authorship of content without any extra help. In many ways, tags are a type of visible meta information, and you will hopefully break out a thesaurus if using them well. Not to confuse the matter, but it is possible to also create tags that can serve the purpose of categories, a kind of “super tag,” if you will (but it would rely on use of a convention to function properly). That kind of functionality will normally depend on your infrastructure, but the idea is that a tag, in a way, is basically a type or subset of categories. But they tend to be much more fluid and less predictable than categories. I could pull information based on the tag “student,” for example, but at the risk of missing stuff tagged “students,” or if you have the ability you could use the tag “student” to match things like “student employment,” “student events,” “student groups,” etc… In this way they are less useful functionally, but far more useful in identifying, connecting, and relating items. And looking at the big picture, properly implemented tags get picked up by sites like Technorati to help identify and group similar information from thousands of web sites on a macro level (for more information on this, take a look at the rel=”tag” microformat).
So there you go – categories organize, tags identify. Ultimately, their basic function and usage might change depending on what you’re using them in (a blog, Flickr, a CMS, etc…), but that basic principle will generally always stay the same no matter where you are. When users question their function, try to give them a simple example to go off of. If they don’t get it in our CMS at first, I tend to find refering to Flickr and YouTube to be nice examples that everyone seems to get. For more information on the discussion, I recommend the Categories vs. Tags articles at Haacked, or Usability Post.