When someone at Happy Cog tells me that they’re teaching a class for Girl Develop It or a local university, or a workshop at a conference, my first response to them is one of encouragement. Then, I say: The best way to get better at what you do is to teach others how to do it, too.

If you want to test your own prejudices and assumptions about the tools and techniques you use, then volunteer to teach a group of local designers or developers or do a short, instructional talk at your local Meetup group. Do you want an even easier way to get started teaching? Write a blog post or article sharing a development or design technique. Regardless of where or how you teach, the experience of preparing the material and then sharing it will make you better at what you do. Ready to get started?

Five Things I’ve Learned About Teaching

Know Your Stuff

For starters, make sure you know the information you’re teaching. If there are aspects with which you aren’t as knowledgeable, do the proper research and become informed. The biggest mistake you can make is to try to teach something you don’t thoroughly understand.

Make the Sale

Teaching requires you to share and transfer your knowledge to your students. But, that knowledge is transferred with a good sell. A good sell? So, teaching is a sales pitch for the material your students are learning? Precisely.

Think about the worst teachers you’ve ever had. Mine was my high school algebra teacher. She was smart and knew all of the material, but her delivery was dry and uninspired. She sat behind the overhead projector and slapped one transparency after another onto the glass. My takeaway from that was that she didn’t care about the material she was teaching, so why should I have?

Show your passion for the topics that matter to you. Remember back to the first time you learned the technique or technology you’re teaching and how excited you were about it. Channel that excitement, and relive that moment for your students.

Teach with Context

Every lesson should have context. Embed the topic you’re teaching in real-world examples. If you’re teaching responsive web design, then the material should walk through how to code a sample project. Give your students the opportunity to immediately apply and try what they’re learning. Give them scenarios that will fit how they’ll use the new technique after the class is over.

Improve and Iterate

Here’s a big secret on teaching: your curriculum is never done. You will always change and improve your lesson and approach based on classroom experiences (e.g. your students are confused by how you’re explaining a topic) or changes in the topic you’re covering.

While you’re teaching, make notes of where your curriculum isn’t working. After the class, go back and adjust it. Improve and iterate on your material after every class.

Be a Student

Take other classes, and be the student. As a student, you get to learn a lot about how others teach: the order of the material they cover, the examples they use, and how they explain difficult concepts. Good teachers always watch others teach.

Alas, these tips are only useful if you actually apply them. So, go find your first opportunity to teach someone something new, and improve your own knowledge!

There are a few options for purchasing devices for your test lab. You can buy them brand new (required for getting the latest gear like the Microsoft Surface or the Nexus 7), used through eBay or Craigslist, or legitimate used from a reseller like Mobile Karma.

I didn’t like or want the hassle of dealing with eBay or Craigslist, so I avoided those sites entirely and went straight to Mobile Karma. All of the devices are contract-free and fully tested. The condition is also noted with each device, and prices can vary based on condition. For a test lab, I have no problem buying a scratched-up BlackBerry if it is $50 cheaper than the mint version of the same phone.

You have to be careful about choosing Android, Windows Phone 7, and BlackBerry devices. The Android OS is fragmented, with different versions on different devices. There are two versions of Windows Phone 7 (7 and 7.5), which run different versions of Internet Explorer. BlackBerrys also run different flavors of the OS, and, unless you plan to get a data plan, make sure you buy a BlackBerry that supports WiFi.

In the resources list at the end of this article, I’ve included some links to information about the OS version of Android, BlackBerry, iOS, and Windows Phone 7.

Here are the devices we currently have in our lab:

• iPhone (original)
• iPhone 3G
• iPad 1
• iPhone 4 (Retina)
• Nexus 7
• Kindle Fire
• Microsoft Surface
• Samsung Focus with Windows Phone 7
• Motorola DROID
• BlackBerry Bold
• LG Optimus S (with Android)
• Palm Pre Plus

At least one of us in the office owns the most current Apple devices, so while they are not a permanent part of the test lab, we also have access to iPhone 5 and iPad Retina. Additionally, everyone on the team will get a new iPad Mini at the end of the week when they are released.

Resources to Get Started

I researched and put together our test lab with the help of the experience of others, especially using information shared by Jeremy Keith and Brad Frost. Below is a list of resources that will help you get started or improve your current device setup.

• Test on Real Mobile Devices without Breaking the Bank by Brad Frost
• Device Lab Portland
• Laboratory Conditions by Jeremy Keith
• ClearLeft’s Test Lab
• How to Build a Device Lab by Dave Olsen
• Adobe Edge Inspect – formerly Adobe Shadow, now out of beta and renamed.
• Blackberry OS Versions
• Windows Phone Versions
• iOS Versions
• Android OS Versions
• Comparison of Android Versions
• Mobile Karma

Ready to build your lab? Go!

On Saturday, it might be an email from Greg Storey or Greg Hoy asking me why our website is down.

The most important thing about The Best Email in the World is that I know when it arrives so I can give it my attention.

But let me back up a little.

My default approach to email is that it is a distraction when I am not checking or reading email. Pretty basic stuff, right? All other times I have my email client closed. The problem is, I won’t know when The Best Email in the World arrives.

My method for handling this was to check email at regular intervals throughout the day; at 10 AM, 1 PM, and 4 PM. Sometimes, however, I would miss emails that were time sensitive or relevant to an upcoming meeting (like related documents, an agenda, a meeting time change or cancellation).

This caused problems in the past because I would miss emails that needed my attention or impacted my schedule. There has to be a better way to handle this.

The Tools For Change

Over the last few months, I’ve looked into ways to not waste time constantly checking email while also knowing when The Best Email in the World drops into my inbox. Here are some tools that help me and might help you.

AwayFind

My tool of choice is AwayFind. It is both a mobile app and web service that hooks into your email account and monitors your email for The Best Email in the World. Through the web or mobile app you can set different rules for when you want to be alerted via push notifications about an email.

There is a My Important People list, where I add email addresses of people whose emails will probably always be important to me. I am notified whenever someone on the list emails me. Occassionally, I am waiting for an email from someone but don’t want them on my permanent My Important People list. For these situations I use a special list that alerts me if someone I add to the list emails me in the next, let’s say, 4 hours.

I can also get alerted if I get an email about a certain topic. I enter a word or exact phrase that I expect will be in the email subject and AwayFind alerts me when an email comes in that matches.

The third way to set email alerts is by who I am meeting today. AwayFind looks at my calendar and alerts me if someone I’m supposed to meet with emails me within an hour of our meeting. This is the most useful notification for me because it alerts me when a meeting time changes, someone sends me an agenda or other document to read over before a phone call.

VIP in iOS 6

In Apple’s iOS 6, which is due out later this year, they have added a VIP feature in the mail client. There isn’t a lot of public information about VIP but their site says that the feature will let you “set up a VIP list so you’ll never miss an important message from your accountant, your boss, or your BFF. “ This looks promising.

Mail Client Filters

Your email client may also have filters or rules you can set that will alert you when you get an email from a certain email address. I use Apple Mail and it is simple to set up a rule that will play a certain sound when an email comes in from someone important to me. There are two disadvantages to this solution: your email client has to be open and you wont’ be notified when you’re away from your computer. But in a pinch, it might just work.

Boxcar

Boxcar is a web service that makes it easy to send your mobile phone push notifcations based on information and events from many different websites and web services.

You can configure the Mail service they offer to alert you when an email comes in. Boxcar’s mail notification service requires that you forward your email to a private Boxcar email address. If you use a service like Gmail you will want to create filters first so you can specify which email is forwarded and control when you are alerted. This is more useful than just using your rules or mail filters in your email client because it sends push notifications to your iPhone via their iOS app.

With one of these services, you should now always know when The Best Email in the World arrives and needs your attention. Now go quit your email client and get back to work.

In his blog post, Greg wrote:

We will step outside of comfort zones and experiment with smaller teams and agile processes. We will make quick decisions. This process will be as much about experimenting with how we work together as it will be about creating something. And most importantly, we hope to emerge with new ideas we can use on our client projects.

My role for Site Week was focused only on the development (back-end coding). On the technology side, we are very familiar with looming deadlines, extra effort, and short turnarounds for last-minute project needs, but nothing quite as fast as what we were up against when we walked into the office on Monday morning. We had to have some type of software to power the new site by Friday afternoon.

Gulp.

Our previous site was made up of static files except for the news section, which was powered by WordPress. The entire site was in a Git repository on Beanstalk and any changes and updates were done manually and then deployed out to the server. This worked well because our site could be easily moved to a new server without a lot of fuss, anyone could work on the site locally without a lot of setup, and the site was very efficient in terms of performance because it was almost completely static. On the downside, it also meant that someone had to wade into the template code for every little change.

Before Site Week even got started, I began discussing the technology side with my Philadelphia cohort Mark Huot. Mark and I discussed how we could use this opportunity to push ourselves a little and try something new. We are both very familiar with the technologies we use for nearly every client project and, honestly, it wouldn’t have been much of challenge to build a basic company website in a week’s time. We agreed that we should branch out and build this new site on a technology we both haven’t used in client work.

I wanted to make sure we had buy-in from both presidents of Happy Cog, Greg Hoy and Greg Storey. At this point I was feeling very passionate about what we needed to do. I sat down and drafted an email to both of them to make the case.

My approach to the technology choice is in keeping with the idea behind the entire exercise: let’s take a risk, do something new and a little crazy, let’s have fun and learn a ton in the process.

I went on to argue that the technologies we currently use for client projects should be off the table completely.

We are already experts in both and building the new site on them would certainly be a safe bet but it wouldn’t mean we’d come out of it having learned something new or expanded our expertise.

Over the course of the long-winded email I laid out the pros and cons of different platforms and CMSes. I had a few requirements:

• The choice had to challenge us and make us feel a little uncomfortable going into Site Week.
• We had to ensure that a CMS or technology we chose would allow us to perfectly deliver our well-structured HTML templates. No inserting junk or extraneous markup allowed. Yes, in 2012, this is still a problem with some systems out there.
• Whatever we built had to be maintainable by us as we continue to iterate on the site after Site Week was over.

What did we decide? We chose Ruby on Rails as the framework on which to build our own custom CMS for the happycog.com website.

We chose Rails because it was an exciting and different type of challenge for us and because Ruby is an elegant and expressive langauge. It fits right in with the Happy Cog approach to design and front-end code. We were very excited about getting to work on a Rails application.

On Tuesday morning of Site Week, after the entire team spent the previous day on a project kick-off workshop full of brainstorming, discussions, sketching, and whiteboarding, Mark and I (the two developers on the project) began to tackle the CMS build. First up was to take the site structure established the day before and start laying out how the app would be structured.

On large easel paper, we listed out the models we’d need for both immediate and future functionality. We discussed the features that we knew we could build before Friday and those that we had to push off to a later time. We even discussed data models for future features just in case they impacted the development work we were doing during Site Week.

We ended up with four or five large pieces of paper stuck to the conference room wall to which we referred throughout the site build as a reminder of what we needed to do. In the busyness and chaos of Site Week, it was nice to look up at the wall and get a reminder of what you’re working towards. After the intial planning, we jumped into Rails and started coding.

(Okay, we actually spent a little time getting our development envioronments set up, reading a bit of documentation, figuring things out, and reading a bit more documentation.

Then we jumped into coding. Oh, look, it’s Wednesday.)

We did experience a few bumps along the way, mostly getting set up for development. Our application uses PostgresSQL for the database and since we hadn’t used it before, it took a little time to get installed and working properly on OS X. Adding to the headaches, we were all running different versions of OS X so once we got it running on Lion, we had to repeat on Snow Leopard.

We also needed to make sure we were all running the same version of Ruby. RVM (Ruby Version Manager) makes it easy to set up multiple versions of Ruby (as virtual environments), ensuring we are all developing on the same version. It also allowed us to match our Ruby version with our host, Heroku. Unfortunately, we’ve been messing around with Ruby since long before RVM gained popularity so we had to uninstall our patched together Ruby to make way for RVM. If you’re nervous about getting up and running on Rails, my best suggestion is to start fresh. It really is easy to do provided you haven’t crippled your system with 10 years of experiments.

If you followed along with Site Week, you already know that we met our one week deadline and successfully launched the new Happy Cog site. Mark and I were able to put together a CMS to power most of the site’s content. We didn’t get everything done we had planned and had to leave some parts of the site as static content in templates. We ran out of time.

Was it a failure? Not at all. All week we discussed and planned different scenarios, flagging features and functionality that we could push until a later time. We didn’t need to make the CMS perfect, we just needed to make it work by Friday. And we did.

Each discipline area had its own challenges and experiences during Site Week, but this is how the development team planned and survived a week hunkered over laptops around a crowded conference room table, coding our first Rails app as a team. We have a lot of work left to do still (there are many outstanding issue tickets filed for bug fixes and feature requests) but we are very happy with what we accomplished. Even more so, we’re glad that we took the chance to try something new with a tight deadline on a much publicized project.

Technology List (for the nerds)

A list of the technology, software, and services we used during Site Week development work:

• Ruby on Rails 3.2.1
• ActiveAdmin gem for the initial admin interface.
• Sublime Text 2
• Heroku for deployment and hosting
• Beanstalk for version control
• RVM for local development environments
• Meet Rails 3 screencasts by PeepCode to get up-to-speed on the changes in Rails 3.

During in-person meetings, I also try to take as many notes as possible. I often scribble notes while others are talking, and if I’m the one doing the talking—or if the discussion is a fast paced back-and-forth—I try to jot down as much as I can during breaks in the conversation. Sometimes I’m able to pen a few keywords in the middle of conversations that I can go back to later (during a break, perhaps) and elaborate on so as to not forget the most salient information.

But I hardly reference the notes later. I write down the notes to help me process the meeting as it happens.

Why do I do this? It’s not because I’m a bad listener. I’m just not good at retaining most of the information I hear. I can process information I hear on the spot and provide feedback and responses that make sense, but for deeper analytical thoughts and responses, I need to write the information I’m hearing down in order to properly process it.

I don’t know if I am predisposed to this type of behavior through the gene lottery or if it was a learned behavior while in school. When I didn’t take notes, I quickly fell behind in a class or lost focus as my mind wandered off to other places. In graduate school, I found myself taking detailed notes just to keep up. It became a survival mechanism for me.

My note-taking habits remind me of the tagline from the Field Notes notebooks by our friends at Coudal Partners:

“I’m not writing it down to remember it later, I’m writing it down to remember it now.”

Drucker on Learning

Back in July, I briefly mused on my personal site about an essay by Peter F. Drucker called Managing Oneself. I was surprised by how intriguing I found the 55-page treatise on self-awareness and self-acknowledgment of our own strengths and weaknesses. Here’s my quick summary of the essay from that post:

Drucker touches on many topics throughout the book about managing your own career, knowing yourself and your co-workers. He draws contrasts between the working life now and how it was before we had a vast majority of the workforce as knowledge workers. There are a few good suggestions on working in teams (the book would be a great team building exercise) and learning to work with your co-workers instead of just alongside them.

An important part about knowing yourself, according to Drucker, is awareness of how you perform and learn. Some people perform better in situations where they process information through listening. Others learn and perform better by reading.

Drucker also talked about how writers learn. Because I’ve worked remotely for years with both co-workers and clients, I spend a large part of my day writing emails, Basecamp messages and, yes, even code. Outside of writing an essay or a book, a lot of my daily routine involves writing. So, am I writer? Yes.

Unsurprisingly, writers learn and retain information best when they write it down. It’s not just about recording the information for later reference. Writing it down is a hack of sorts to help remember, and perhaps process and analyze, the information that is being discussed.

Drucker has a great anecdote about the composer Beethoven:

Some people learn by taking copious notes. Beethoven, for example, left behind an enormous number of sketchbooks, yet he said he never actually looked at them when he composed. Asked why he kept them, he is reported to have replied: “If I don’t write it down immediately, I forget it right away. If I put it in a sketchbook, I never forget it and I never have to look it up again.”

Do you have that same experience?

Writing Tools

I want to leave you with some tools I use to write and take notes during meetings. While not a comprehensive list, these tools have helped me become a better listener by writing:

• nvAlt – fork of the Mac app Notational Velocity. It provides frictionless plain text notes that can sync across devices using Simplenote sync or Dropbox.
• Notesy – iOS app that lets you write plain text files and sync them with Dropbox. This is my mobile version of nvAlt.
• Edward Tufte graph paper pads – Smooth, smooth paper that makes writing easy. The stock is thick so that even “hard writers” like me don’t get writing indentations on to the next sheet of paper. I have a standard 8.5x11 size and a larger 11x19 size for when notes and drawings are needed. As I mentioned in a previous blog post, My Paperless Trail, I take those meeting notes and scan them for safe keeping and later reference.
• Field Notes – Both my wife and I love these notebooks for random notes, lists, and scribblings. I keep it in my pocket on the go. Like a good pair of jeans, they’re better when they’re worn.
• Fisher Space pen – Black matte with a clip.

Are you also a writer? If so, don’t rely on someone else’s meeting notes. The value isn’t in the notes, it’s in the process of writing them down. You can only do that for yourself.

Last Fall, with the impending arrival of our first child and initial plans to sell our house, I decided to simplify our life by reducing the amount of stuff we kept around. Part of this was my Great Paperless Office Initiative 2010 (affectionately referred to as “sigh” by my wife). Since I had already put so much effort into doing this for my personal documents, it only made sense to extend this to how I store, search, and organize documents for my work at Happy Cog.

My tools are:

• DEVONthink Pro Office because of its ability to OCR (Optical Character Recognition) scanned documents and
• the Fujitsu ScanSnap S1300 scanner.

Together I can almost effortlessly scan, OCR, and organize my documents. The result is a paperless, searchable and smart filing system.

Keep ‘Em Separated

DEVONthink Pro Office allows you to create different databases where you can store your documents and other information like URLs, RSS feeds, email, spreadsheets, and rich or plain text notes.

I have different databases for each context of my life: Personal and Work. In the Personal database I store everything from financial records to scans of important receipts, medical documents, bills, and even manuals for appliances. In my Work database I store project information (PDFs, wireframes, sitemaps, technology research) for both active projects and prospective clients. Because I sometimes have to do research for prospective clients (e.g. a certain technology or platform is required and I need to learn more about it), it’s always handy to keep that information together in one spot. Here’s a sample of what my setup looks like:

There are three top-level folders: Clients, Internal, and Prospects. Clients are broken up into separate client folders, Internal is organized by internal projects, and Prospects by company. The hierarchy can be as simple or complex as you want. For my Happy Cog database, I don’t need anything complex, so this setup works just fine.

Getting the Data In

While doing research on a prospective or active project, I can drop in bookmarks to related web pages (or as I typically do, create web archives for offline viewing), import PDFs, take notes, or as in the case of the (unfortunately fake) “Breakfast Tacos USA” client, I’m pulling in an entire Google Alert feed for a search related to the project. This automatically updates my DEVONthink database with the latest search findings.

For phone or on-site meetings, I prefer to take meeting notes on paper. In the past, I have taken notes directly into DEVONthink or into a plain text file. I’ve found I take better handwritten notes, which also allow me to draw diagrams, doodle, and otherwise express myself as quickly and succinctly as possible. I find that hard to do when just typing text in an editor.

I used to take my notes in a bound notebook (like the Moleskine variety that are so popular) but that made it difficult to get the notes scanned. I’ve settled on a notepad of standard (for the USA) 8.5 × 11 graph paper. The paper I use is the Edward Tufte variety. I like the quality of paper and how easy it is to write on it.

After a meeting, I drop the notes into my ScanSnap scanner and press the glowing blue button. It’s a duplex scanner so it scans both sides at once. DEVONthink takes over by OCR’ing the notes and placing them in my database inbox. I can move them to the project or let it auto-classify the document. I should note that unless you have very neat handwriting (and I do not), the OCR’d document may not prove very useful. You can mitigate this somewhat, however, by using a good document title and adding relevant keywords. Doing so will help your document appear in search results.

After scanning, the paper notes are kept for a short period (days, not weeks) and then shredded.

For web-based resources, I like to import web pages as a web archive or entire website using the Import Site feature.

Getting the Data Out

The real power of DEVONthink (and what puts it beyond just using the Mac OS X Finder and Spotlight) is its “Artificial Intelligence.” Along with text searches of PDFs, DEVONthink automatically displays relationships between your documents, which means you can find exactly what you’re looking for plus any related material. This really works well when you have a lot of documents stored in the database or are working on an extensive research project (like writing a book, a proposal, or planning a new technology platform).

From DEVONthink, I can also quickly email documents to coworkers or export entire projects as folders or even as a website.

Further Reading

My current workflow with DEVONthink Pro Office doesn’t take advantage of everything the software can do, so if you’re interested, I hope you’ll read more about it. I can recommend the following additional reading (which, coincidentally, I found by searching my database for DEVONthink materials):

Feature List of DEVONthink
Bylr.net for an overview, scripts and tweaks
Take Control Of Getting Started with DEVONthink 2 ebook

For the last five years, I’ve been working from home. It started back when I was the first employee at Airbag, and then continued after we merged with Happy Cog in August 2009. As part of the San Francisco team, I’m 3 hours ahead of, and almost 3,000 miles away from, most of my co-workers. My process and methods have evolved since the early days when it was just me on the East Coast and Greg Storey in our southern California office. As we added more people, I learned new ways and implemented new tools to become a more effective remote worker.

Fast-forward five years. As a Technology & Development Director at Happy Cog, I run and direct all of the development projects in the San Francisco office. I work closely with our entire team day in and day out. This does, of course, present some challenges. My days have me jumping from project to project, writing code, being on phone calls and sorting through email. Here’s some insight on how I try to organize my days to help me be as efficient as possible while working so far away.

The Quiet of the Morning

The mornings are quiet because San Francisco is still sleeping, so I use this time to get through tasks that don’t require consulting with my coworkers in San Francisco. The first task of the day is always email.

I sit down with my morning coffee and review email that came in the evening before. Unread email usually consists of new issue tickets from clients (we use Lighthouse) and Basecamp messages from clients or co-workers (like the milestone reminder that this blog post is due). I am copied on every new issue ticket submitted by a client so I can see what the problems are, fix them or discuss them with my co-workers when they start their workday.

I use my quiet time to go through the email and plan my day. If I try to immediately respond to and act on every email message that lands in my inbox, my day would consist of just reacting to several different projects without any organization or method. Spending the entire day just reading and reacting to email doesn’t sound like much fun at all. To prevent this, I don’t respond to email immediately unless it’s an emergency. Instead, I create tasks for myself in OmniFocus. I jot down notes for a later discussion with a co-worker (for the GTD wonks, I use the “Talking to [coworker name]” context) or ideas I want to bring up on our daily phone call.

The email step can take awhile, but I do try to limit it to one hour. After that, I close my email client so I’m not tempted to ride the “New Mail” button. For the rest of the day, I close my email client when working on a task, and if it is open, it is set to only check once per hour.

In the remaining time, I try to complete work that requires intense focus, like coding, reading, or writing.

Lines of Communication

Early on, I found remote workers need to over-communicate with their co-workers and vice-versa. Over-communication is a must. Leslie Camacho notes some discussion during the SXSW session on company culture:

Mozilla’s biggest tip for working virtually is to over communicate. Say it once, then email, then IM, then phone, then whatever it takes to be understood. Working in a completely virtual company myself, I highly endorse this tip.

How we communicate is also very important. Some methods are more awful than others, and they are all awful compared to being in the same room. Bank on that. But we can still make it work!

Here are the tools we use to make it easier:

• Basecamp – The central repository of all knowledge and information about a project. Don’t put it in email, put it in Basecamp.
• Campfire – Chit chat, silly banter, and a place to check in.
• Instant Messaging (iChat) – Great for private conversations, but very disruptive.
• Phone/Skype/Audio Chat – Should be used a lot and whenever there is a communication breakdown via other methods.

Did you notice I didn’t include email?

For real-time, intrusive chatting tools like Campfire and iChat, I suggest removing all alerts (bouncing icons, badges) and silencing all sounds. No one should be able to interrupt you at will. That’s what the phone is for, and, unlike iChat, it’s used much more sparingly.

Scheduling Phone Calls

To keep my mornings free to focus on work, I try to schedule all phone calls in the afternoon, if at all possible. Since I’m 3 hours ahead of the San Francisco office, this is easy to do. The first phone call of the day is at 12:30PM Eastern time for our daily check-in. The entire team in the San Francisco office spends 10 minutes discussing the tasks for the day. I always request that the rest of my phone calls take place in the late afternoon, and I try to bunch them up. This isn’t always possible, of course, but I make it my goal.

Taking Notes, Organizing Project Materials

For some reason, I find it harder to remember information from conversations if I’m not in the same room as the person with whom I’m talking. I used to keep a notebook with notes and ideas from phone calls, and it allowed me to always reference back to a phone call to verify information. Last year, I switched over to a software solution, because I found that searching is faster than flipping through pages.

My project documents, phone call notes, related emails, reference URLs, and anything else I might need get stuffed into DevonThink Pro Office, a powerful database tool by Devon Technologies. DevonThink is an over-achieving piece of software that allows you to easily store, tag, classify, and search for documents. It’s where I put everything: bookmarks (fed in via RSS from Pinboard), PDFs, images, text documents, phone call notes and email. It’s the hub of my attempt to maintain a paperless office.

Do you work remotely? If so, what tools and tricks do you use to manage your time and still be an effective coworker?

Our composter isn’t a complicated piece of machinery worthy of a TV appearance with Ed Begley Jr. It’s a black plastic dome that sits on the ground and acts as a food scraps cooker. On hot summer days in North Carolina it quickly heats up and breaks down anything we toss in it. Two years later, our three-person household has never managed to fill the composter up faster than it decomposes the food.

The composter we use is The Earth Machine. Set up was simple. I chose a convenient place to install it (one where I wouldn’t have to walk too far from the kitchen door) and secured it in the ground with stakes. Next, I shoveled in a small starter piles of dried leaves and mulch and then dumped in our first batch of food waste, which consisted of egg shells, potato peels and apple cores.

Composting requires some very light maintenance. You need to stir the mixture to keep oxygen in the mix, feeding the microbes that chomp away at the food scraps. You may have to add water so the mixture doesn’t get too dry. In the humid weather of the Southeast, however, I usually need to dump in a few pitchforks of dried leaves and dirt to help dry out the compost mixture. If the compost is too wet, it will stink and swarm with fruit flies (Did I mention the location of our Earth Machine is along the fence that borders my neighbor’s house?).

The benefits of composting to the local landfill are immediate: there is less trash to bury in the ground. For us, the benefits are delayed by several weeks while the pile of food is turned into compost. After that, however, the cycle repeats and your backyard crop of Blood Red Atomic Carrots will love you for it.

As a developer, the switch to composting teased my fancy for making small changes in our development projects to become more efficient and sustainable. Introducing efficiencies in a development system doesn’t require a whole new application framework, a new programming language or a new type of version control system. These wholesale changes rarely make you more efficient.

Consider automating project tasks that you have to do more than a few times. This could be in the form of:

• a simple Ruby script to set up your basic SVN repository project structure,
• finally automating that database backup you perform every Friday at 5 PM or
• reducing the number of manual steps it takes to set up a new client project and subdomain on your development server.

Happy Cog’s own Jenn Lukas took the residuals of her experience building templates for ExpressionEngine and created a set of starter files that you can use to quickly get up and running on a project.

Beyond automating tasks, it’s also easy to save your own scraps of code by maintaining a code snippet bucket where you toss code you didn’t use in a project or may use later. Turn often used code into a plugin for your favorite application framework or content management system or just have it readily available in your code snippet bucket.

Simply put: Make your scraps work for you.

What have you done to make your website building more sustainable and efficient?