Category: Self-employed

Back to the Future

I’m happy to say that I’m back in the lower-48 after spending a fantastic summer in Alaska and taking an almost month-long road trip through Alaska, the Yukon Territory, British Columbia, Washington, Oregon, California, Nevada, Utah and Colorado. We’ve settled into our new lives in Fort Collins, Colorado, and I’m most excited about having reliable internet and cell phone service again.

I keep describing Alaska as 1996 to people, and it’s not too far from the truth. The cell phone service is very limited, our home internet came out of a cellular MiFi device (remember those?), and shipping anything took two weeks. Oh, and there’s still a working Blockbuster Video in the town where we lived.

Being in Fort Collins feels a little like returning to reality, but a good reality with a nice Target and lots of good restaurants. I’m having a little trouble getting my feet wet here, but I’m planning to start joining some networking groups next week and have a few events on the calendar. It helps that my parents are only about 90 minutes away in a South Denver suburb.

As for my future, I’m still working for private clients over at Jonas Digital (accepting new clients now!) and am considering taking on a part- or full-time position at a company here in Fort Collins, if I can find something that is a good fit for me.

Adventure Kitty survived his trip to Alaska and back and is happy in our new home. I am woefully behind in blogging our adventure over at Last One Up, but I’m planning to take this chance to work on getting caught up with our stories from the summer as late fall sets in over the Rocky Mountains and days get too short for after work adventures.

Here’s to a new adventure!

Things I Wish I Knew Before I Started My Own Business

I graduated from college 10 years ago, and since that point, I have had a full-time, salaried job, until June of this year when I decided to go out on my own and start my own freelancing business.

Now that I’m about six months in, I have a list of things I wish I’d known when I started. Some of these things are practical, some are philosophical, but all are good advice for anyone thinking about going out on their own.

  1. It’s better to start with systems than to develop them as you go
  2. Pay for the accounting software
  3. Your business name doesn’t matter nearly as much as your business structure
  4. Working for friends can be a blessing, but it can also be the hardest client relationship to manage
  5. Insist on signed estimates and deposit checks before starting a project
  6. Hold on to your free time. Just because you work at home doesn’t mean that you’re always at work
  7. Be confident in your abilities, but know when to ask for help
  8. It’s OK to outsource things you’re not good at (more on that in my next post)
  9. The worst part of any job is going to be billing – dealing with money sucks
  10. Save everything – receipts, business cards, notes, emails, mockups, draft documents, checks, etc. – you never know when you’re going to need to refer back to something
  11. And above all – remember the reason you’re doing this – whether it’s for creative freedom, the ability to work from anywhere, the ability to spend more time with friends or family, remember that reason and hold on to it. There will be hard, horrible days where you’ll wish you could go back to a full time job, or where you’ll want to fire clients, resign accounts, and quit projects. On those days, it’s important to think about why.

    For me, there are multiple reasons why freelancing works for me, but one of the biggest is that life is short, and there is so much in this world that I want to see and do, and so when I have a hard day, I remember a raft trip down the Nolichucky river on a Wednesday morning, and how it was a perfect day, and how in my previous jobs, it was a day I would have had to miss, sitting instead in my office while the leaves went from green to yellow to red, and then fell off the trees. Those are the kind of days that make it all worth it.

Do you use checklists?

As I fly home to Denver today, I’m wondering what tools other developers use when setting up projects.

I have a questionnaire that I sent to clients before quoting a project that helps me get a sense of the type of website we’re going to build.

But I’m thinking of developing a series of checklists for new projects.

  1. Collecting Logins for Clients with Existing Websites
  2. Setting up a new WordPress installation
  3. Plugins
  4. Social Media Scheduling
  5. Analytics and Adwords

Any others you’d like to see?

Keeping up with the cutting edge

One of the things I’m loving about self-employment is the opportunity to continuously learn new things. From changing technologies, to new projects, it seems like every week presents a challenge that I have never conquered before.

Last week, I worked my way through some social media best practices courses that served as a refresher course for me as I launch into a social media project for a client. This one in particular from Hootsuite has a series of videos and quizzes that help you work through the changing landscape of social media.

It was great for two reasons:

  1. I refreshed my knowledge, staying up-to-date on the latest best-practices for social media
  2. And, it reminded me of the items that I needed to describe to the client to get the best elements for their profiles and posts

Now that I’m working for myself, doing these kinds of things can be hard. While I’m running through these courses, those are not “billable hours” for me. But it improves my work across many clients and lets me reset my brain for new projects.

How about you? How do you balance the need to do continuing education and research with the need to create billable work?

Open Source is Ugly

This is the fifth in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

One of the themes of the design track at All Things Digital this year was how to add design to Open Source projects. Apparently, design has not been a priority for Open Source in the past, but is becoming an important part of a lot of projects.

The session called Open Source is Ugly on the UX/UI track gave a good overview of why design is important for projects. All projects have users. Sometimes these are the general public, but often in Open Source, these are internal, or specific users, like developers who work in a specific technology, or users who are already using another project that can be extended.

For this reason, developers often don’t think about design as a top priority, but user experience is very important, from Branding to User Interface.

This speaker, Garth Braithwaite from Adobe, talked about choosing a styling platform, integrating design to your project, and giving developers a crash course in design using free online tools, which I plan to check out soon.

You can check those tools out here: Speakerdeck

(Garth and I, incidentally, had a very funny twitter interaction the next day about why my four hour drive should take precedent over the after party. You can check that out and follow me onhere.)

GitHub for Beginners

This is the third in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

The second session I attended at the conference was called “How to Start an Open Source Project” and it dealt with the nuts and bolts of GitHub and open source licensing and all those other intimidating things that keep people from starting and contributing to projects. The presenter, Don Schenck from Rackspace, gave a great overview of the process, from getting an idea, naming it, creating the repository (repo) and starting with the first file.

One of the key things he said to us was “once you publish your code to GitHub, it’s not your code anymore,” which is a way of saying that open source projects belong to the community. When starting a project, you need to be starting it with that in mind. If you want to control every aspect of it, then open source may not be right for that project.

He also talked about the need for a development plan: what needs to be done, in what order, and how to get people to contribute.

I’m still not sure I’m ready to create my own project on GitHub, but I’m at least a little more confident that I might contribute to one.

Conference Notes: All Things Open 2015

Last week, I attended my first All Things Open conference. The conference focuses on Open Source software and includes speakers from major industry players like IBM, Microsoft and Red Hat.

This conference was a reach for me. I am not a backend developer and know very little about server-side technology or app development. But it was an important reach for me for a few reasons.

First, working from home means not having people to bounce ideas off of and not having those informal conversations that allow you to get new ideas and see cool things that other people are working on in person. Conferences can fill some of those holes for me.

Second, while contributing to open source software can seem intimidating (WordPress is Open Source), it shouldn’t be. The community is overall supportive of new people joining projects and wants to find new ways to include people who believe in the mission of open source.

Third, and possibly most importantly, spending time with people who are passionate about what they do, whether it’s the same thing I do, or something completely different, is energizing and regenerative. I came home from this conference convinced that I can build that app, finish this project and do something new.

For more on what I learned at the conference, check back in a couple of days.

This is the first in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

Design at the Speed of Digital

The web changes quickly and clients expect us to keep up. In this always on age, clients often want design projects turned around within a few days, if not hours.

The traditional agency is used to having a lot longer to do its work. Print deadlines are set many weeks in advance and work is signed off on a weekly basis, not hourly. But when you’re talking about small graphics projects for digital properties, or even iterative web design, those timelines may no longer work for your clients.

But how can you continue to produce excellent design work while working within these newly compressed timelines? Sometimes you just have to wait for inspiration to strike, and sometimes that doesn’t happen overnight (or over the next hour – whatever the case may be).

First, be honest with your clients about your workflow. Especially if you are single-person shop, like I am now, you need to let them know not only that it takes time to produce design work at the quality that they hired you for, but also that you have other commitments, and, at least in my case, you can’t rush the process or you’ll get flawed work that makes no one happy. No one, NO ONE is less happy with flawed work than I am. Not even the client who is paying for it.

Second, you need to re-evaluate your processes and see where efficiencies can be found. Some clients don’t need three mood boards, let alone six. The curse of digital can also be the benefit. You can check in with clients more often which means you don’t have to do unnecessary steps to hone in on a design.

What is it that you do, exactly?

How many times in the past three months have I heard that question? So, so many times. What’s worse, I don’t really have a good explanation for it. My career services counselor from grad school would be so disappointed that I haven’t perfected my elevator pitch yet, but there’s a reason for that.

This excellent article from CSS Tricks explains exactly why it’s hard to explain what I do.

Working in the web industry, my job title and job description is ever changing. Add to that the fact that I have experience and interest in doing a vast number of things and you’ve got the problem outlined in that article.

According to his descriptions, I am mostly a “front end developer” with some “content strategist” and “SEO specialist” elements mixed in. But I also do digital advertising, social media, and other tasks on a fairly regular basis.

How about you? What job title do you give to people?

90 Percent of the Time it Works Every Time

Repeat after me: When in doubt, it’s almost always a plugin conflict. It’s almost ALWAYS a plugin conflict.

You know how sometimes, when you’re having a problem at work and you can’t figure it out, you just need to step away for a bit and the answer miraculously comes to you?

I have a very complex site I am working on, and for some reason, a perfectly coded membership system was generating 404 pages for all member profiles. The pages existed, the code looked good, but there came the 404 page, all the same.

Since the site is complex, with multiple layers and plugins to generate forums, a membership system, a link to an email service provider, and other items, I assumed that the code was the problem and started to dissect the files that were creating the profiles, to no avail. I couldn’t figure out what was causing this 404 response.

So I did what most developers would do, I googled it. And it was at that point that I was reminded – here it comes – when in doubt, it’s almost always a plugin conflict.

I turned off all the plugins except the membership forum system and voila! a working profile page. Then I turned the plugins back on, one by one, and discovered that the plugin that was generating the 404 page was the plugin that had the conflict (this should probably have been my first idea, right?).

So… a problem that caused me a sleepless night and several hours of work could have been pretty easily fixed by just remembering that – when in doubt, it’s almost always a plugin conflict. Despite the complexity and customization of the site, it’s almost always a plugin conflict. Despite my growing fluency in the code, it’s almost always a plugin conflict.

Because – all things being equal, the simplest explanation is almost always the right one.

Loading...
X