Category Archives: News

Goals for 2014

I should have posted these at the beginning of the year but I didn’t even have time to think about them until last week. Here’s a list of things I’m trying to accomplish this year (in and around my business).

Gross a Large Amount of Money

It is always nice to have a number to shoot for so I picked a big round one that I know is achievable but I’ll need to push myself to hit. Between my contract work and other sources, I expect to reach this number, assuming my projects go smoother this year than last.

$200 per Month from Affiliate / Niche Site (by end of year)

BoostWP, a business that I recently launched with my former client and now partner Chris, provides high quality products for people using WordPress as a marketing tool. I figure it is probably a good idea to actually use the products I build so that I can become intimately familiar with the challenges that our customers will face.

What better way to do that than to dogfood the products I’m building and use them to their intended ends? I essentially know nothing about internet marketing so I’m hoping $200 per month isn’t a crazy goal. I guess we’ll see!

Generate 25% of Revenue from Product / Subscription Sales

Did I mention that BoostWP launched recently? I really believe in its potential and am setting the bar high in terms of calling it a success. By the end of the year I want to be generating at least a quarter of my income from non-hourly work (e.g. product or subscription sales) and I expect BoostWP to make that a possibility. There might be other products (keep reading this post for more info) but BoostWP is where it’s at.

Write 90 Blog Posts

Did you notice that I’ve been writing a lot more recently? I did 30 days of writing back in September of last year but since then I’ve written almost nothing on this blog. I’m aiming to change that for two reasons. One, I love writing (especially teaching through writing). It is a good release for me and allows me to express myself in a way that I normally don’t get to. Second, I want to continue to build a voice (as was my intention with the 30 days of writing mentioned previously).

I plan to publish 90 posts this year. I’m not sure what they’re going to be about or how long they’re going to be, but I’m hoping you’ll read at least some of them.

Write Another Book

I wrote a book in 2010 and I didn’t have the best experience. When I finished the book (with the help of a co-author), I was proud of the fact that a published piece bore my name, but I wasn’t proud of the contents. It was out of date as soon as it hit the market and I hated that. On top of all that, I made almost $0 from the book considering all the time I invested in it. It has been a good marketing tool for years, but it’s time to write another one.

This year I’m going to self-publish a book. I’ve been watching as a lot of people I follow and respect have released pieces covering topics that reflect their expertise. I firmly believe I can do the same. I’ll talk more about this in upcoming posts, but I’ve written an outline that I believe will lead to the proper amount of content and will deliver a large amount of value to both businesses and individuals.

These are my business goals for 2014. I’d love to hear yours if you’re willing to share in the comments or on your blog!

How to Write a Great Feature Request or Bug Report

There are few things more important to a project then clear and actionable direction. If you’re a freelancer, knowing what to do next makes your job infinitely easier. If you’re a client, detailing what you’d like to see with as much clarity as possible will ensure you get the end result you want.

Writing actionable feedback takes practice. That being said, there are a few concrete steps that will make feedback better for everyone involved.

Describe the Current and Desired Behavior in as Much Detail as Possible

As much as it pains me to say it, this does not go without saying. When giving feedback, you should go out of your way to explain, in as verbose a way possible, what you expect to see or experience. The preferable way to do this is in a step-by-step format given a certain scenario.

For example, if you’re testing a custom registration process for a web app, perhaps you expect to see validation of fields happening as you fill them in. Instead, field validation is happening only when pressing a “Register” button on the form. Here’s what you might write:

The username, email, and password fields are not being validated until a form submit happens. I am performing the following steps:

  1. I click on the name field to focus it
  2. I enter an invalid username
  3. I press tab or click to advance to the next field
  4. There is no indication that the name is invalid
  5. I click “Register” on the form
  6. A message displays indicating the username is invalid

I would like to see the following occur:

  1. I click on the name field to focus it
  2. I enter an invalid username
  3. I press tab or click to advance to the next field
  4. A message displays indicating the username is invalid

This is much more useful than an abbreviated description that might read as follows:

When I enter a bad username I don’t know it is invalid.

While accurate, the second version doesn’t explain the desired behavior in any way or allow for reliable replication. The recipient of the feedback can guess what is going wrong and what the desired behavior is, but can’t be sure until she attempts a fix or asks more questions, lengthening the process to get to the expected end result.

Provide Supporting Materials

Any time you’re testing something that requires input in some form, you should provide your inputs with any written feedback. For example, I recently build a form parsing engine for a client which would automatically detect appropriate labels for each input detected. Unfortunately, the engine couldn’t appropriately parse certain forms that would be popular with the market the surrounding product was entering.

The client provided me with samples of the forms that were not being parsed correctly without prompting. This gave me the ability to test, diagnose, and remedy the problem that had been discovered. Without the forms, I wouldn’t have been able to move on the problem with any speed.

As a simple rule, provide any of the following related things with each bug report or feature request:

  • Text you entered into a form field
  • Files you uploaded or used as input into a desktop application
  • Error messages you received (if any)

Take Screenshots and Record Screencasts

Have you encountered a visual bug? The most useful thing you can do is take a screenshot and provide it with any feedback. Whether a UI element is positioned incorrectly or you are seeing an odd rendering bug in a corner case, a picture can be worth a thousand words.

How should you take your screenshots? All operating systems come with a facility to capture the current output of the screen. You can reference for information on how to take perform the correct steps.

If you have access to a graphics editing application, adding text and arrows or lines pointing to the elements you’ll describe in text is very helpful.

While screenshots are awesome, there is a class of bugs that require capturing motion on your screen. Perhaps an animation is running incorrectly or some type of interaction with the application causes an unexpected result which is hard to describe. These are the perfect situations to record a short screencast.

There are a variety of screencast tools to choose from. If you’re looking for the absolutely easiest and quickest, I recommend Screenr. I prefer this tool because it allows you to download an mp4 formatted file after uploading to this service, which you can upload to a project management tool or send via email.

A Real World Example

Recently, I was working on a WordPress plugin that integrated the embeddable widget into a WordPress site. While doing so, I encountered a bug and reported it to the developers of the site. Here is what my bug report said:

While I was checking out the widget functionality you guys have developed (using my hometown). I found what I think might be a character encoding issue with Chrome on Windows 8.1. The red flag warning icon character doesn’t show up correctly in that browser for some reason. It displays correctly in every other browser I tested, though, including Firefox and IE11.

I’m attaching a screenshot that illustrates the issue.

I provided the following image for reference:


As you can see, I provided a description of the behavior, what I did to test the issue, and (most importantly, in this case) a screenshot that clearly illustrated what I was seeing.

Did I Miss Anything?

These are the steps I follow and ask my clients to follow when we details changes we’d like to see. Do you have any other tips or pointers? What do you like to see in a bug report?

30 Days of Writing

I’m doing a little experiment this month. I’m going to write a moderately substantive post on this blog every single day. Some of these posts will be technical in nature, similar to my post about adding a setup fee to a new Stripe subscription, but most will cover things that require less upfront effort and discovery based on the myriad experiences I’ve had running my business.

This is a public commitment on my part. If you read this post and see me skip a day, please contact me via Twitter or Skype and tell me to get it done.

Why Am I Doing This?

Primarily, I want to be a better writer. I want to develop my ability to express my ideas concretely and concisely while making the text as compelling as possible. I figure the only way to do this is to practice it – that’s the reason for the emphasis I’m putting on production during the next 30 days. There’s other reasons as well, of course.

Developing a Public Voice

I write copiously as part of my business efforts: statements of work, technical documentation, delivery notes, and testing instructions are just some of the things I write. Add the actual code and you’re looking at a large number of words every single day.

There’s a difference between those things and what I’m trying to do here. All of the above pieces are distributed privately and aimed, almost without fail, at a single person or small group. The language I use in those documents is exceedingly explicit due to their very nature.

I feel that writing for public consumption is very different from the type of writing I usually do. Good public writing is interesting to read and does one of two things. It either teaches how to do something specific or expresses an editorialized opinion on some topic. Both of these things require a writing “voice” with some authority and style.

I Love to Teach

The feeling I get from helping someone with a problem they’re having is amazing. If I know something that can help another individual, I want to share that knowledge. I figure this blog is a great place to do that.

I was at Starbucks with my wife the other day and I noticed someone with a Macbook open and a sketch in front of them on notebook paper. It looked like they were building a website, so I decided to strike up a conversation with them. At first, I was looking to see if they were available to take on overflow work.

It turns out that the person was struggling with some schoolwork that involved building a website based on a Photoshop file. When I told him that I was a web developer, he asked if I would be willing to help him understand how to do what he needed to.

I was so happy to help this individual. We talked about how you break down the structure of a website logically, how to float things into place in order to achieve the desired layout, and what kind of elements made sense based on the content available. He was so grateful that I took a few minutes out of my day and I felt amazing afterwards because I made a real difference in someone’s life.

I want to experience that feeling more often. By posting tips about business and software development publicly, I’ll be able helping many more people than just one guy at Starbucks. That’s awesome!

Public Profile

I’ve come to realize I need to work on my public profile because I essentially don’t have one. Privately, I work with small, medium, and large clients on a variety of interesting projects and have very rarely worried about there not being enough work to do. An extensive referral base combined with existing clients keeps me more than busy enough.

Publicly, though, I might as well be a non-entity. No one has any idea who I am and that’s definitely not good for someone running a business based on personal relationships. If my connections dried up and my current clients ran out of things to do, I’d be pretty stuck.

Being perceived as an expert on the topics I know a lot about will help remedy this problem. I’ve heard there’s no better way to get people to think of you as an expert than to write about the topic you want them to think you’re an expert in, so that’s what I’m going to do.

How Am I Going to Do This?

I didn’t want to go into this process blind, so I’ve developed a very general plan to make sure I actually follow through.

First, I’ll be writing every day before I do anything else. I will spend up to one and a half hours working on content to publish.

Second, I’ll be brainstorming at least 20 topics every Sunday night for the upcoming week. I figure that I can probably get seven good posts of varying lengths out of 20 topics.

Finally, I’m making a commitment to hit the publish button. In the past, I always felt that something had to be perfect before I put it out there. With each passing day, I realize how untrue that is. I can always update or correct something later. For now, I just need to focus on getting things written and published.

Your Thoughts

Do you want to write more? If you do, please join me in this little experiment. I’m sure we can all learn a lot from each other. If you’ve got other comments, please drop me a line below!