Samuel Mullen

What could possibly go wrong?

Startup Journal: Procrastination

Several weeks ago, I met a friend for lunch to discuss what we’ve each been working on. I was excited about my product and began relating to him how much progress I was making on the registration and authentication pieces, completing the accounts pages, and how I was turning my attention to defining “plans”.

Without missing a beat, Kenny just looked at me and asked very pointedly, “Why are you wasting time on registration, when you should be working on the product itself?”

That stung a lot, but he was right. I should have been focusing on the product itself, but there I was working on registration. At the time, I was convinced registration had to be in place before I could even start on the main application. Now I know I was just putting it off.

Unlike registration, the rest of the application is uncharted territory. I don’t know how things are done in the industry, what the workflows are like, or what the user experience should be. (I’m basically trying to duplicate a real world process on the computer without ever having actually seen the process being performed.) Not having a clear idea of what to do is highly demotivating. So, like most people, I gravitate toward activities I know until more is revealed about the problem at hand. In this case, however, no more information was forthcoming. I just needed to push through.

Getting that initial momentum is everything. Once that’s acquired, building upon it is easy. What seems to work well for me is staring blankly at the ceiling for a little while – but not too long – trying to figure out how things will work, and then drawing some basic wireframes on paper.

I don’t know if it’s the act of laying things out at that high of a level, of if drawing opens up some part of my brain which knows what needs to be done, but that’s the pattern which seems to have emerged. Think, draw, do.

Since that lunch with Kenny, I’ve completed the first of the three major components of the application, and have started working on the second. Procrastination’s still a problem – it always will be – but having friends to keep you on track can sometimes be all the momentum you need.

Transparency

It’s not uncommon for clients to send me emails asking for the current hours worked on a project for a given month. Sometimes it’s to help them allocate resource, while other times it’s due to budget constraints, and I’m sure there are other reasons as well.

It’s never a problem to provide this information, of course, but I also recognize it as a pain point for them. In that light, I thought it might be better to give my clients the ability to check on their projects themselves. To that end, I’ve created a web application called Transparency.

All my clients have access to the application, and through it, can see the amount of time spent on each of their projects.

They can also zoom in on any given project to see the task breakdown.

There are more features I’d like to add - listing non-billable work and subcontractors’ hours come to mind - but as the project stands, it does what it’s supposed to do: it provides some Transparency to my customers.

The Two Most Productivity Enhancing Scripts Ever Written in the History of UNIX

You’re not a slacker. In fact, you’re a pretty good developer who gets things done on time and done well. But sometimes you find yourself wasting time on that site again. You weren’t planning to go there, but the code takes a minute to compile and the tests take a bit longer to run and so you just flip over there while you wait.

Ten minutes later you’re still there, not thinking, just consuming.

And you berate yourself again for wasting time.

What you don’t need is some overlord application telling you you can’t access the internet for the next three hours. You just need a gentle reminder that you want to be productive.

Here it is. Two simple scripts. (go to the GitHub Gist)

One to block the sites you don’t want to visit:

worktime bash function
1
2
3
4
5
6
function worktime {
  echo "# WORKTIME" | sudo tee -a /etc/hosts > /dev/null
  while read -r line; do
    echo "127.0.0.1 ${line}"
  done < $HOME/.blocked_sites | sudo tee -a /etc/hosts > /dev/null
}

And one to remove the block:

slacktime bash function
1
2
3
4
5
6
7
8
9
10
function slacktime {
  flag=0
  while read -r line; do
    [[ $line =~ "# WORKTIME" ]] && flag=1
    [[ $flag -eq 1 ]] && continue
    echo $line
  done < /etc/hosts > /tmp/hosts

  sudo cp /tmp/hosts /etc/hosts
}

List the sites you don’t want to be visiting in .blocked_sites in your $HOME directory. Like this:

.blocked_sites
1
2
3
4
5
twitter.com
www.twitter.com # you may need to include the www subdomain
feedbin.me
alpha.app.net
app.net

When you want to be productive, run worktime. When you’re ready to slack off, run slacktime.

worktime adds those sites to your /etc/hosts file redirecting you back to localhost. If you’re feeling creative, make a landing page with a picture or text reminding you to keep been awesome. I use a picture of R. Lee Ermey to gently remind me what I’m supposed to be doing.

When you’re done being productive, run slacktime. slacktime just removes the entries which were added to the /etc/hosts file.

So are these really the two most productivity enhancing scripts ever written in the history of UNIX, or am I just using a bit of hyperbole to increase traffic? Probably the latter, but I still hope I help you become more productive.

Now quit slacking off and get back to work!

Startup Journal: Beginnings

Words have always been associated with changes in the course of history. Jesus’ “It is finished”, Julius Caesar’s “The die is cast”, and the Declaration of Independence’s “We the people…” were each at the fulcrum when history’s events completely shifted.

For those who have started businesses, it is likely they can look back upon a conversation, an argument, an article, or even just a handful of words which resonated with them. It was the tipping point which changed the course of their history forever.

For me, it is this blog post.

Choices

In Paul Graham’s recent article, Do Things That Don’t Scale, he wrote, “…startups take off because the founders make them take off.” Although it was written more as a lead-in to the rest of the article, that one phrase resonated with me more than anything else in his essay.

Like many people, I’ve either played around with the idea of a business or started down the path to creating one. Book store, sports registration site, bookmarking service, a chess site, and probably a couple of other things which have fallen down the memory hole. They all kind of petered out for one reason or another. Of course I know why, but I have no regrets. It was all by choice, and arguably, the right choice.

This time around, I need to choose to succeed.

Reasoning

That’s why I’m writing this post and those which will follow. It’s one thing to start something and quit when only your wife knows what you’ve been goofing around with, it’s quite another when everyone in your community knows. By putting this out there publicly I’m hoping it will provide the motivation - through self-induced guilt-trips and fear of public humiliation - to pursue this to the end, rather than stopping somewhere along the way.

More than just personal motivation, I’m hoping that journaling my progress will also help to clarify things for myself. Things which need to be altered, processes which need to be improved, and just providing me with clarity of thought on the business. I’m also hoping my writing will be an encouragement for others.

Just Enough

The business will be a SaaS for businesses of a specific market. This means there will be a web application with an eventual iOS and Android tie-in. The application will be subscription-based and focused on a somewhat niche market, but one which both needs the application and which has money. I have an advisor, and through him, I will have access to subject matter experts (SME) and beta-testers who can help me determine what the industry needs. But for the most part, I’m on my own.

And that’s as much as I’m going to say about the market and what I’m building. It’s just not that important or interesting to those on the outside.

Frequency

I don’t know what kind of frequency I’ll be able to produce these posts. I’ll write when I can, but I also have to find time to work on the product and business. If you weren’t already aware, my day/night/evening/weekend/vacation job is as an independent software developer, so I don’t have a lot of time to begin with. I usually write in the mornings, but even then I can get side-tracked or stumped for a topic (topics are another reason for this series).

The Ring

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.

– President Theodore Roosevelt, Paris, France on April 23, 1910

I am putting a lot of pressure on myself to make this business succeed. Some of it’s competitiveness with the Jones’s, some of it is for my family, but a lot is just out of a personal need to build something of my own. Obviously I’m worried about failure, but failure’s not the worst thing that can happen. The worst thing that can happen is you come to the end of your life and realize you did nothing with it.

So You Want to Be a Freelancer…

In certain circles, I get a lot of attention when I mention I’m an independent developer (i.e. freelancer). The questions range from “isn’t it risky?” to “how long have you been doing it?”, but most of the questions revolve around how to get started. For some, such as myself, the transition happens gradually as “side work” slowly evolves into just “work”. For others a more daring trajectory is chosen and they quit their full-time job and dive in without fear of the ramifications. Still others turn to freelancing, not as a choice, but as the only option left for them.

I understand the allure of freelancing: the freedom and independence, setting your own hours, choosing the clients you want, more time to spend with your family, choosing your own rates. The siren’s song of freelancing is very powerful. And like the myth, if you’re not careful, your ship may end up shattered on the rocks.

The Cake is a Lie

If I can offer you just one piece (cake pun) of advice concerning freelancing, it’s this: Don’t do it. I’m serious. All that rubbish about free-time, family-time, money, and freedom? It’s there - mostly - but it comes with a price. Let’s look at a few of the costs:

  • Free-time and family-time: You can get more free time and family time, but often you’ll have to be very intentional to do so. You’ll have plenty while waiting for clients to sign off on projects, or when you’re looking for your next job.
  • Freedom and independence: yes and no. If you’re too independent you may find yourself with a little more freedom. If you’re not independent enough, you’ll become a slave to your clients.
  • Choosing your own rates: Yup, you get to do that. Don’t screw it up.
  • More money: Yes, but it’s entirely dependent upon how much work you get, what rate you charge, and if your clients pay.

When you talk with a freelancer - myself included - you’re going to hear the highlights. You’re not going to hear about sales, marketing, taxes, problem clients, accounting and bookkeeping, the never-ending flow of email, the constant hustling, late nights, sleepless nights, angry spouses, etc. No. You’re mostly going to hear the highlights.

Really, you have to be either arrogant or ignorant to go into this business; if you had any sense, you’d run screaming away in terror from this decision.

But you’re not going to, are you?

First Things First

Chances are, you currently have a “normal”, 9-5 job. Congratulations, they are your first client. The place may be an institutional, bureaucratic hell which is slowly draining you of any will to achieve in life, but like it or not, they’re your first client and you need to treat them as such. That means doing your best work, helping out your coworkers, making good connections; basically leaving a positive impression on as many people as you can.

There are at least two reasons for this:

  1. Your current employer may end up needing you after you leave. They’ll be more inclined to hire you as a freelancer if you’ve left on good terms.
  2. Many of the people you currently work with are going to leave for other companies. Those are all potential opportunities for future work.

One more thing, don’t talk to your current employer about freelancing - I’m speaking from experience. Your current employer wants to know that you are focused on them. That also goes for when you have clients: Client A doesn’t care about your problems with Client B.

From This Point Forward

There is a misconception that freelancing allows a person to focus solely on one’s craft. It surprises many to find out that a busy week may only net 30 billable hours. Where’d the rest of the time go?

You are no longer just a writer, designer, programmer, sysadmin. You are now a business owner. And with that change in title, also comes a change in responsibility. You’re now responsible for responding to clients, creating estimates, meeting people for lunch, increasing your network, marketing, invoicing, bookkeeping, and on, and on, and on.

You will find that you are always selling. While talking to a parent at your kid’s soccer game, in the back of your mind you’ll wonder, “would they or their company need my services?” You just never know where that next sale or opportunity will come from. Everyone’s a potential future client.

Selling Your Life, an Hour at a Time

There are basically two types of pricing: value-based (project), and time & materials (hourly). Most people start out as hourly, or if they don’t, they switch to it shortly after enduring a project that wouldn’t die. Later on, as freelancers move toward becoming agencies, they figure out how to crack the nut that is value-based pricing. It’s a tough nut.

To begin with, however, you’ll likely want to charge by the hour. What you bill is up to you, but I advise people to figure out their current annual salary, and divide that by 1,000.

hourly rate = annual salary / 1000

That may appear at first to be a really big number, but remember, you have to pay for your own insurance, vacation time, sick time, 401K, and so on. This is not the time for “imposter syndrome”. Believe you are worth your rate, or be prepared to be negotiated downward.

But having an hourly rate can mess with you, and I’ve spoken with people who refuse to freelance for this fact alone. You can now determine how many hours it will take you to pay for that new computer, but you also know how much it costs you to spend time with your family. It’s surprising how much a little league game costs ([40 minutes travel time + 2 hour game] * hourly rate = much weeping and gnashing of teeth.)

But you get over it…mostly.

Oh, there is one more tiny matter: taxes. Make sure to take a 1/3 of each invoice you are paid and put it into savings for taxes. Seriously, you don’t want to make this mistake.

Perform the Most Uncomplicated Procedures and Processes Which Stand To Produce the Most Favorable Outcome in a Consistent and Regular Manner

Huh?

Exactly. Do the simplest thing that can possibly work.

When you’re starting out, you don’t need a website, special Twitter account, legal entity, business cards, logo, t-shirt, etc. You’re a freelancer, all you really need is work and someone to send the invoices.

When you are first setting out, it’s easily to look around and see what the more established independents are doing and get caught up in where you aren’t. Just take a deep breath. Relax. You have time. If you have work, focus on that. If you don’t have work, focus on finding work. The rest is ancillary and can be done a little at a time.

Just write down the things which need to get done; prioritize them; and complete them when and as you are able.

Alone Together

When you start a “real” job at a company, you have the benefit of coworkers (yes, I actually said that). Coworkers can be great resources for discovering where to go for files or paperwork, learning how things are done in the organization, and how to navigate the political waters.

As an independent, however, you don’t have all of that, so it is useful to find other people in your area who also freelance. From more seasoned freelancers and from those in other disciplines, you can learn about a host of topics you might not be aware of such as contracts and legal issues, insurance, accounting matters and bookkeeping, outsourcing and subcontracting, and so on.

Not only is having a good network of like-minded peers great for discovering better ways of doings things, it’s also great for finding new work, or being able to offload work. Developers need designers and dev ops; designers need developers and copywriters; and we can all learn from one another, because not a single one of us has it all figured out.

Freelancing is a solo gig, but you don’t have to go it alone.

The Next Client

Earlier, I said you will be doing both sales and marketing. This is why: you’ll always be on the hunt for the next client. When you find them, you’re going to have to close the sale.

Remember that guy in high school who just did his homework, kept to himself, didn’t really get involved in anything, and never made a commotion? No one else does either. Like it or not, you’re going to have to market yourself, and that means promoting yourself and getting your name out there. To do that, you’ll need to find the marketing strategy that works for you.

Blogging and social media work well for some people. I know other freelancers who offer products to increase their image as an authority. Still others do the conference circuit, screen casts, and some actually go out and meet people face to face (what’s up with that?)

There are a lot of options out there, and to help you figure out your own strategy, you should check out the following books:

Assuming your marketing strategy is successful, then it’s time to close the sale, and every sale is different. Some clients will sign you on after a first meeting while others will drag out the process over a period of months. Some people want to haggle, while others just sign on the bottom line.

If there’s any advice I have about sales, and I don’t have much, it’s to try to understand the client. It shouldn’t be you vs. them, but a partnership to help them achieve their objective. Listen to them, try to understand what their real needs are, and do your best to communicate how you can meet those needs in the manner in which they need to hear it.

Regardless of the sale, you’re going to get moved outside of your comfort zone. You’ll be intimidated in some instances and totally in charge in others. You’re going to nail some sales, while others are going to go so badly you’ll want to move out of state. Sales is hard, but you’ll get better with experience, and you may eventually enjoy the hunt.

Wrapping Up

If I’ve not made it clear yet, freelancing isn’t always easy, and it’s not the career choice most “normal” people would choose for themselves. It solves some problems, but it brings along with it a host of others (and opportunities). It really helps to have the right personality for it, and not everyone has that.

I’ve been freelancing now for about four years: part-time for two years, and full-time for two. There are days when I want to chuck it all and become a greeter at Walmart, but in general things are great. I get to spend a lot of time with my family, I’m growing in my field, I have time to exercise, and I just get to enjoy what I do.

I love freelancing.

Lazy Instantiation

I first heard the term, “lazy instantiation”, when I started working in iOS. I’d used the idea before, but didn’t have a name for it. The basic idea is to “[delay] the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.” (Wikipedia).

Here’s an example in Objective-C:

Objective-C Example
1
2
3
4
5
6
7
8
- (myClass *)myClass
{
    if (!_myClass){
        _myClass = [[myClass alloc] init];
        [_myClass setUpMyClass]; // this method just loads sounds and some text
    }
    return _myClass;
}

Real World Example

Lately, it seems like all of my projects have needed to access third party APIs. I’ve been using lazy instantiation to combat unnecessarily calling the external resources. What follows is a simple example of some code for retrieving what’s currently playing on Rdio:

RdioQueue
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class RdioQueue
  attr_reader :client, :venue

  def initialize(client, venue)
    @venue = venue
    @client = client
  end

  def rdio_user
    @rdio_user ||= self.client.get(:keys => self.venue.uid, :extras => "lastSongPlayed,lastSongPlayTime").values.first
  end

  def rdio_track
    @rdio_track ||= self.rdio_user.lastSongPlayed
  end

  def rdio_track_start_time
    @rdio_track_start_time ||= self.rdio_user.lastSongPlayTime
  end

  # ... other unrelated methods ...
end

This class is primarily used to retrieve album track information, all of which is handled through the call to Rdio’s user API. Rather than making a separate call through the Rdio client each time information is needed, we just pass our messages through rdio_user. Once it’s initially retrieved, the external call is never made again (thanks to the or-equal ||= operator).

If we needed to perform an action against rdio_track further down in our code, we would just call rdio_track. There would be no need to first initialize rdio_user, it all just happens “just in time”™. At this point, rdio_user has its instance variable (ivar) set and further calls to rdio_user return immediately, as do calls to rdio_track.

Caveats

Some care must be taken with lazy instantiation. If taken to an extreme, it will result in a Law of Demeter violation.

Closing

I am not presenting any hidden coding secrets or revelations. None of this is rocket-science, and it’s likely you’re already using lazy instantiation in a current project. Only, now you have a name for it.

The Problem With Rails Callbacks

If you search StackOverflow for “Rails callbacks”, a large number of the results pertain to seeking means to avoid issuing the callback in certain contexts. It almost seems as though Rails developers discover a need to avoid callbacks as soon as they discover their existence.

Normally, this would be a cause for concern, that perhaps the feature should be avoided altogether or even removed, but callbacks are still part of Rails. Maybe the problem goes deeper.

What is a Callback?

As you likely already know, callbacks are just hooks into an ActiveRecord object’s life cycle. Actions can be performed “before”, “after”, or even “around” ActiveRecord events, such as save, validate, or create. Also, callbacks are cumulative, so you can have two actions which occur before_update, and those callbacks will be executed in the order they are occur.

Where Trouble Begins

Developers usually start noticing callback pain during testing. If you’re not testing your ActiveRecord models, you’ll begin noticing pain later as your application grows and as more logic is required to call or avoid the callback.

I say, “developers usually start noticing callback pain during testing” because in order to speed up tests or to get them to pass, it becomes necessary to “stub out” the callback actions. If you don’t stub out the action, then you must add the supporting data structure, class, and/or logic to each test in order for it to pass.

Here’s an example of what I mean:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class Post < ActiveRecord::Base
  has_many :followers
  after_save :notify_followers

  def publish!
    self.published_at = Time.now
    save
  end

  private

  def notify_followers
    Notifier.post_mailer.deliver
  end
end

describe "publishing the article" do
  it "saves the object with a defined published_at value" do
    Post.any_instance.stub(:notify_followers) # Codey McSmellsalot
    post = Post.new(:title => "The Problem with Callbacks in Rails")
    post.publish!
    expect(post.published_at).to be_an_kind_of(Time)
    expect(post).to_not be_a_new_record
  end
end

In order to get that example code to pass, notify_followers must be “stubbed out”. If it isn’t, and if followers are used within the mailer, the test will fail because it’s not able to execute the delivery (i.e. it’ll error out due to nil values).

What About Observers?

Rails developers who’ve begun moving into a more Object Oriented mindset might ask, “What about using observers instead of callbacks?” It’s the right direction: by creating an observer, you move responsibilities which don’t belong in the object being observed to the observer.

The problem is that observers in Rails are kind of like ninja callbacks: they perform the same function as callbacks, they just work in the shadows. Unless you look at the file system, you are very likely to forget Observers even exist in your application.

Furthermore, observers are assigned to their appropriate class when Rails starts up, and Rails starts up when you run your tests. Once again, you’ll start feeling pain in your tests first, because in order to avoid observer calls in your tests, you will need to either create all the dependent objects or install a gem such as no_peeping_toms. Just like callbacks, observers run every time their condition is met.

Aside: Herman Moreno wrote a good post on undocumented observer usage: Fun with ActiveRecord::Observer.

Why Are Callbacks So Problematic?

In his post on ActiveRecord, Caching, and the Single Responsibility Principle, Joshua Clayton noticed “after_* callbacks on Rails models seem to have some of the most tightly-coupled code, especially when it comes to models with associations.”

It’s no coincidence. “before_” callbacks are generally used to prepare an object to be saved. Updating timestamps or incrementing counters on the object are the sort of things we do “before” the object is saved. On the other hand, “after_*” callbacks are primarily used in relation to saving or persisting the object. Once the object is saved, the purpose (i.e. responsibility) of the object has been fulfilled, and so what we usually see are callbacks reaching outside of its area of responsibility, and that’s when we run into problems.

Solving the Problem

Jonathan Wallace, over at the Big Nerd Ranch, ran into to same problems and came up with one simple rule: “Use a callback only when the logic refers to state internal to the object.” (The only acceptable use for callbacks in Rails ever)

If we can’t use callbacks which extend responsibility outside their class, what do we do? We make an object whose responsibility is to handle that callback.

Before Example

Let’s look at a hypothetical example. This is what we might originally have:

Order model
1
2
3
4
5
6
7
8
9
10
11
12
13
class Order < ActiveRecord::Base
  belongs_to :user
  has_many :line_items
  has_many :products, :through => :line_items

  after_create :purchase_completion_notification

  private

  def purchase_completion_notification
    Notifier.purchase_notifier(self).deliver
  end
end
Notifier ActionMailer
1
2
3
4
5
6
7
8
9
class Notifier < ActionMailer...
  def purchase_notifier(order)
    @order = order
    @user = order.user
    @products = order.products

    rest of the action mailer logic
  end
end

In the above example we can see that when an order is saved, it’s going to shoot off an email to the customer. That Mailer is going to use the order object to retrieve the ordering user and the products which were purchased and likely use them in the email. Pretty simple, right?

In a test, however, any time an order is saved to the database, user, line_items, and products will need to be created, or the purchase_notifier method will need to be stubbed out – Order.any_instance.stub(:purchase_notifier) (Ugh).

After Example

Here’s what happens when we move some responsibilities:

Our Order model is much simpler.

Order model
1
2
3
4
5
class Order < ActiveRecord::Base
  belongs_to :user
  has_many :line_items
  has_many :products, :through => :line_items
end

Here’s our new class:

OrderCompletion
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class OrderCompletion
  attr_accessor :order

  def initialize(order)
    @order = order
  end

  def create
    if self.order.save
      self.purchase_completion_notification
    end
  end

  def purchase_completion_notification
    Notifier.purchase_notifier.deliver(self.order)
  end
end

What we’ve done above is moved the process of saving the order and sending the notification out of the Order model and into a PORO (Plain Old Ruby Object) class. This class is responsible for completing an order. Y’know, saving the order and letting the customer know it worked.

By doing this, we no longer have to stub out the notification method in our tests, we’ve made it a simple matter to create an order without requiring an email to be sent, and we’re following good Object Oriented design by making sure our classes have a single responsibility (SRP).

It’s a simple matter to use this in our controller too:

OrdersController.create
1
2
3
4
5
6
7
8
9
10
11
def create
  @order = Order.new(params[:order])
  @order_completion = OrderCompletion.new(@order)

  if @order_completion.create
    redirect_to root_path, notice: 'Your order is being processed.'
  else
    @order = @order_completion.order
    render action: "new"
  end
end

Wrapping up

As much as I complain about callbacks, they’re really not bad as long as you remember the rule: “Use a callback only when the logic refers to state internal to the object.” And really, that can be applied to any method.

When you start to feel those first twinges of pain from your tests, whether from callbacks or otherwise, consider if what you are trying to do exceeds your class’s responsibility. Creating a new class is a simple matter, especially compared to the pain and frustration caused by not doing it.

Many thanks to Pat Shaughnessy for proof-reading and providing feedback.

Determining and Encouraging Developer Growth

Excitement, frustration, discovery, passion, elation, disappointment, hunger, failure, conquest, defeat, insight, freedom, dominance. These are not subtle words, and I’ve chosen them because they are descriptive of programming, and more specifically, growth as a programmer. Not one word standing above the others, but all of them, in any order, and of varying durations. Do you know these words? Do you know them now, or are they a memory?

I’ve been thinking a lot lately about how to determine if you’re growing as a programmer. It’s easy to see growth when you are first beginning; you see the progress of acquiring knowledge. But as your mastery increases, quantifying growth moves from that based on knowledge, toward a growth based on understanding and application. What are the metrics for determining growth then?

An Experiment

To give us an idea if we are growing, let’s try an experiment. Answer the following questions:

  • List three new things you’ve learned in the last week about your current technology of preference.
  • What new idea, concept, pattern, or technique have you played with or tried to use in the past week.
  • What was the last technical book you read for fun? When did you read it?
  • Do you program outside of work? (For fun, not freelancing)
  • When was the last time you had an exciting conversation with a peer about programming?
  • Do you look forward to going to work?

Did your responses to those questions give you an idea about your current state of growth? Simply put, the best metric for determining if you are learning and growing as a programmer - probably as anything - is this: “Are you having fun?”

So, are you?

Go back to the first sentence of this post. When in your programming career have you felt those words most intensely? When you were learning, right? But weren’t you also enjoying yourself? Weren’t you having fun?

Being Stuck

If you had trouble providing positive answers for the questions above, maybe you’re in a bad spot. I know what that’s like. I know what it’s like to have every idea shot down because that’s “not how we do things.” I know what it’s like to have your creativity constrained because “failure’s not an option.” I know what it’s like to want to do better, but be told “it’s good enough.” I know what it’s like to be stuck.

Being stuck is a horrible state to be in. Maybe you’re stuck because of the technology you’re using, or maybe it’s your boss or your organization, maybe it’s the system, but whatever the case, there you are, unchanging, unmoving, not growing, stuck.

Needless to say, being stuck is not fun.

Encouraging Growth

The whole premise of this post is that if you’re having fun, you’re most likely growing as a developer; if you’re not having fun, then you’re not growing as much as you could. If you’re not growing as much as you would like, then something needs to change, and maybe several “somethings”.

What follows is a list of some ideas you should try in order to rekindle your love and excitement for the art. This is not an exhaustive list, and I would love to hear from you what things you’ve tried to get the development juices flowing.

  • Keep lists of researchables: I have a list - it sounds more organized than it is - I use to keep track of words, concepts, and ideas that I want to research. When I get a few minutes (between test runs) I go and look things up.
  • Develop a low pain threshold: We create applications to solve problems. Pay attention to those little annoyances and find a programmatic way of solving them. e.g. Be annoyed by the way your editor behaves and find a way to fix it.
  • Play more:
    • Take some time to tweak your configuration files; especially emacs, VIM, Git, or shell configs.
    • Experiment with a new library or language
    • Force a limitation on yourself: examples, try to use recursion instead of loops; use methods instead of constants; read source code in place of documentation; etc. See also Creative Limitations
    • Participate in a Hackathon
  • Find other developers who are passionate and start hanging out with them, especially if they’re better than you.
    • Check out your local user groups
    • Go to conferences
    • Find a mentor
    • Find a way, but make those connections
  • Start contributing to a FOSS project
  • Try playing with some Arduino or Raspberry Pi projects?

The point is to play and to have fun, and to remind yourself how much fun programming is. Yeah, at times programming is difficult and sometimes it’s even a chore, but you know from your past that it doesn’t have to be that way, and you know from your experience that it shouldn’t be that way. If you are at a point where you find yourself incapable of growth, maybe it’s time for a change; maybe a drastic change.

Because, let’s face it, “If you’re not having fun, you’re doing it wrong.”

Workload Based Marketing

I’ve been working through the book,“Get Clients Now,” as part of my never ending quest to attract and develop new clients. In the book, the author suggests you choose ten activities you can complete on a daily or weekly basis over a period of twenty-eight days. As I was discussing with my wife some of the activities I was considering (blogging, answering StackOverflow questions, attending networking events, reaching out to contacts, etc.), she stated rather bluntly, “You’re setting yourself up for failure.”

It sounds harsh, but it was really what I needed to hear. My wife worked in sales for a number of years and she recognized immediately the effort required to complete all the activities I had on my list. More importantly, she understands me and the effect it would have on me.

You see, as of this writing I am finishing up two projects and I’m gearing up to start three new ones - one which includes an unfamiliar technology. My wife knows that if I meet all my clients’ needs AND attempt to meet all ten of my marketing goals, something will have to give; probably a lot of somethings. And because I’m highly goal oriented, she knows I would beat myself up for not meeting all my expectations, and waste a lot of energy and time trying to figure out why I couldn’t get it all done.

My wife’s years of sales experience helped her recognize the obvious: I was trying to do too much. Part of what kept me from recognizing the same was my own inexperience with the demands of marketing, the rest was me blindly following recipes out of a book.

But from her insight and fresh perspective, I’ve come up with a new marketing strategy for myself which I’ve dubbed…

Workload Based Marketing

It’s not rocket science, and it’s certainly not an earth-shattering discovery, but it was eye-opening for me and where I was at. It starts with these three rules:

1. Focus on Current Clients First

Here’s the deal, you already have actual clients. Marketing represents clients you might get, and who might have money. If you have to choose between marketing and investing in relationships with your current clients, choose the latter; it’s the only decision guaranteed to pay dividends every time.

2. No Marketing Effort is Too Small

Like I said, clients always come first, but I also know none of us are heads-down 24/7. There’s always time in a week for at least something. Maybe it’s making a couple phone calls one day, eating lunch with a contact another day, or just getting a paragraph or two on that next blog post.

The point is to keep up the momentum. Momentum from small efforts can lead to big opportunities.

3. Waiting is Stupid

In “Get Clients Now”, the author instructs you to start your system on a Saturday. I had planned on starting mine on the first Saturday of the new year, after the holidays were over.

My wife asked, “Why do you want to wait to find clients?”

Ummmm….

The Plan(s)

With those rules in mind, let’s look at the plan itself.

Based on the name alone, you should already get the basic idea of “Workload Based Marketing”: if you have a lot of work on your plate, don’t push yourself to market so much; if your workload is light, increase your marketing efforts accordingly.

More than that, though, and before you start anything, devise plans for yourself which you can execute according to the intensity of your workload. To keep it simple, create three plans: one for when your workload is light; one for when it’s moderate, and then one for those times when you’re swamped. For example, I’ve created plans for myself based on possible workload, each with a variety of activities suggested from “Get Clients Now” or from my own marketing preferences.

Having these plans established ahead of time allows you to “just go on autopilot” rather than burning a lot of cycles trying to figure out what to do. You won’t need to waste time thinking about things, you’ll just be able to go. Organizing your plans around a weekly schedule is probably the simplest solution.

“Get Clients Now” is a great book, and every freelancer should read it at least once and consider the author’s suggestions. In it, she gives some great advice for getting started, setting goals, and strategies for the different stages of the marketing cycle. But remember also, no system is perfect. Adjust whatever system you settle on to match your own needs, and prepare your plans ahead of time so that when storms hit, you can be ready with something to do, rather than wasting precious time and energy.

One last thought, review your plans in light of the end goal: right clients, right projects, and right price. Make certain your strategies and tactics are aimed at the right audience. Use your time wisely on existing clients first, and then pick the plan matching your workload to find the prospects who fit the profile you desire.

Why Your Company Should Sponsor Tech Conferences

Note: In this post, when I refer to “developers”, I’m generally referring to programmers, DevOps, and digitally creative types.

For the past couple of months, I’ve been reaching out to companies, asking them to sponsor Ruby Midwest 2013, a technology conference I’m helping to organize. Every company I’ve had contact with has been super nice and many have chosen to support us either financially or with products or services. Some companies have chosen not to sponsor for a variety of reasons, and that’s cool, I get that. There are definitely reasons not to become sponsors. But in this post, I want to look at some of the results decision-makers are expecting, and some which they might not consider, and which, if they do, might change their outlook on sponsorship.

Just looking at sponsorship from a general perspective, most companies are seeking to advertise, increase brand awareness, make sales, and maybe find new employees. The hope is that the amount of money invested will be offset by what is returned. And of course this works, which is why you see some of the same companies sponsoring so many conferences.

Take, for example, publishing companies O’Reilly and Addison Wesley. I can’t imagine a conference which didn’t have books from either of these companies to give away. The results of these minor investments are advertising and increased brand awareness (people get to see the books handed out), and increased sales by way of the book recipients buying more products from the same publisher, and also from them telling their friends or writing reviews. It’s nothing but “win” for these guys.

Since I am currently seeking sponsorship for Ruby Midwest, I am a little hesitant to say this, but investing in a conference may not be the best choice for a company if it is only looking for sales and advertising. Part of the problem is that those running the conference are usually developers (like myself), and, well, we’re not really known for our ability to sell and market companies and products (or even have “normal” conversations.)

The other part of the problem is the target audience. Most people attending tech conferences are company-employed developers (i.e. not the decision-makers). So even though a company might be selling the new whiz-bang product, we may not be in a position to do anything about it other than make the case to our management, (and again, we’re not really known for our ability to sell.)

Selling books or developer tools is one thing; developers are usually the decision-makers. Selling other types of products, especially those focused on companies, are a different matter; developers, even if they’re the target audience, may not be in a position to purchase.

And so at this point you may be asking yourself, “If we’re unlikely to make sales, get a good advertising push, or increase our brand awareness, why should my company sponsor a regional conference?” In short, by sponsoring conferences, you are telling your development staff that you support them and their passion, you inform the local development community that you “get it”, and you add to your reputation as a company who understands technology. Let’s break this down a bit.

I’ve written about this before in my post on ”Attracting Good Developers”, but in short, developers want to know they’re supported and needed. You can do that in a number of ways (and you should) but one way is to invest, not just in them (which you should), but also their interest: i.e. conferences they want to attend. By doing so, it’s understood that your company is taking an interest in their growth and improvement. That matters.

When you sponsor conferences, you not only tell your own development staff you support them, but that you support the local community and you’re a company who understands technology. Believe me, we notice.

Don’t underestimate the value of this. Good developers want to work for “cool” companies, because, well, to be honest, it makes us “cool”. Not “cool” like James Dean, but “cool” as in, we are good enough to work there. This can be a huge confidence boost, and can unleash hidden potential. Developers who once just thought of themselves as the line-workers of the 21st century, might now - with the added confidence - begin to think of themselves as something more, and increase their contribution to your organization.

Used with permission from KCITP’s post: 3 Reasons Why Developers Need To Attend Hack The Midwest

Alright, let’s pretend my arguments have convinced you to sponsor a conference, which ones to you sponsor? Here are three things to look at:

  1. If you’re local, stay local: If you are a company localized to a certain city or area, sponsor those conferences and developer communities resident in that area; in your market
  2. If you’re big, go BIG: If you’ve got offices all over the nation or world, you should probably be sponsoring the major events: OSCon, PyCon, RubyConf, Velocity, etc. But hey, don’t forget the to sponsor the regional conferences your offices are located.
  3. Stay with what you know: Unless you are trying to recruit talent from another technology area, don’t feel like you have to sponsor everything; just sponsor the conferences relevant to your company.

Tech conferences occur in every semi-major city around the globe and every company with a good development staff or who wants a good development staff should be sponsoring at least one a year. Sure, sponsorships can bring in new sales extend your company’s brand, but more than that, it can improve your company’s reputation among your own staff and in the development community.

In the end, sponsoring conferences isn’t just about investing in your company’s representation of itself, it’s really about investing in your development staff and in your company’s culture. It’s worth it.