Proper

As promised, I wanted to follow up on my post from Thursday asking what you charge (as a response to this article: http://www.jamiebegin.com/how-much-to-charge-as-a-freelancer/). 

I didn't get a lot of results (only 8 people were brave enough to share!), but data is data and hopefully it can influence your pricing for the better. Here's how it stacked up: 

Total Responses: 8 

<$50/hr: 

3 People (37.5%)

$50-$75/hr:

2 People (25%)

$75-$100/hr: 

1 Person (12.5%)

$100-$125/hr: 

1 Person (12.5%)

$125-$150/hr: 

0 People (0%)

$150-$175/hr: 

1 Person (12.5%)

$175-$200/hr: 

0 People (0%)

>$200/hr: 

0 People (0%)

I just sent an email out to the Proper/WhatWhen mailing list asking about what people charge and I wanted to share the link here, too. 

I decided to create a survey to ask what everyone is charging in response to this article I read about pricing for freelancers: http://www.jamiebegin.com/how-much-to-charge-as-a-freelancer/.

If you have a few minutes, hop over to Survey Monkey to contribute your rate (this is anonymous and I'll be posting the results back here on the blog on Monday): http://www.surveymonkey.com/s/8RLN77Y.

When I first started out as a freelancer, I looked at anyone who came to me with money and an idea for a project as my ideal client. Over time, though, this didn't net the best results. Why? I had a steady stream of clients and decent money coming in, so what was the issue? I was stressed out beyond belief.

The work was steady, sure, but the majority of the clients that I worked with were a real drag. They'd fight me over my rate, asking if I'd lower it or give them a discount. They'd challenge my invoices, saying things like "gee, this doesn't look like it took eight hours to do…" I was annoyed and stressing out more than seemed fair.

So I did a little experiment. I made up two clients: a good client and a bad client. For the bad client, I wrote down all of the things that upset me when working with my previous clients. For the good client, all of the positive things clients did that made project's run smoother. When I was done, I had a clear picture of who I wanted to work with and who I didn't.

Here's what my original list looked like: http://cl.ly/QL5x

With a solid definition of my ideal client, weeding out bad clients was a cinch. Whenever I hopped on the phone with a new prospect, I'd have these lists nearby. As we talked about their project, if any of the "bad client" items were mentioned, I made a note. If so many items came up during a call (my limit is 2-3), I knew it was a sign that I wouldn't work well with this client. To make sure I wasn't a jerk, I'd write a follow up email the day after our call, politely rejecting the work:

Hey <Name>,

I wanted to follow up on our call from yesterday to say that I'd like to pass on your project. After our discussion, I decided that it I'm not the best fit for the job and would recommend having another designer take a look at the project. Best of luck with everything and if you have any questions, don't hesitate to ask.

Take care, Ryan

Now don't get me wrong. Turning down the chance to work on a paying gig can sting, but part of having a "good" clientele is being able to identify and get rid of the "bad." A good way to get started is to only apply your list to half of your prospects. As you get more comfortable with rejecting work, increase the number of prospects you check against the list until it's at 100% (note: don't drag this out forever, commit to fully validating prospects within the month).

Another helpful tool is keeping a client journal. From your first call and throughout the project, take notes on your client's behavior, how you work together, and what parts of the experience are good and bad. Use these notes to improve your good client/bad client lists and work toward having a bullet proof filter for new work.

As development of Proper moves forward, I’ve started to toy with a good way to handle hosting. After doing a bit of research, I came across a short list of PaaS providers, finally landing on Nodejitsu as the most attractive for my needs. If you’ve investigated using Nodejitsu, too, you’ve probably come across this Stack Overflow post that mentions a problem with getting the Node Fibers package up and running.

Fortunately, the Demeteorizer tool created by the Modulus team (another PaaS provider) helps us get around this. In this tutorial, we’ll go over the process of using Demeteroizer, getting a Nodejitsu account running, and deploying a working app.

Installing Demeteroizer

The first step is to “demeteorize" your app and prep it for deploying to Nodejitsu. The instructions in this post are what you’ll need to follow, but it’s important to note that you’ll only need to do two things: install Demeteorizer and then run it in your project directory. This can be a little confusing, so let’s step through it.

First, run the command to install demeteorizer via the NPM (Node Package Manager) CLI:

npm install -g demeteorizer

Once that’s installed, switch into your project directory and demeteorize it:

cd myproject && demeteorizer

This will do some magical fun stuff and then output a raw Node version of your app in the .demeteorized directory (this will be in your project root unless you specified otherwise). After you’ve done this, pop open the .demeteorized directory and then open up package.json in a text editor. Under the “engines" value in the object, set the value for the “node" key equal to “0.8.x". It’s important to note, this is what worked for me. I’m by no means a Node pro, but changing the version number from 0.8.18 to 0.8.x made the Nodejitsu deploy script quit spitting out errors. Once this is set, save and close this file. Next, we’ll setup a Nodejitsu account and get a deploy going.

Setting up Nodejitsu

First things first, head over to Nodejitsu and signup for an account. For this demo, I just setup an account under the “free" plan. If you’re hosting an open source project, Nodejitsu will give you hosting for free. Check out this link if that’s you. If not, setup a free account and then we’ll keep moving forward.

Got an account? Great. All we need to do now is install the Nodejitsu command line utility:

npm install -g jitsu

Cool. Now, let’s login to our Nodejitsu account and deploy our first app:

jitsu login

You’ll be prompted for your Nodejitsu account info. Follow the prompts until you see:

info: Authenticated as <username> info: Nodejitsu ok

Nice work! Now we’re logged into Nodejitsu and can get a deploy going. Let’s make sure we’re in the .demeteorized directory we created early (if you’re not already), and the run a deploy:

cd .demeteorized && jitsu deploy

So, the next thing that happens is you’ll be prompted for some info from Nodejitsu. The first thing you’ll be asked for is a subdomain prefix where your app will live on Nodejitsu. This is just a plain string, something like “exampleapp" (no quotes). Make this whatever you’d like your URL to be (the final URL will be http://<subdomain>.jit.su).

Next is setting up the “start script." This is a Node thing. We need to tell Node a bunch of stuff to get started up and this script is what does the work for us. What this prompt is asking for is a path to the directory for the script. Just type server/server.js (after the prompt) like so:

prompt: scripts.start: (node server) server/server.js

Blammo! Everything is setup and Nodejitsu we’ll start to deploy. Almost there.

Now this will run some dohickery and then we’ll get an error. Crap! This is an easy fix, though. The bug is that the app is looking for a MONGO_URL (our database URL) and can’t find one. If you’ve ever deployed your app to meteor.com before, this may seem strange because they automatically setup a db for us. This time, we need to do it on our own.

While a detailed walkthrough is outside of the scope of this tutorial, I recommend trying out MongoHQ. They offer a free sandbox database that you can use to your heart’s content, and set up is really simple. Head over to MongoHQ quick and setup an account. Once you’ve done that, create your first database (hint: you’ll pick out the “Sandbox" option under the Elastic Hosting (AWS) subheading). With a database in hand, you’ll want to add a user to it so we can access it easily.

To add a user, tap on the “Admin" tab on the left-hand side of the screen and then the Users tab. Add in a new user and remember the information (we’ll need this when we wire up the MONGO_URL next). Got a user? Write down the info? Nice, let’s get this working.

Setting up Environment Variables on Nodejitsu

Let’s head over to the Nodejitsu website and login. At this point, we’ll see the app we just tried to deploy with the name we provided in the prompt above. Here, you’ll see three tabs. Click on the “Environment variables" tab. Here, we need to add some URLs. Make sure to leave the ones that Nodejitsu added by default intact.

Click on the “Add variable" button (you’ll repeat this for each key/value pair below) and add each environment variable listed below:

NOTE: These will be different for you, so make sure to customize with your own information.

Got them added? Great. Now we can try our deploy again and get a working copy of our app running.

Deploying to Nodejitsu…Again

Now that we’ve got these set, we can actually just try starting our app from the Nodejitsu web interface. On the same screen, look for the group of buttons to the right of your app name and click on the one labeled “start". Once you’ve done this, give Nodejitsu a few seconds to boot everything up. Once you see the badge to the right of your name turn green and display the text “started," go to your Nodejitsu URL. If everything went as planned, you should see a working copy of your app! Awesome!

Wrapping Up

We covered a lot, so let’s review what we accomplished:

Installed Demeteorizer and demeteorized our app to get it Node-proof for Nodejitsu.

Created a Nodejitsu account, logged in, and attempted a deploy.

Ran into an error with our database, created a database on MongoHQ.

Setup Environment variables on Nodejitsu to tell our app which resources to use.

Turned our server on and got a running app.

Pretty cool stuff. Now, we can run our app on Nodejitsu which means we get the benefit of using web sockets and sticky sessions. If you’re curious about scaling and how this works, I recommend checking out this tutorial over on Meteor Hacks.

Did this work for you? Shoot me an email with your app URL after you’ve got it working and I’ll add it to this post as an example.

I just spent the last half hour daydreaming about another career. What would it be like if I were doing that instead of writing software? I felt guilty. If I really cared about what I was working on, would I be daydreaming about doing something else? In the past, I would have responded "no, if you're serious about this thing it should consume your entire being." That's a little ridiculous, isn't it?

What I didn't consider was that I was daydreaming because I got stuck. I was working on the timeline feature for Proper and was contemplating what I learned from the launch of WhatWhen. What feedback had I gotten on the features? Do I really need all of this stuff? I got overwhelmed, I seized up. Progress screeched to a halt. Oh no…do I suck now?

Of course not, and here's why: there isn't a fixed process for this stuff. Sure, we sell books and give talks on how there is a fixed process, but in reality, a process is nothing more than a set of guidelines that fails to take into consideration the human element. 

We're dynamic. Our opinions, needs, and desires change more frequently than we like to admit. When we try and force ourselves into doing something that neglects the ebb and flow of life, we start to lock up. We feel guilty. Sometimes we give up, believing we're absolute failures.

You know what that daydreaming did, though? It allowed my brain to move away from the problem. It made me say "hey, maybe it's time to take a break and step away from this." I got up, went into the kitchen, made some coffee, and now I'm here writing this post. 

In a sort of domino effect, my daydream about another career has allowed me to kickstart my creativity and get excited about what I was working on again. Now I can't stop thinking about finishing this article so I can get back to work on that timeline feature.

Earlier today, I was on the bus heading back from a meeting and realized something: I used to be terrified of this. No joke, when I first moved to Chicago the idea of getting on the bus freaked me out. I was convinced that I would get lost, get off at the wrong stop, or the bus would make a right turn and I'd never see home again. Silly right?

I think this happens more than we'd like to admit. We make up these exaggerated stories in our mind of what we think will happen, but rarely – if ever – does. We develop a list of things that, at the thought of trying them, makes us down right cringe. 

This got me thinking. What else makes me cringe? After a little bit of thinking, I had another cringe worthy idea from my list: open source software. Really? Yep. The thing that made me cringe about it wasn't the software itself, but rather, the act of sharing it. Giving my work away for free and leaving it open to scrutiny.

More than it being free, the criticism really spooked me. What if my code "sucks?" What if people think my work is crap? Just the though of one email saying "pack it up dude, you suck" made me shudder.

Until today. Just like the bus, I'd decided my fear was silly. I recently launched a new app called WhatWhen which is built on a new JavaScript framework called Meteor. While the community and resources are growing around the framework, there are not a lot of examples online of "full" applications. So I asked myself, "could someone else learn from this?" Am I really going to care if someone gives me a negative comment instead of helping out a fellow developer? 

No. And for a good reason: it takes stones to share your work. To put something out into the world for other people to poke and prod at, to manipulate, to tear to absolute shreds. I could see the trolls under the other side of the bridge, but I said "fuck it" and typed git push origin master. If you'd like to check it out, you can find the result over on GitHub: https://github.com/properapp/whatwhen.

Today, I'm announcing a new product: WhatWhen - Tidy timelines for freelancers.

If you've been following this blog, you'll know that I've been working on a product to manage client expectations. Today, I'm giving a preview of that work in the form of another, simpler product. 

WhatWhen was made for freelancers. It allows you to create simple, clean timelines to share with your clients. It's based on the same tool that you'll find in Proper when it launches later this summer. It's really cool and I'm excited to release it to the public.

Head over now to signup and create your first timeline.

I'm extremely open to feedback on WhatWhen, so please, if you have any thoughts, I'd be glad to chat: [email protected].

Humph. 

Just killed more time than I should have trying to get a couple of Twitter and Facebook buttons working. If you're going to add these (or any other external widget-style content) to an app you're working on, the following will help you out.

By default, these buttons load once on page load. They work, and that's great, but if you're using something like the Meteor Router package, shifting between pages causes the buttons to break. So, what's the fix?

Iframes. Yep, just use an iframe. Twitter and Facebook have their own (newer) embed codes using javascript, but these are not reliable. To get everything working, place the iframe HTML for each button into a template of its own (i.e. one template called 'twitter' and another 'facebook') and reference where they're required. 

I'm stressing out. 

I've been tying up the final pieces of WhatWhen, the timeline-focused sibling of Proper and in the process, I've started to doubt myself. Why? That's the problem: I'm not entirely sure.

The usual "what ifs" have been running through my mind. What if people don't like it? What if it's confusing? What if it doesn't solve their problems. The thought of an idea being rejected is surprisingly stressful.

Amidst all of this fear and loathing, I've come to understand and accept something: software can't fix all of your problems.

Software can't make someone a better communicator. Software can't help someone be more detailed. Software can't remove uncertainty from life. Software can't make someone's work better. Software can't guarantee perfection.

Software is what it is. No piece of software can meet the needs and capabilities of every single person. There are limits in all directions. The best we can do is make the best that we can now and iterate from there.

Holy crap has this part of the blog gone silent. Well, I'm back. A bit of an explanation on my lowered frequency...

In an effort to help drum up some interest in Proper and test out the overal look and feel of the app, I decided to spend the last couple of weeks bashing out a sub-product based around one feature of Proper: timelines. 

When I'd considered which piece of the app would be most useful on its own, I realized that the timeline had this sort of independent vibe to it. Once I had the basic idea on paper, I dug in. 

The cool part was that a lot of the code I needed to write was already committed to Proper. Most of my time was more or less spent changing variable names and eliminating bulk. The end result, though, is coming together and I'm hoping to launch it in the next week or so. Take a peek at the landing page in it's current state:

Excited? I am. Once I get the thing out the door, I'll do a write up on how I did it, why I did it, and how what I've learned is being rolled back into Proper. As always, signup for the mailing list over at http://properapp.com for the latest updates and announcements.