How To Put Creative Work First

by Jess Brown

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:

Foundation Menu In Refinery

by Jess Brown

The sign of a good open source platform is when you want to do something outside the box, how easy is it to modify. Well Rails and Ruby are particularly good candidates and Refinery doesn't hold them back.

I was recently building a Refinery CMS and was using Zurb Foundation for the front end framework. If you've used Foundation before, you'll know that the top menu requires specific markup and unlike many of the other components, doesn't have mixins that you can use to implement it.

My menu needed to look something like this:

<section class="top-bar-section">
    <!-- Right Nav Section -->
    <ul class="right">
      <li class="active"><a href="#">Right Button Active</a></li>
      <li class="has-dropdown">
        <a href="#">Right Button with Dropdown</a>
        <ul class="dropdown">
          <li><a href="#">First link in dropdown</a></li>
        </ul>
      </li>
    </ul>
</section>

The Refinery menu html looked like this:

<nav class="menu clearfix" id="menu">
  <ul>
    <li class="selected first"><a href="/">Home</a></li>
    <li class="last"><a href="/about">About</a></li>
  </ul>
</nav>

In the past, Refinery had used view partials to implement the menu, but in an effort to clean the code up and make the menu more efficient, they changed it to a presenter. Now Refinery uses this one call from a view to to implement the menu:

<%= Refinery::Pages::MenuPresenter.new(refinery_menu_pages, self).to_html %>

I didn't immediately know the best way to solve this, so I fired off a quick Github comment and one of the primary maintainers immediately wrote me back (testament to their responsiveness). He said, just subclass it and overwrite the methods.

That actually turns out easier than it sounds. Just create a new file in app/models/foundation_menu.rb.

class FoundationMenu < Refinery::Pages::MenuPresenter
end

Now we can start overwriting the methods we need. The first is the render menu method:

class FoundationMenu < Refinery::Pages::MenuPresenter
  def render_menu(items)
    content_tag(:section, :id => "nav", :class => 'top-bar-section') do
      render_menu_items(items)
    end
  end
end

Here's the diff on that method:

Click to enlarge

×

As you can see, we're just slightly changing the methods. Here we changed the content_tag to be a section instead of a nav, the id to be nav instead of default one and the class to top-bar-section

There's a few more changes that need to be made and one addition to get the dropdown menu working. I'll link to it here so you can use it if you like. Refinery Foundation Menu

Once you have your subclassed menu presenter in place, no you just need to link it up in your view:

# app/views/refinery/_header.html.erb
<div class="row">
  <div class="columns large-12">
    <nav class="top-bar" data-topbar>
      <ul class="title-area">
        <li class="name">
          <%= link_to image_tag( "logo.jpg" ), refinery.root_path, width: 100, height: 75 %>
        </li>
        <li class="toggle-topbar menu-icon"><a href="#">Menu</a></li>
      </ul>
      <% menu = FoundationMenu.new(refinery_menu_pages, self) %>
      <% menu.max_depth = 1 %>
      <%= menu.to_html %>
    </nav>
  </div>
</div>

It'd probably be cleaner to extract this out to a heleper or in ApplicationController

Having a system that is flexible and easy to extend and override is awesome for a programmer. I've built quite a few projects using Refinery CMS and I continue to be happy with that I can accomplish.

Don't Be In A Rush To Be A Specialist

by Jess Brown

Specialization

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 end developers specialize in SASS or Javascript frameworks. Some rails 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:

Slide by Jared Spool Slide from Jared's Talk

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:

Slide by Jared Spool Slide from Jared's Talk

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 hand surgery.

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 labor.

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 ownership.

He also makes the point that good programmers are good programmers and good designers are good designers...regardless of what technology they're using.

Summary

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 scope.

You Can Blog Too!

by Jess Brown

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!

Update:

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 !

Rails For Beginners

by Jess Brown

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 course :-).

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 specific skills (HTML/CSS, Javascript, DB Admin, etc) like I had.

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.

Git

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

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.

Local Setup

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.

Ruby

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 beginning.

Command Line

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.

Console

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.

Testing

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 else.

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.

Rails

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

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.

The Magic

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.

MVC

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.

Summary

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 valueless commodity.

Navigation