Last year I went on vacation to Okaloosa Island. Going on vacation for
a small business owner is tough. I usually get Scott to check my email
for me, handle anything pressing, and respond to others telling them I'm
out of town. On this trip though, he was going to be out of town too.
So I decided I'd check email once in the morning and once around lunch.
To my surprise, I was able to 1) quickly process email, and 2) no one
really seemed to notice I "didn't respond right away".
Creative work first
I recently read Manage Your Day-to-Day: Build Your Routine, Find Your
Focus, and Sharpen Your Creative Mind. Close to the beginning
of the book, I picked up on a quote:
The single most important change you can make in your working habits
is to switch to creative work first, reactive work second. This means
blocking off a large chunk of time every day for creative work on your
own priorities, with the phone and e-mail off.
That coincides with a tip read a long time ago that suggested to never
check email first thing in the morning.
Email is definitely reactive work. You can sit around for hours answering email
and getting distracted from your creative work.
How to turn email off
The problem with ignoring email is that I need my email to work. Clients
send me copy, images, instructions, etc and I need access to that. But
if I go to my inbox and see new messages, it's too tempting to get
distracted. I recently found a tool for gmail to turn email off. It's
called Inbox Pause. Inbox pause helps by pausing your new incoming
email. It does this by adding a hidden label to the email. Your email
will be delivered to the inbox in one of two ways. You can manually
unpause your inbox, or you an setup a schedule for emails to be
delivered. I use the latter so I can stick to a schedule of blocking off
time for creative work and blocking off time for email.
My email arrives at 12:30p so I can check either before or after I get
back from lunch and at 4:30p so I can check at the end of the day and
make sure there's nothing urgent to do before going home and so I can
plan accordingly for the following day.
This process has been working for me so far ( I'm happy enough to write a
blog post about it ). I can focus on my creative work, I can focus on
knocking out email when I'm done, and I'm not distracted by email in the
evening when I should be spending time with my family.
I know there's thousands of strategies to handling email so choose your
flavor, but I'd definitely recommend giving this one a try. Here's a
short clip about it:
Over the course of several years, I've heard a lot about becoming a
specialist in my industry (web development). Many people focus on
design, some focus on front-end development, some focus on backend
frameworks. Many people even take that further. Some designers only
design for iOS and some only for the entertainment industry. Some front
developers specialize in big data or geospatial intelligence.
What do I specialize in?
This March will be my 6th year in business. I've been trying to redesign
my website and rewrite copy and the message I want people to know about
what I do. It's got me thinking: Shouldn't I be a specialist?
UX Thursday: The Rise of the...
I was listening to Jared Spool speak at a recent event called UX
Thursday. He made some great points about the intent of design
throughout the talk, but some of the things he said towards the end
really resonated with me. Let me give you a brief background.
The title of the talk was It's a great time to be a designer, and
towards the end he said that after all these years of trying to
convince companies that design matters, they were finally listening.
But now suddenly, we (as designers) have to back up the talk. He read
an old Chinese proverb: "Be careful what you ask for, lest it become so".
The problem now is finding good designers. Jared's company does
research and helps companies attract and retain good designers. During a
recent study, they asked many design team managers: What skills are
found in the best design teams? What he got back was quite a large list
of skills. Then trying to narrow the scope, he asked, What separates
out the best designers? He was expecting a single skill or
characteristic that set apart great designers from others (remember his
goal is to find the best designers ...if he could hone in on this one
important skill, he'd be able to seek them out and recommend them for
hire). Well, what he got back was this:
When I saw this, I remember being overwhelmed and thinking, if I was
looking for a UX job, I might just get up and walk out, because I'll
never be great at all those things.
Then Jared presented his thesis of the presentation: The Rise of The
UX Generalist. Let's explore some terms:
He wasn't saying that being a specialist was bad, but being a
compartmentalist was. Also, to be a specialist, you need to first be a
generalist. He used an analogy of being a hand surgeon and showed how
this particular hand surgeon was a general surgeon for many years before
he became a specialist. Being a specialist didn't mean he wasn't good at
any of the other types of surgery, it just meant he was a better at
So what's the moral? For me it was you can't choose to
not be good at many things and only try to focus on one
speciality...they're all to intertwined. I have a feeling there are a
lot of compartmentalist designers and developers out there, for it's
easy to ignore one some areas and only focus on a few. The best
will be good at many skills, and some who have been well rounded for a
long time may become a specialist over time.
Seth Godin says be a...
I've been rereading Linchpin. If you're not familiar with the book,
it's about breaking out of a factory mindset where jobs are broken down
into specific tasks and become part of an assembly line in a factory.
Instead he seeks to introduce us to the Linchpin. A Linchpin is
someone who can bring it together and make a difference, someone who
thinks outside the box, an artist: someone with a genius for finding a
new answer, a new connection, or a new way of getting things done.
The point of the book is that great work doesn't come from perfection
and it certainly doesn't come from being average, but it comes from
solving problems that people haven't predicted and for which no job
description exists. He talks about Marissa Mayer:
Marissa has created billions of dollars' worth of value in her time at
Google. Yet she's not the key brain in the programming department,
nor is she responsible for finance or even public relations. Marissa
is a Linchpin. She applies artistic judgement combined with emotional
Marissa led the way in Google's now-cherished user interface. Is/was she
a specialist? Here's an excerpt from her wikipedia page:
During her 13 years with the company, she was an engineer, designer,
product manager and executive. Mayer held key roles in Google Search,
Google Images, Google News, Google Maps, Google Books, Google Product
Search, Google Toolbar, iGoogle, and Gmail. She also oversaw the
layout of Google's well-known, unadorned search homepage. In
her final years with Google, she was Vice President of Local, Maps,
and Location Services and, before that, vice president of search
products and user experience.
Interesting, she about did it all. Now she's CEO of Yahoo!
37Signals (oops, I mean Basecamp) Specializes in...
DHH wrote a blog post on specialization recently where he makes the point
that too much specialization is a bad thing.
Specialization might give you a temporary boost in productivity, but
it comes at the expense of overall functional cohesion and shared
He also makes the point that good programmers are good programmers and
good designers are good designers...regardless of what technology
I'm not going to be too eager to specialize in anything just yet. I
enjoy helping clients and offering them an opinion that that isn't
limited to one technology. Of course, you can't be everything to
everybody, so there is some relativity here, but in my arena, it's being
able to take a web app from start to finish: concept, planning, project
management, design, development, deployment and support. One of my
favorite parts of my job is learning, improving and exploring.
Specialization doesn't eliminate that, but it definitely narrows the
This evening I attended a local design meetup called
TransformAthens. The topic was Blogging and Your Future and the
presenter was John Saddington. John is a well known proponent for
blogging and was there to encourage us to either start a blog or keep one going.
I recently started blogging and have found it to be much easier
than I figured it would be. First I worried, What would I write
about? I didn't realize this at first, but the more I learn, the more I
realize that a lot of blogging is simply about sharing your experiences.
As a rails and web developer, I have learning experiences every day.
So I decided that whenever I learn something new, I'll blog
about it. So anytime now that I have to look something up or
research an issue, I'll open up Evernote and make a few notes, save the
urls or code snippets I used, and save it for later on. Then, at a set
aside time, I'll write a blog post about it. Sometimes, if it's going
to be a quick post, I'll just stop working on the client work and crank
out the blog. I've been doing that for about the past month.
Ok, you're writing, but will anyone read it?
Will it help anyone?
The other day, I recorded a screencast of me setting up a refinery cms
rails app and deploying to heroku and published it to my blog. A
few days later, I had the idea to send the post to Peter Cooper who
publishes a popular Ruby newsletter called Ruby
Weekly. I didn't think there was any way he'd
publish it, but today Ruby Weekly was released and I about jumped
through the roof when I saw he published a link to my post.
So there you have it...what John says is true, you really have no
excuse. If you can hit the publish button, you can start and maintain a
blog and it'll reward you.
I hope my small experience of a quick success story of starting a blog,
actually publishing some posts and getting it picked up by a popular
industry newsletter helps. I'm a believer!
Matt Smith posted a much better recap of the meetup and listed some
of the major points John made in his talk. Go check it out !
I recently read a tweet by Andy Lindeman asking:
I'm not about to try and answer that question, but it does resonate with
something that I've been thinking about for some time: all the things I
had to learn to learn rails.
I started my company in 2008. I'd built a few websites on the side,
knew a little HTML, barely CSS, a few PHP functions and phpMyAdmin
(though couldn't say I knew anything of MySQL). I had no formal training
in any web technologies and majored in Finance (I did have one CS
That first year I went through a huge learning curve and started
getting much better and smarter about web development. I believe it was
sometime in 2009 when I first heard about Ruby on Rails.
I read a few tutorials, at first but didn't really get started on my
first real app, a personal project, until March of 2010.
If I had to summarize the difference in learning rails vs learning php,
or css, or any of the other technologies I had previously learned, it'd
be this: to learn rails is to learn a new craft called software
development. It's the difference in learning how to hammer a nail vs
how to design, architect and build a house.
People struggle the most when learning rails (actually substitute any other
software development practice here: web app development, iOS, etc) when
they either come from no technical background or they only have a few
Here are the things I had to learn and struggle with as a begging rails
developer. Many of which you'll see are not related to rails itself so
much, but software development in general.
Before learning rails, I had no prior knowledge of Git or any other
version control systems. FTP was the name of the game and if you were
going to make a change to a file that you might not want to keep, you
just back a quick backup, like
index.php.bk or be confident in
whatever backup process you were using.
Though the basics are pretty straightforward (git add, git commit), Git
is very complicated and I'm still new tricks today.
Deployment with a static HTML site or PHP was/is so simple. A LAMP stack
was the norm for most of my client's hosting services. The only hiccup
would come when the client was on a windows server and my PHP mail
script wouldn't work!
Rails has always had a difficult past with deployment and hosting.
Luckily, I missed the mongrel era, but I really struggled with my first
VPS and Passenger.
Fortunately, with services like Heroku and Engine Yard, this is becoming
less and less of an issue, but even experts still struggle with
deployment. I'm thinking of you asset pipeline and dependency issues.
In a close category to deployment, setting up a local machine is
something that has to be learned. Rails strongly encourages developers to
develop locally, and when everything is good, deploy confidently to
production. Tools like homebrew and rvm|rbenv|chruby, rubygems and
bundler have made this process WAY easier over the last few years,
but if you're new to web development and/or rails, you have to learn how
to use these tools too.
If you're coming from another language (or no language at all) I can't
really imagine a better language to start learning than Ruby. It' so
expressive and developer friendly...it's joyful to learn.
Coming to Ruby to PHP wasn't necessarily hard, but it just takes time to
learn things and get in the flow of how thing work. Little things like
learning how to read the documentation, figuring out how to debug error
messages, style, and how to phrase questions and bugs are as much or
more a part of learning the language as anything.
Objects, Classes, Modules, Inheritance, OH My!
As I stated earlier, I didn't have have a CS background and my PHP
programming skills were sub par. Using thing like Classes, Inheritance,
Namespacing were all foreign principles to me. I knew some basics like
functions, arrays, loops, etc, but Objects really blew my mind in the
While I was in college training to be a financier, computers always were
my hobby. I'd collect family member's old computers and figure out how
to get Linux or FreeBSD on them. So, fortunately, I was familiar with the
command line. Not that I was ever slinging bash or anything, but I knew
the basics of navigation and how to run commands. But for some, this is
something else they have to spend time learning.
Similar to the command line, the console was a new principal to me. To
test if a piece of PHP code works, you just upload it to the production,
server, right? The console is such a big help, I almost don't want to
list it as a "thing you have to learn before you learn rails", but it is
another concept you have to figure out.
Text Editor or IDE
Before I started my quest to learn rails, I used Dreamweaver. A lot of
people bash it, but I still believe it's a good tool to start front end
web development on. However, it didn't take very long for me to realize
that it wasn't going to be a good tool to code Ruby. I started looking
into TextMate and Vim. I was so fascinated with Vim, that I figured if
I was going to have to learn something new, I might as well learn Vim.
Learning Vim is a journey in of itself in addition to learning rails. I
believe most beginners coming to rails are going to have to learn a new
IDE or a new text editor.
From all my reading and everything I had heard, I knew testing was a
must. I'd been burned in the past by making small changes to a CMS or
shopping cart only to realize later that my change had broken something
Looking back on it, I can't really pick out any one pain point, but I
just really struggled with it. Many times I'd know what I wanted to
test, but just not know how to write it up. My instinct was to just fire
up the browser and visibly test it.
Testing is one of the more obivous things that beginners struggle with,
but it's one of the things that separate the beginner from the advanced.
Finally, alfter all that, we get to the thing we've wanted to learn (I
realize you can possibly skip some steps like deployment and testing).
I never really thinking rails was tough to learn, but it's just a giant
framework with tons of convienent helpers. It just takes time to learn
it. Similar to what I said about Ruby, you have to get used to the
error handling, docs, etc, but then there's a few other categories...
Conventions are awesome after you learn/know the convention, but before
you learn the convention, it's just another unknown. I think all in
all, the majority of conventions in rails are a big help. It's really
nice to see the same directory layouts in tutorials and to see similar
controller actions in beginner app as in an advanced app.
The Rails Way
It might have just been me, but I was so concerned about doing things
the right way, that I'd waste hours trying to figure something out that
I knew how to do, but didn't think it would have been "The Rails Way". I
suppose there's a balance that needs to be made. Sometimes it's
important to learn things the right way the first time and sometimes it
could be better to just do it and refactor later.
It's been discussed, but a lot of the magic behind rails is
wonderful and some of it is harmful. A lot of times you don't know why
or how something works, but you see others do it or find it in the docs
and it gets used. On reply to the tweet by @mislav said
Rails is awful for beginners, especially those who don’t understand
the set of problems that a framework like this solves for you
The "magic" is a part of that disguise.
A MVC concept was was unfamiliar with to me. I didn't always understand
the role of the controller, model, views, helpers, etc. What should go
where? I'm not sure if routing really falls under MVC, but that was a
confusing concept too. In PHP, you just upload the file and it works!
DSL's and Gems
Rails is one big DSL and typically developing a rails application
involves learning many other DSL for necessary gems. Devise,
formtastic/simple_form, bootstrap/foundation, slim/haml, state_machine,
cancan, kaminari, carrierwave, fog, delayed_job/sidekiq are just a few
common gems in my Gemfiles. All of them and more have to be learned.
I hope that the people teaching rails will read this and understand a
little more about what a beginner is thinking. I wish I'd have written
this in the early stages so I'd have a fresher memory of the struggles.
I'm sure teachers and instructors have their own memories and
reflections of when they first learned too, but hopefully another
perspective will help out.
Lastly, if you're new to rails or going through the learning process
now, I'd say don't get discouraged. If you really want to become a good
rails developer, it'll take time, experience and dedication. It's not
easy and you don't want it to be easy. If it was easy, anyone could
pick it up and do it, which would make being a rails developer a