Go check it out

Let’s talk about that work/life balance thing

Most of this discussion always seem to revolve around the idea of a work/life balance. The basic idea is to keep yourself sane. Don’t abandon your real life for your work. That makes sense, until people start attaching hours to it. I’ve had discussions with people where they try and argue to me that 40 hour work weeks keep them balanced. But I have to wonder, where does that magical number 40 come from?

The fallacy here is that people are thinking in black and white terms of “work” and “life.” I never really understood that, and I think I’ve gotten to a point in my life where I can see why: it’s a bunch of bullshit that employers made up to promote 40 hour work weeks. If you really think that there is a certain number of hours you can work a week to balance your life, you’re doing it wrong. So let’s ditch this idea of a work/life balance, because it just doesn’t make sense.

It’s about creating a creative environment in your life

It’s just that simple. If you’re in the creative field, you need to make sure your life promotes a creative environment. There isn’t one catch-all formula to do this. There isn’t a number of hours you need to work. You just need to experiment and find out what works for you. What I will do is try and offer some advice.

Find your passion in life and try to make money from it

If you hate your job, it’s unlikely that you’ll be successful in fostering a creative environment. Try your best to fix this. Find out what you’re good at, and try to make money from it. You’ll be producing better (more valuable) work and enjoying life more.

Explore projects that are explicitly not for profit

Money taints things, there is no denying this. So I suggest to find an outlet that you purposefully can’t/don’t make money from to help exercise your brain. That might mean creating websites, making music, or hacking on an epic perl script that no one but yourself will use. It doesn’t have to be something different from your work — it just has to be separated from your work. Something you can change or destroy without worrying about what others think.

Stop working if you’re producing crap

The only thing worse than being unproductive at work is forcing false productivity. If you find yourself at your desk and you can’t come up with anything useful, just stop trying. Leave your desk and go do something else. Maybe for a few hours, maybe for a week, maybe for a year.

Accept that there is no way you can be productive for 40 hours a week

The 40 hour work week is completely unsustainable. Human beings are not meant to sit down and really focus for 40 hours a week, 50 weeks a year. Our brains can’t handle it. I’m sure startup founders will come in here exclaiming how they’ve been working 100 hour work weeks for 6 months now and every hour was well spent. They’re lying.

Your brain needs to purposefully not think in order to come up with creative ideas. That might mean relaxing to your favorite book or movie while your subconscious attacks your latest project. You’re not working in the strict sense–but you’re getting work done.

That’s not to say you can’t have weeks where you get hundreds of hours of work done. But in my experience, after a week like that, I need another week or two to decompress.

Focus on what matters

My goal with this post is to hopefully get people to stop thinking in hours. Start focusing on making great things. It’s about the things you produce, not the hours required to make them.

Once you realize you’ve been focused on the wrong metric I think you’ll realize arguing about a work/life balance is just ridiculous. Spend time on your life. Spend time on your work. But always strive to do better. That’s all you need.

A brief look at the past couple years

The past couple of years have been a crazy blur of projects for me. Most of what I did for ENTP was for [redacted], so you won’t be seeing most of what I did, but I thought I’d spend a few minutes to archive (for my own good) some of the public-facing projects I completed.

Tender

By in large, the biggest project I worked on ENTP was Tender — and I’ll be honest, it’s going to hurt to let this go. Tender was my baby, and I did all of the IA, design and front-end work for the site as well as some marketing and analytical work. The shining side of that tunnel is that of course GitHub uses Tender for their support, so I’ll at least get to use it and see how ENTP shapes the product.

Lighthouse iPhone

Designing an iPhone optimized interface was one of my first projects at ENTP. It doesn’t benefit from any of the OS 2.0+ features (HTML5, CSS Animations, Etc) since the code was created before these came along, but it gets the job done. It was a great exploration in turning a complicated interface and trimming it down to the bare essentials.

ENTP.com

I designed this in collaboration with Justin Palmer when ENTP decided they needed a new site. It’s got a few interesting features (like pulling in our current GitHub projects on demand in the footer), but it’s mostly just a brochure site for the agency.

Hoth

Hoth is ENTP’s blog. This design accompanied the new ENTP.com design and added in a bit of tumble-like functionality to the templates.

On to the next chapter

So now I enter the third dream job I’ve had in the 4 years since I graduated college (none of which have been slightly related to my degree). I’ll be diving into a design/front-end role for the team and help clean up and take the product to the next level.

I’ll see ya’ll at the next GitHub drinkup.

The state of startups

Call it “Valley Culture” or however the hipsters wants to spin it — there is a definite attitude of Entrepreneurship in California. I’ve lived around it my whole life. People are itching to start companies so bad that they get VCs to give them extraordinary amounts of money for really dumb ideas. I mean, really dumb ideas. Ideas that never had a hope in the world of making money, let alone becoming popular.

My point being: if we can get VCs to put up millions of dollars for practically any idea, why don’t we see more lean journalistic startups? Nothing fancy, just some (good) reporters, editors, and a small syndication (web) team. Editors & reporters generally get paid shit, and you wouldn’t need more than 2-3 tech people to support a couple dozen reporters with today’s technology — so a few million would go a long way.

It’s not the news that’s dying, it’s the news organization

Increasingly I’ve been hearing the same mantra from smart people around the web: It’s not the news that’s the problem, it’s the newsroom. In any modern newspaper, the people producing content (editors & reporters) are a small fraction of the costs. One of my favorite quotes on the subject comes from Mr Gruber:

The question these companies should be asking is, “How do we keep reporting and publishing good content?” Instead, though, they’re asking “How do we keep making enough money to support our existing management and advertising divisions?” It’s dinosaurs and mammals.

The truth is, people are hungry for news. And there’s plenty of money to be made. I don’t see TechCrunch or Mashable hurting for money. And they’re out there just producing bottom-of-the-barrel reporting. Could you imagine how much money someone would make if they had a TechCrunch style news organization with real reporters? People might even start trusting them as a source of information.

So where are the startups?

Maybe it’s me, but the answer seems so clear in my head. We have thousands of unemployed journalists. Good journalists. We have VCs ready to hand out money for a shit sandwich. We have a proven business model. Why don’t I see a flurry of journalistic startups? Get rid of the cruft of the newsroom, give power to the reporters and content producers.

Stop trying trying to grasp onto idiotic ideas like “social news” or stabbing blindly at twitter in hopes of saving an archaic organizational structure. People aren’t buying printed newspapers? Stop printing them. People only want to read their news online? Let them read it online.

America needs to stop concentrating on how to save our dying industries and start concentrating on how to create the next booming industries. Isn’t that what the American dream is all about, anyways?

So instead, what I did was hack together a quick referral script using Javascript to track where people came from and add that to a field on the Site model (each install of Tender is considered a ‘Site’). The Javascript (in MooTools):

var Tracker = new Class({
  tracker: null,

  initialize: function(){
    this.initCookie();
    this.updateCookie();
    this.markLinks();

    var field = $('site_referral');
    if (field){
      field.value = this.tracker;
    }
  },

  initCookie: function(){
    this.tracker = Cookie.read('tracker');
    if (!this.tracker || this.tracker == "") this.setTracker();
  },

  // Order of precidence
  // 1. ?source= from in the URL
  // 2. ?utm_campaign= in the URL
  // 3. Referrer / Direct
  setTracker: function(){
    var final_source = document.referrer ? document.referrer : "direct";
    var args = $get();
    if (args.utm_campaign && args.utm_campaign.trim() != '') final_source = args.utm_campaign;
    if (args.source && args.source.trim() != '') final_source = args.source;
    Cookie.write('tracker', final_source, {duration:1});
    this.tracker = final_source;
  },

  // Updates the cookie if another ?source or ?utm_campiagn is set
  updateCookie: function(){
    var final_source = null;
    var args = $get();
    if (args.utm_campaign && args.utm_campaign.trim() != '') final_source = args.utm_campaign;
    if (args.source && args.source.trim() != '') final_source = args.source;
    if (final_source){
      Cookie.write('tracker', final_source, {duration:1});
      this.tracker = final_source;
    }
  },

  markLinks: function(){
    $$('a.signup-link').each(function(el){
      el.href += "?source=" + this.tracker;
    }, this);
  }
});

function $get(key,url){  
   if(arguments.length < 2) url =location.href;  
   if(arguments.length > 0 && key != ""){  
       if(key == "#"){  
            var regex = new RegExp("[#]([^$]*)");  
        } else if(key == "?"){  
            var regex = new RegExp("[?]([^#$]*)");  
        } else {  
            var regex = new RegExp("[?&]"+key+"=([^&#]*)");  
        }  
        var results = regex.exec(url);  
        return (results == null )? "" : results[1];  
    } else {  
        url = url.split("?");  
        var results = {};  
            if(url.length > 1){  
                url = url[1].split("#");  
                if(url.length > 1) results["hash"] = url[1];  
                url[0].split("&").each(function(item,index){  
                    item = item.split("=");  
                    results[item[0]] = item[1];  
                });  
            }  
        return results;  
    }  
}

The way this works is the following:

1. If someone comes with ?source=something or ?utm_campain=something (a Google Analytics keyword), it stores that value in a cookie called ‘tracker’
2. If no ?source or ?utm_campaign can be found, it stores the referrer
3. If no referrer can be found, it stores the value ‘direct’
4. Every URL that has the class signup-link gets ?source=trackerhere appended, so that the referral gets tracked over to our setup domain.
5. If it finds a field with the id of site_referral (the rails default for Site#referral field), it sets that value to whatever is stored in the tracker cookie.

Now when people sign up, I can see where they came from in the admin panel:

Burndown is a simple little app that adds a new dimension to Lighthouse – Time. It shows you a burndown chart for each milestone in your project, recording the number of open tickets each day so you can see the progress of your milestone. If you’re running in short iterations, it’s a good way to measure your team’s velocity all agile and whatnot. You can see an example for Tender’s current milestone. As a bonus, you can keep tabs on our development on Lighthouse and Tender for the sample install :)

Miniapps are fun

Burndown is what I’d call a miniapp — it can’t survive on it’s own, doesn’t have fancy permissioning, security or even the best code. It just gets the job done. For me, it was a way to play with a lot of new technologies I haven’t played with before. It’s currently running on Heroku, powered by Sinatra & Datamapper, with the front-end powered by jQuery & Raphael. I haven’t touched a single one of these, but the app still only took about a week to build.

If you want to try it out, I’d suggest opening up an account over at Heroku. From there, it should take a few minutes to get your own Burndown instance running.

Some thoughts on the tech

Since this was an all new experience I thought I might share some of my thoughts on the tech I used to build Burndown.

Heroku… rocks

I’d heard great things about Heroku, but never really had a need to play around with it. My first reaction: holy crap this is awesome. Getting the app up and deployed was easier than setting up Wordpress on Dreamhost. That says a lot. That being said, there were definitely some rough patches debugging the app, and I’m really not sure what was causing them. I’m guessing it’s whatever database they’re using, but can’t be certain. Weird ordering with my records.

Datamapper… I’ll take AR, thanks

Datamapper was definitely a struggle. I’m not down with the way conditions work at all. I understand what they’re trying to do here, but :age.gte => 15 is freakin weird lookin Ruby no matter how you slice it. I also ran into quite a few random bugs where my association finders weren’t getting scoped (want an example of a really hard bug to track down?). All in all, I’ll take my ActiveRecord over it any day.

Sinatra… rocks, reloading does not

Sinatra is an awesome little framework. I’ve played around with it in the past to the extent of hacking other people’s code, but never deployed something for myself. It’s a pretty rockin framework, and with PassengerPrefPane it exists seamlessly in my dev environment. Unfortunately the lack of code reloading is really a pain. Can’t tell you how many times I typed in touch tmp/restart.txt…

Raphael is awesome, if a bit obfuscated

I wanted to play around with a more powerful graphing library, so I ended up choosing Raphael. The end result is smooth, awesomely extendable, and fast. Unfortunately the sample code is really hard to understand. A few comments in this file would have gone miles. So would have using regular hex color values instead of crazy hue math. There is also zero documentation from what I can tell. Yes, there’s a documentation page… it does not show you how to use it.

When you HTTParty, you must party hard!

My first turn when interacting with the Lighthouse code base was to turn to the Lighthouse API gem, but because of the ActiveSupport dependency — and quite frankly gem conflicts I didn’t want to deal with — I decided to go the HTTParty route. Honestly, it’s just too easy to use. It made dealing with the API a breeze.

Go forth and create Lighthouse miniapps!

Feel free to fork / steal the source (including the design!) and create more miniapps for Lighthouse. Everyone uses bug trackers differently, and sometimes the best idea is to just build the interface / chart / feature you need. This app should cover the basics of saving / validating API keys, as well as some simple examples of how to sync data locally through cron jobs.

Your application will have many bugs

The first rule of development: your code is going to have a lot of bugs. I don’t care if you’ve got 3 days experience or 30 years experience in the industry. Your code will have bugs. This isn’t a pride issue, it’s a fact of life. Good developers know this and rely on testing (code, user-acceptance, performance) to expose bugs so they can fix them.

Bugs will appear after your code is deployed

Whether it’s the Y2k bug, deprecation of a technology, or your application getting blacklisted from a web service — some bugs are going to show up after your code is deployed. This is something you should expect. Again, this is not negotiable. It is going to happen.

The web makes us lazy

The truth is, developing web applications makes us lazy. I can fix a bug, deploy, and it’s fixed in about 15 seconds. This is why I love working on hosted web applications. You’ve got such immense power over the deployment process. Some things that rock about web apps:

• You can be really lazy with UAT (User Acceptance Testing). Users will do your UAT for your and you can fix it on the fly.
• You can be really lazy with bugs that will appear after deploy. If a web service changes, you fix it and redeploy. Done.
• You only need one computer to test your application. No need to purchase multiple hardware platforms, video cards, or install multiple operating systems!

You can’t be lazy with installable applications

I once worked on a desktop application that was being sent out on millions of machines. This application was going to be the first thing that started up when the user booted the machine. It also meant we didn’t have the option to issue updates for the application after deployment. We spent tons of time doing user testing on dozens of machines. And then the client did user testing. And then the client’s QA department did even more testing. And then the client’s QA department did more testing throughout the whole time they were writing hard drives.

Remember the days when you updated applications with CDs or floppy disks? My god, for a while there it just wasn’t feasible to update installable applications over the internet. The end result? Software development firms spent a lot of time and money on QA. Same goes for game development companies.

My point is: if you know that one of your restraints is updating can be slow or impossible, you spend more time testing the application.

The App Store is slow

It’s true the App Store is slow when it comes to delivering updates. To me, this is just a known variable. Wouldn’t it be awesome if they had 24 hour turnaround? Sure would be. But it’s one of those tradeoffs you get with a closed system. If you want to trade it for an open system — build a web application. It’s not that hard.

I know it sucks testing your application. I know as a lone developer you don’t have the money to hire testers.

But think of the rewards. The App Store is something of a gold rush right now. A small group of people have made obnoxious profits off very little effort. There’s almost no overhead ($100 application fee? psh) — and anyone can submit apps. It’s a shitty closed ecosystem controlled by Apple. But it’s a shitty closed ecosystem of chocolate-filled pools lined with gold and supermodels dressed in nothing but $100 bills if you strike it rich.

The good things

Let’s start off with what’s been working out great. First off: I get to focus when I want. Previously, I was one of those “9 to 5″ workers, meaning I got into work at 8:30am and left around 6:30pm or later. My problem is that my greatest focus time is generally around 7-9pm and 11-2am. The time I was at home. So now I get to work when I want, which means I get far more done in less time.

This whole focus thing can’t be exaggerated enough. I do not function in the mornings. Sure, I can force myself to wake up, get dressed, get to work, pound some coffee, but I just don’t get the work done I do later on in the day. Don’t give me the “you’ll get used to it” speech, because I did this 8-6 thing for 5 straight years. My body just doesn’t function in the mornings.

The second best part of working from home is controlling my nutrition. When I worked at an office, my diet was pretty horrid. I was constantly grabbing quick food from various places, for lunch, for dinner, for a breakfast snack. But now I get to wake up, make some coffee and enjoy a bowl of fruit or oatmeal as I catch up on the day. It’s also a lot easier to make several smaller meals throughout the day. I’ve also been able to exercise a lot more — I don’t have to wait until getting off work, or worry about bringing my gym bag, etc — I just go for a run when I have some spare time.

Lastly, I tend to waste a lot less time when I set down to work. I spend much less time in meetings (meetings used to consume an ungodly amount of my time at an office). I can close myself off in my room, put on some headphones and just get things done. Nobody to come by my desk and annoy me, or useless meetings to attend. Less talking, more doing.

The not so good things

My biggest problem right now is separation of work from home life. My desk sits opposite my bed right now, which means my computer’s always there in my bedroom. My next place I’d like to try and get a loft or something where there’s a really clear separation between sleeping space and working space. (Let me know if you know of an awesome loft opening up in San Francisco around July)

The second problem for me has been not working human hours. I have a few friends downtown who try and get me to go have beers with them at 5 when they get off. Unfortunately by then sometimes I’ve only clocked in a couple of hours for work — so I have to stay home and work through. This is of course directly in battle with my productive times, so it’s hard to find a clear winner here.

The future, perhaps?

Back in the late nineties, it seemed as though everyone thought telecommuting was going to be the future. I wonder if maybe we’re swinging back towards that now. Traffic of course only gets worse — while people’s homes are getting larger and further from city centers. About half of entp works from remote (from Tennessee to Uruguay) right now and we seem to get things done alright.

There’s no denying having an office is awesome, but I have a feeling it’s going to move from the “necessity” column over to the “nice to have” column in the next decade or two. Especially for professions like design & programming which take a certain amount of closed-off concentration to get things done. The problem is that people in our profession work well in small groups — and much worse in large groups. A small group breeds healthy debate and conversation, while a large group breeds endless arguments and criticism.

In any case, I wish more companies would try out having less strict hours for working in offices. It’s crystal clear to me that forcing people to work 9-5 only breeds a culture where your effort is measured in hours spent, and not work produced. It’s easy for someone to put in 8 hours of programming and get less done than another person who puts in 1 hour of work. It all has to do with breeding work conditions that work towards their advantage.

More info at Hoth

Hi, did you come here to tell me that XCode offers “all-in-one” editing? Please, don’t send me an email. This is addressed in this article if you take time to read it.

I posted some thoughts to twitter last night about how much the xCode window management drives me insane. What I got back was a huge reaction of “it’s perfect” and “this is how OSX works” Suddenly I was wondering, am I just insane for thinking the window management is absolutely horrible?

No, no. I’m not. It’s horrible. Just because Apple built it, does not make it perfect.

Tabs are the future (actually it’s been the standard for years)

Tabs have clearly proven themselves to be a superior method for editing multiple code files. Why? Because the most recognizable thing about code file is it’s filename. Not the look of the text. Let’s look at this through some examples.

Case #1: Window-based management FTW, Photoshop

Example of window management in Photoshop

Window management in OSX defaults to a new window for each document. This works wonderfully for most applications when you can see the differences visually. Photoshop is a great example. Using Exposé, I can see which document I mean to be working on at a glance The visual representation of the document is the unique identifier.

Some more points on why this works so well:

• Image documents are the only windows you will ever see in Photoshop. Everything else is a panel. This functionality is the same for all five-star document-based apps. iWork, iLife, etc. There is a really good reason Apple chose to hide panels when activating Exposé.
• Photoshop is a document immersive program. It’s unlikely you’ll be working on more than one PSD at a time. The document is all that matters. Conversely with code, the project is all that matters (not one code file).

Case #2: Tab-based management FTW, Texmtate

Example of window management in Texmate

Window management for Textmate is handled via tabs and a persistent sidebar. At a glance, you can see all files you’re currently working on. In the case of Cocoa, you are often switching between interface & implementation files, but this is easily handled via cmd-opt-up, so long as you have the name of the class right, you’ve got the right file.

Some points on why this works so well:

• Windows provide a way to group files in a meaningful manner. Each window is a unique project. Remember, the project is the important thing — when coding in Cocoa, you’ll need to edit multiple files at once to make them work with one another.
• I can quickly move between individual files via the keyboard. Considering coding is almost purely typing, keeping my hands on the keyboard is killer.

Case #3: WTF-based management FTL, xCode

Example of window management in xCode

Window management for xCode is handled via a combination of this thing called a Project window, which morphs depending on it’s toolbar state, windows for each document, and windows for ancillary programs (like the model editor). Please note I have the same number of windows open in this screenshot as I did in Textmate (7). It’s actually a pretty small program, but completely overwhelming.

Some points on why this doesn’t work so well:

• Windows mean different things. Some mean code documents, some mean visual aid, some mean a kind of “project” that groups all things.
• The project window continually morphs it’s state as you enter and exit debugging. It’s appearance is different, not upon your application’s state, but rather the toolbar button in the upper left, that automatically changes (one-way).
• All the code looks the same. There is no unique identifier in Exposé mode. I must selectively hover over each file and read it’s filename. Or, I can exposé to try and find the project window (which can look much like a code window too), and then open a new document.
• If I accidentally Cmd-W the Project window, I have to start from scratch, opening the whole project and each document again. This often happens as you accidentally open windows and want to immediately close them.

Some may counter, telling me that xCode offers editing inside the project window. Sure, this works, but offers just as many frustrations.

• You must single click on files to open them. Double-clicking them still opens them in a new document.
• Because of the above, and the last bullet on the previous list, I constantly find myself accidentally closing the project because I was trying to close an accidentally opened window.
• Unless I choose not to run my program, I constantly have to switch out of debug mode and back into editing mode via the toolbar.
• Every single time I open xCode I have to force it into editor mode.
• There is a delay in single clicking a document. You click the file on the sidebar, the sidebar highlights, but the new document doesn’t open in the editing window for a second or two. When trying to scan documents for some code, this results in endless confusion.
• There’s no idea of “open files” in this mode. No context for which I’m working. I can’t say, work on the View Controllers by opening each of them. Each time I must select the unique view controller in the sidebar, ordered alphabetically.

It’s a shame

It’s a shame, because other than the window management, xCode is really an awesome IDE. The actual text editing is great as is debugging, scriptability, and file management. It really helps solve all the problems that Cocoa apps force upon mere text editors (long method names, class names, files being in one directory, different types of files in the same directory, etc).

It’s the program’s fatal flaw in my mind. It isn’t that it’s sub-par, or not good enough — it’s downright infuriating to use. I want to do mean things to cute kittens whenever I use it. So I don’t. I use TextMate. Which actually is very good at Cocoa & Objective-C. But it means much more typing (especially with the shift key) since TextMate favors tab-triggers rather than tab-completion.

At the end of the day, this is the kind of stuff I hope Mac developers care about. It’s about making the user experience the #1 priority in software development. And it’s something that I’m confident Apple knows about and intends to fix in future versions of xCode. Because they care about the user experience.