Early last year, I started renting a desk at Studiomates while working remotely for Adobe. With the majority of mates either running their own companies or freelancing, I felt the itch to follow suit. This feeling has been with me ever since I first started working for someone else. I knew that one day it would be too much to bear.
I sat down with Tina Roth Eisenberg and discussed my dream of being on my own, as well as my nightmares of making the initial jump. (I start to make sense of the memories of everyone in the pool already, yelling for me to join, while I cautiously dip my toe in the water.) She asked me, “What is holding you back the most?” Hands-down, it was my fear of not having that initial project to get me off to a running start. Without this, I would never find a project. I would burn through all my savings and end up homeless. Now, I know this sounds dramatic, but when you’re going through this decision, those thoughts are a daily occurrence—even after making the decision. At that moment, she gave me TeuxDeux.
One year later—I’m not homeless. I have a number of websites and apps under my belt, an immeasurable sense of freedom, and the experience of working alongside some of the very people whose online exchanges once gave me Bieber Fever-like reactions. So, what did I learn?
Save as much money as you can
Running out of money is the stress of all stresses. And this is the last stress you want when trying to do good work. It hinders your creativity and forces you to make quick decisions. I left Adobe with a considerable amount of savings, which calmed my nerves to a certain extent, but even still, I had frequent panic attacks.
How much is enough? Think of a number you could see yourself burning through, then double it. Once you’ve doubled that amount, triple it. There were countless expenses that came out of nowhere when starting Destroy Today LLC—the most memorable being the interim health insurance. I had a 3-month window to sign up for COBRA insurance while shopping for more affordable coverage. The idiot in me, who doesn’t read the fine print, decided to wait until the last minute to sign up, so I wouldn’t have to pay for those months. Little did I know COBRA is retroactive, so shortly after, I received $4000 bill from the past three months of coverage. That hurt.
Hire a lawyer and an accountant
Setting up a business can be tricky. In New York, there are a few hurdles to intentionally prevent just anyone from starting a business. Like, you must announce your business in two NYC publications, which ends up costing about $1500. Instead of handling this myself, I hired Jerald to take care of it. Jerald is my lawyer. He takes care of all my client contracts. He also helped me choose the type of incorporation that was right for me. Since Jerald uses half of his office space as an incubator for startups, I know he understands my line of work.
Then there’s accounting. The best money you could ever spend is on an accountant you can trust. Warren handles my taxes and he’s been handling my dad’s for the past 30 years. I use Xero to keep track of invoices and expenses, and every Sunday I balance the books for the previous week. Once a quarter, Warren looks at the numbers and we’re good to go. This confidence in my accounting brings incredible peace of mind come April.
Join a co-working space
After a year of renting my desk at Studiomates, I could easily say I will never go back to working at home. The benefits of a co-working space far outweigh the cost of rent or time to commute, and I’m almost certain I wouldn’t have made it on my own if it weren’t for Studiomates.
When at Studiomates, I’m in work mode. I put on my headphones and go full speed ahead. My desk does not sit directly next to my comfortable bed, nor do my video games feed my procrastination. At the end of the day, I ride the subway home and my mental gears shift. I feel a sense of relaxation that only home can provide. This separation keeps me sane.
Inspiration is everywhere in a co-working space. Seeing others work hard inspires me to work harder. Watching others ship amazing products makes me want to do nothing but the same. In my first month at Studiomates, we held a show & tell for everyone to introduce themselves and share what they were working on. My jaw dropped an inch with each presentation. By the end, you could taste the inspiration flowing through the room. People started approaching each other, asking questions and discussing ideas of their own.
In this past year, every single job I’ve taken has come from someone in the studio or visiting the studio. Since (almost) everyone in the space is in the same field, it’s the perfect environment to find work as well as find people to work with. Some of the most common scenarios I see come from a designer needing a developer to build their design, a developer passing a job along because they have too much work, or a casual conversation about an idea turning into a collaboration. And this happens all the time.
Make your availability known
This sounds dumb, but it’s important—make it known that you are looking to take on more work. Early on, I missed out on several opportunities because people just assumed I was too busy for their project. It’s easy to imagine. In the weeks leading up to the TeuxDeux launch, I was heads-down, constantly stressing, and only talking about TeuxDeux. In their eyes, no way am I available for more work, but in reality, I’m planning the next few months post-launch. You can have a great network, but if they only see you working, everyone will just assume you’re booked.
On the reverse end, don’t wait for someone to approach you. Reach out to those you want to work with. Send them a note saying you’re available and interested in working together. I sit next to the Oak guys at Studiomates and for months, I watched them ship amazing products. One day, on a whim, I wrote a short email to Skylar simply saying I’d love to work together. From there, I was able to lend a hand with Dropmark.
Know your limits
Leading up to the TeuxDeux launch, I worked 40 hours over the course of a weekend. I felt a constant pressure on my forehead and shots of pain in my chest. I definitely exceeded my limits and my body let me know it. Never work this hard. Ever. Whatever you’re working on is not worth the mental and physical pain. I learned how to tell myself that deadlines will come and go, and everything will be fine, regardless of whether we finish in time. My mom always says, “Tomorrow is another day.” Some nights, I need to say this to myself, but it helps when I do.
Go for it
I’ve learned a lot about myself since being on my own. I feel stronger and more independent than I’ve ever felt in my entire life—even if my internal voice is much louder and longer-winded than ever before. Every project is a challenge and provides a real sense of ownership. Each day ends with great excitement for the next. Is it for everyone? No, but if you have the itch, go for it.
It’s late on the first of January, almost the second, but I’m determined to get this post up before it’s too late. Today might even be too late, but I think it’s important to have something written for this past year, especially for this past year. Let’s get started.
I moved to New York
After a year and a half in San Francisco, both Jen and I heard the calling of the east coast loud and clear. Even with the beautiful weather, close proximity to the mountains and beaches, and unbelievably accessible fresh food, overall, it wasn’t for us. In February, we moved to New York where we feel at home more than ever. This is where I’m meant to be.
I joined Studiomates
Shortly after moving, I started renting a desk at Studiomates, which I would easily call our second home. The people in this co-working space are incredible. Working aside some of the makers I’ve looked up to for years still feels like a dream. The sense of community is so strong, I wouldn’t give up my spot for anything.
I taught my first class
Maryland Institute College of Art invited me to teach a 2 day workshop on anything I’d like. I had the students take an existing app and redesign it. The experience was fantastic and I would love to teach more. I’ll be back at MICA later this year to teach another class.
I quit my job
Two and a half years at Adobe sure taught me a lot, but most of all, my time there made it clear what I really wanted to do with my life. The urge to be on my own grew with every day and even though I enjoyed most of the projects I worked on, I constantly felt myself racing home to work on my side projects.
I started my own company
Rather than looking for a new job, I decided it was time to finally go out on my own and start a company, giving Destroy Today the focus it truly deserves. I couldn’t be happier with the decision. I’m consistently working with incredible designers, developers, and companies. And it’s easy to find passion for these projects because I believe in each one I take on. I also feel real ownership and responsibility. The drive to succeed is one of survival. I still have those moments of panic several times a week where I fear I’ll go broke, not have a next project, or burn out. I’ve come to realize this stress is just part of being on your own. It never fades.
I got married
After five and a half years of dating Jen, we tied the knot in our home state of Pennsylvania. Everything went as planned—she showed up and agreed to marry me. The day was perfect and married life couldn’t be better. She keeps me going and keeps me sane.
What’s next?
Very soon, I plan teux ship the product that’s been my life these past six months. I recently ditched Instgram with the hope of returning to real photography. I need to write more. I want to work on at least one off-the-computer project. I’d love to teach and speak more.
Let’s do this.
On the 15th, I became a married man. An inordinate amount of work went into this wedding to ensure that it matched us as a couple in every way, and luckily, everything went without a hitch. I’m a dev at heart, so in the planning, I took it upon myself to be creative where I could. I utilized several services and even experimented with some of the newer web tech out there. In this post, I’ll run through the ‘backend’ of our wedding and provide detail on exactly what went into it.
Planning
In planning the wedding, we used a variety of web services for organizing everything from guest lists to vendor options. Since this data needed to be seen by several people and incurred much overlap in editing, we relied heavily on Google Docs. Maintaining our guest list as a spreadsheet allowed us to keep everyone’s contact info in one place and in an easily exportable format.
For outlining website content and keeping a general list of ideas, we used my go-to list app, Workflowy. Its interface is so quick and easy, there’s absolutely no friction in jotting down thoughts. Sharing is a breeze, too.
To keep track of everything that had to be done, we used TeuxDeux. With its calendar interface, todos rollover to the current day if you don’t do them. This allows more flexibility while keeping the task in view, in case something unexpected comes up. Protip: when planning a wedding, something unexpected always comes up.
Save the Date
This year has been pretty active for us. In February, we moved across the country, back to the east coast, and a month later, both of us quit our jobs. Because of this, we weren’t as quick to send our ‘Save the Date’ as we had originally hoped. With only a few months before the big day, we opted for a less traditional approach.
I set up a single page website using vintage postcards Jen bought on eBay—each displaying a location where we lived. The website determined the viewer’s location from their IP address and displayed the corresponding postcard. With CSS3, the postcard flips when rolled over to show the wedding info. The postcard images are retina-supported and look especially nice on the latest iPad.
To get the word out, we used Mailchimp. Since we had a Google Docs spreadsheet of our guests, importing them into Mailchimp required only a click. Again, we used a scan of a vintage postcard as the email graphic with hand-drawn type by Jen.
RSVPs
After sending the ‘Save the Date’ as an email and website, we wanted to provide guests with something more tangible for the actual invite. Jen designed and illustrated our very own postcard that we screenprinted together. It provided guests with details about the big day and pointed them to our wedding website to RSVP.
We opted for an online approach for the RSVP because it requires the least amount of effort from the guest—they simply need to fill out a form. Personally, the thought of mailing anything these days feels like a hastle. We again used Mailchimp, but this time for their subscription form. By having them ‘subscribe’ to our wedding, we now had a new mailing list specifically for those who are able to make it. By cross-referencing this with our original list, we were easily able to see who didn’t RSVP and send them a follow up email.
Website
The website was built on Jekyll with HAML and SASS compiling to HTML and CSS, respectively. It provided guests with everything they needed to know about the wedding, including the pertinent information, like time and location, but also our backstory, hotel accommodations, and Philadelphia attractions. Jen even created a Pinterest board for suggested attire that I coded to fit within the site.
Photo Blog
For the day of the wedding, like any couple getting married, we wanted to capture every moment and every angle. We hired amazing photographers, but still wanted more. We knew that a fair amount of guests would take take their own photos and some would even use Instagram to post them. Originally, we planned to use a hashtag to auto-post to a Tumblr feed, but within days of the wedding, we discovered another couple had the same idea!
I looked for other methods that could give us more control and rediscovered IFTTT. With it, we could set up a trigger to watch for ‘likes’ from a specified account and post the corresponding photos to Tumblr. I created an Instagram account for the wedding, followed each guest with an account, and ‘liked’ the photos we wanted on the blog. At first, I thought this approach would be tedious, but it ended up being a great way of re-experiencing each day including and surrounding the wedding.
Wrapping Up
I hope this post was helpful to those either currently or eventually planning their wedding. With so many advancements in everyday technology, we should always look for ways to take advantage of them. Be creative and have fun. And let me know if you have any stories of your own.
This started as a post about all the ways you could use Alfred outside of just launching apps, but the post quickly became a book in size, so I decided to split it into a series. To prevent the series from becoming the only content on my blog, I’ll focus on the use-cases that are specific to my everyday workflow.
I constantly think about ways to improve my workflow. The main goal is to automate any menial tasks, so I can focus on the more important ones. One of the biggest lesson I’ve learned since starting my own business is that the value of time cannot be measured, and anything that saves time is well-worth the initial time invested.
I started analyzing my typical day-to-day. Are there any repetitive tasks soaking up my time? The first that came to mind was setting up my dev environment. With TeuxDeux, I need several Terminal tabs for the following processes:
-
rake server runs the web server, which serves the app and javascript tests.
-
rake guard cleans all public folders and auto-compiles all HAML, SASS, and Coffeescript files.
-
bundle exec autotest watches Ruby source folders and runs Ruby unit tests with RSpec.
-
bundle exec racksh enters the app’s console.
Sure, each process requires only a single-line command, but tally how long it takes each and every morning and you can see the effect. Aside from lost time, it’s a daily hurdle that must be done before I’m able to do any work, and it’s a task that requires no skills, unless you type it one-handed—that takes skills. Wouldn’t it be nice if this could all be done with a single command? Yes, that would be quite nice.
Luckily, Alfred gives its users the ability to write extensions—all sorts of extensions! For my case, I need to write an Applescript extension, so I click the ’+’ button in the bottom left of the Extensions tab in Preferences and select ‘Applescript.’
I set the title AND the icon because this is an extension I’ll see everyday and anything with an icon is legit.
From there, I describe the extension, set its keyword (something easy), and write the Applescript.
Applescript isn’t your everyday programming language, so I had to dig to find the correct syntax. The code starts by launching Terminal if it’s not already open or bringing it to the front if it is. I specify the commands I want for each tab and the script loops through them, opening a new tab for each one.
tell application "Terminal"
activate
set command_list to {"rake server", "rake guard", "bundle exec autotest", "bundle exec racksh", "subl ."}
repeat with the_command in command_list
tell application "System Events" to tell process "Terminal" to keystroke "t" using command down
do script with command "cd ~/projects/teuxdeux;" & the_command in selected tab of the front window
end repeat
end tell
That’s all. By setting aside 10 minutes one morning, I can now start writing code sooner and get to what really matters. That makes think—what else could I do in a short period of time to greatly improve my workflow? The posts to follow will continue this discussion. If you have tricks of your own, feel free to share them in the comments.
Today, I start as lead developer on TeuxDeux, a todo app by swissmiss and Fictive Kin. Since its release, I’ve been an avid user, relying heavily on TeuxDeux for more than just todos, so I’m ecstatic for the opportunity to help shape its future. First on the agenda is to rewrite it for the modern web. From there, we’re going to take TeuxDeux to the next level. Sign up now to be the first to hear about updates.
In the past year, I shifted interests from the desktop to the web. I’m really drawn to apps that can be accessed from any device with a browser. I have a history with HTML, CSS, Flash and PHP, so I’m familiar with the space, but only in a presentation sense—I’ve made websites, but not web apps. I dove head-first into Rails and instantly fell in love, but the immediate response I knew with Flash was replaced with page loads. Because of this, I turned to Javascript.
Like the new kid at school, I didn’t know who was who in regard to frameworks. I looked around and saw mentions of Backbone.js everywhere, so I assumed it was the standard. After several months, however, I realized it’s not for me—Backbone.js lacks a clear direction of use. Every tutorial I read used a different structure, and it almost seemed too easy to disregard proven design patterns.
Enter Spine.js. I spent a night just reading through its guides and examining its demo apps. Everything I saw just looked right. That night, I wore a big smile and even had trouble sleeping because I couldn’t wait to start using it. What made me so excited?—these 10 things:
-
A Clear Architecture
Spine.js follows MVC (model-view-controller, for those who should take a moment to learn MVC). All the apps I’ve written follow the MVC architecture, so I immediately know how to structure my app using Spine.js. I also feel a sense of familiarity off the bat. There’s no question of which class does what or where each class lives.
-
Models are Models
Backbone.js has models, but it’s awkward because there are also collections—essentially an array of models that can also query an API and populate itself with the results. Spine.js models are very similar to Rails models. A model can be instantiated to represent a record, but it also has class-level methods for retrieving records from the API. These methods return the results instead of populating an array, so we don’t have to contemplate where the class lives, as one would with collections. And because collections are instances, many of the examples I’ve seen treat them as singletons. As a result, those learning Backbone.js and following these examples are also learning how to write untestable code.
-
Spine.app
While using Backbone.js, I found myself copy/pasting code every time I created a new class. I missed the generators I grew accustomed to in Rails. With a single command, I could generate the new class along with its spec, based on a template—this adds years to a dev’s life. “Write Backbone.js generators” was on my todo list for weeks, but I never got around to it.
Spine.app generates files. With a single line, I can create a class and its spec, just like in Rails. Hell, I can even generate a new app with one command.
-
Dynamic Records
This one is just crazy black magic, but it solves a problem I faced with Backbone.js. Let’s say you fetched a record in one view of the app. Then you fetch and update that same record in a different view. In Spine.js, both records will update. You don’t have to worry about keeping them in sync. The moment I read about this, a single tear rolled down my cheek.
-
Elements Hash
With Backbone.js, I constantly found myself manually assigning variables to nested elements in every view’s render method, repeating the same code for each element—that’s a lot of boilerplate. In Spine.js, there’s an ‘elements’ hash. The keys are selectors and the values are variable names. Just like the ‘events’ hash in Backbone.js, all your elements are mapped—clearly and easily.
-
The Release Method
In my Flash days, optimization was a key to survival. If ever I forgot to remove a single event listener, my app would leak memory like… a poorly maintained app. Because of this, every class I wrote included a method to nullify all references and remove all event listeners. Spine.js has this built in. Sold.
-
Routing Lives in the Controller
There is no Router class in Spine.js. This functionality is part of the Controller class where it belongs. In any controller, I can navigate to a new location and react to this new location. Other controllers can react to this new location as well. Now there’s no temptation to create a router singleton.
-
Model Adapters
By default, Spine.js saves models in memory, but there are two adapters that can be applied to any model class—Ajax and Local. By simply extending either of these adapters, your data can live in a remote database or even locally using HTML5’s local storage API. All this functionality is a matter of one line of code.
-
Get a Model from its HTML Element
This is another issue I faced with Backbone.js. I could instantiate a view and tie a model to it, but if I would ever need to reference that data without access to the view instance, I’d be out of luck. Spine.js provides access to an element’s model through a jQuery plugin. Just call the ‘data’ method on the element and you have your model.
-
Logging
Spine.js comes equipped with a nice little convenience module for logging. In any controller, you can call the log method and it will write to the console with a set prefix. You can then toggle whether or not to trace the logs without removing them.
In Conclusion
Now, this list is why I switched to Spine.js. Some apps might be better suited for Backbone.js, or any other JS framework. If you’re researching different frameworks, definitely take a look at all of them. Do your due dilligence. Make sure whichever framework you choose has a clear example and is free from gotchas. You don’t want to find yourself halfway through development and questioning the framework.
Resources
By default, Spine.app generates an app with Jasmine as its testing framework. I much prefer Mocha.js, so I forked Spine.app to add Mocha.js support. It also includes a HAML compiler and I have plans to include SASS as well as other helpers.
Here are all my javascript bookmarks from my recent high-dive into the language. They consist of links to articles, libraries, and answered StackOverflow questions. Hopefully, they will get a few of you out of a pickle.
I plan to write more about my Spine.js discoveries over the coming months, so keep an eye out if you’re interested.
thumbnail from OrthoIndy
When I left Adobe, I returned my company laptop. Since then, I’ve been test-driving a borrowed Macbook Air from fellow Studiomate Skylar Challand (Canadians are so nice!). While using the laptop, I realized something strange—even though it lacks a disc drive, it still has an eject key. This is understandable because of the optional USB superdrive, but the last time I actually used a disc drive was to burn the MP3s I downloaded from Limewire.
Half-joking, I tweeted this:
Before the tweet could load, I knew I had to follow through. And within 15 minutes, I had a solution.
Disclaimer: There are probably dozens of easier ways to do this, but this is the first way that came to mind.
-
Download KeyRemap4MacBook
KeyRemap4MacBook is a free preference pane app. I would describe it, but it’s one of those apps that skips all the cutesy names and tells you exactly what it does.
-
Map the eject key to F13
Go to the KeyRemap4MacBook preference pane, search for ‘eject f13’ and check its box. I use F13 because, on my computer at least, it isn’t mapped to anything. 
-
Download rimshot MP3 from instantrimshot.com
If you haven’t been to instantrimshot.com, you aren’t telling enough jokes in the workplace. I ended up scrubbing the HTML to find the MP3 file, but you can just download it here.
-
Create Alfred extension to play MP3 using afplay
I skipped writing a step for downloading Alfred and purchasing the Powerpack because I assume you already have them. If not, 5 points taken from Gryffindor! Open the preferences and under ‘Extensions’, create a shell script as seen below. Ever since Leopard, OSX comes bundled with a binary called ‘afplay’ that lets you play audio files from the command line. Incredibly useful in this case. 
-
Create global hotkey for extension
Lastly, go to the ‘Hotkeys’ tab and create a global hotkey for your shell script and map it to F13. 
Try it out and let me know how it goes!
Early this year, my brother Ben interviewed me as part of a series he’s working on. I talk about design, why I build, and my thoughts on collaboration. Ben recently started his own company as well, Hallman Productions, providing services for video recording and editing.
In case you were wondering about the birdhouse and plant, Ben interviewed me at our parents’ house in PA while I was home for a visit. And no, a tiny bird does not live in that birdhouse. I wish.
As mentioned in my previous post, I recently left Adobe. I won’t go into detail about why I left—I just knew it was time. Leading up to my last day, I met with several companies. I figured my next steps would be to join a new company and see where it leads me.
All of them seemed like great opportunities. It was enlightening to talk to people about their future while I was trying to figure out mine. When asked for input on what they should do next, I surprisingly had no problem sharing my thoughts. This on-the-spot kind of thinking allowed me to come up with ideas I never considered, looking years into the future instead of just months.
I showed them my work, speaking thoroughly about the process and sharing the many stories tied to each app. When asked about specific UX innovations in my apps, I turned to DestroyFlickr. I recalled it having a handful of unique features I was really proud of.
Revisiting the app left me a bit nostalgic. I could remember everything about the time I wrote it. I remembered being so excited to work on it I couldn’t sleep. I remembered knowing nothing about designing an app besides what felt right. I remembered celebrating each time I got a new user—reaching 30 was a huge deal.
At that moment, I fell in love with my side projects all over again. I realized I would still work on them no matter where I ended up—they are a part of me. Without a doubt, these side projects are my best work. They are what I’m best known for. They are my passion in life.
Then why are they just side projects?
The decision has never been more clear. It’s time to destroy today, every day. I will work for myself, spending every waking moment just building. I will collaborate with other builders, creating partnerships out of the want to make our ideas real. I will share everything I learn—writing articles and teaching workshops. Whether I’m designing, developing, or both, I will ship quality products. This is what I need to do. I’m ready.
After almost three years with Adobe, it’s time for me to move on. I was first a developer, then a designer, and now I need to be both. I wish the best for my fellow Adobe-ans and look forward to their future work. As for me, that’s for another post. Stay tuned.
-
1
-
2
-
3
-
4
-
5
-
6
