Matthew Lang

When I first started freelancing, I thought I had the perfect job. Setting my own hours, working from home and no tiresome commute. These positives are what many people want from freelancing but there's a downside as well.

The downside

Working alone is hard for a number of reasons, but the main reason is that you are in fact alone. You're no longer part of a team, you're on your own trying to build a career with the resources you have available to you. It's not as dire as it sounds, but there's lots of little things you miss when you're working on your own.

The office banter is gone. I worked in a great team of developers a couple of years ago and I do miss the chatting before the stand up and pairing with other devs through the day. You can be the most connected person on Twitter, but it's no replacement for a face to face chat with people.

Then there's the resource part. Everything is on you, and I mean everything. No only do you have to deliver great work, but you also must communicate clearly with your clients, keep your skills up to date, market yourself and about a thousand other tasks that keeps your business running.

The upside

So you're working alone with big responsibilities on your shoulders, but there's an upside to working this way as well.

Having a balanced work life that doesn't eat into my time with my family is why I enjoy working from home so much. Not only do I no longer commute to and from work, but my hours are also dictated by the client work that I do. It's very rare now I work at night now. I fit all my client work in during the day, which leaves me time at night to do work on my own projects, get some reading done but best of all I actually get to spend time with my family.

The other big positive for me is I get work the way I want to work. I get to choose the hours I want to do. Having the flexibility to fit more in my day means that the weekend is left free for more important things like taking the kids to the park or getting myself out on the bike.

I also get to choose the the tools I want to use. It's very liberating to have this choice and not be confined to working with one tool or framework and be restricted by the equipment you can use. I've had my fair share of programming jobs in the past that wouldn't have been my first choice, but now I'm actually in a role where I'm enjoying what I am doing.

The verdict

I prefer this independent way of working. The positives really do outweigh the negatives for me. It's definitely not as easy or straight forward as I first thought it was going to be, but it is providing me with more opportunities to carve myself the career that I want.

Programmers have always got old code lying around. Forgotten applications, libraries, ideas and other files and folders. Remnants of days perhaps when ideas were rife and ambitions were high. I have those days as well. I have an idea for something, I mock up a quick test with some code and then most of the time decide that it's not simply worth my time investing in it further. What remains behind is a filing system littered with dead folders and files.

Today I started cleaning up those dead end projects.

I deleted old applications that I'm not hosting anymore, deleted ideas for applications and products that I know are not going to work and also deleted a few repositories from Github account. I cleared out a few forked repositories that I had high ambitions of working on but haven't contributed to them.

From there I then started to remove a few applications from my MacBook Pro. I only deleted a few applications, but better to remove them than to have them sitting idly doing nothing. More deadwood gone.

Then I moved onto the online tools and services I subscribe to and removed a couple of them also. A few more dollars back in my pocket each month and that great feeling of removing yourself from a service or subscription that might distract you with an email each week, but you quickly delete it.

Just like clearing your desk or work environment of deadwood files, folders and other junk on your desk, it's also important to remove the digital deadwood as well. Start with your laptop or tablet and remove the applications you don't use, the old folders and files that are no longer relevant. Once your immediate work environment is clear, move on to your work environment in the cloud and trim those services that you don't use anymore.

Keeping a clean digital environment is just as important as keeping your physical work environment clear. You might just end up saving yourself some money or even getting some space back on your laptop. Even better, you might just have rid yourself of a few unwanted notifications each month.

At any one time there are usually three devices sitting on my desk. A laptop, a phone and a tablet. They all have different apps running on them but some of the apps they use are for the same service. So for App.net I have an app running on my laptop, but a different app running on my phone and tablet.

Here's the problem. I haven't really paid too much attention to configuring notifications for each of the apps so sometimes I end up getting multiple notifications going off on the different devices for the same event. For example, in App.net when I get a new follower, I get an email notification in my phone as well as a notification from Felix, and also a notification on Felix on my tablet. Just little bit overkill if you ask me.

So here's my question to all of you. What's your strategy for dealing with notifications on multiple devices?

I sit in front of my laptop for most of the day, so ideally most of my notifications should come through there, but then what notifications should I enable for my phone? Are there any type of apps that you recommend I should completely silence?

If you've got any thoughts on this then please reply back to my original post on App.net or drop me an email here. I'd be really interested to hear your views on this.

... with our guide, Kurt Harden.

via PedalConsumption

My wife mentioned the other day that she was thinking about her New Year's resolution for 2014. I said to her, "Did you keep last year's resolution?". "No", was the reply. In fact she freely admitted to never keeping resolutions.

"What's stopping you from starting now?", was my next question. It got her thinking and she's decided to start making plans now to implement some positive changes to her health and fitness.

Why do we feel the need to wait for a milestone to pass before we start something? New Year's resolutions are never kept. I never kept mine. In fact, it was only a few of years ago when I abandoned the whole idea of starting and keeping a New Year's resolution. I do keep a theme for the year that I can group goals under, but that's all it is. A theme for the year.

Don't wait.

Start now.

Write down what you want to achieve next year now and start making a list of next actions towards making those achievements. Do it now.

What's the point in waiting for a holiday or birthday to roll by before you start taking action? Age is just a number and so is the year. There's nothing special about them that will make you achieve your goals.

Get the notepad and pen out and start that list now. Start working towards your goals now. Get the jumpstart on the year and start it knowing you've already achieved something before the this year is finished and that the next achievement is just around the corner and not 12 months away.

New Year's Day is just another day on the calendar. So is today. Don't wait for the end of the year. Start now.

I can't wait to get NB's latest book.

I've been building web applications in Ruby, on a full-time basis, for a couple of years now. During this time I've been exposed to a number of different testing strategies and approaches. Test-Unit, MiniTest, RSpec, Cucumber, Steak and many more. I've used many of these test frameworks to some extent, but despite the many choices I have in this area, I'm still befuddled by the right tools to building a web application in Ruby using test driven or behaviour driven development. The Rails framework has shipped with Test-Unit for years but the most popular testing framework is probably RSpec.

In order to quell my confusion, I thought I would expand on the three approaches that I have used most often in my time using Ruby.

1. The True Agile Approach

Perceived by some as the holy grail of testing, and in some cases with an equally preachy opinion, is the true agile approach. Being part of an agile team with a customer on hand to flesh out user stories, daily stand ups, retrospectives. Just about everything that embraces an agile approach to building software.

In this approach, test driven development and behaviour driven development tools reign supreme. If your approach is TDD, you'll most likely be using RSpec or Test::Unit for testing all aspects of your web application. If your approach is BDD, then it's Cucumber all the way. This is pretty much a no brainer really. With so many hands available for development, it makes sense to always write tests first.

2. The Solo Developer Approach

The true agile approach is fine when you're part of a team, especially when that team advocates pair programming and you have a customer on hand to flesh out user stories. What if you're a developer with your own product or service though? You understand the business domain enough to eschew the behaviour driven development approach but you still want to test your product?

I had this problem with the early iterations of Journalong. I understand the business domain, so is it really necessary to use a BDD approach? Can I simply just switch to a TDD approach with Test::Unit or MiniTest?

I'm still on the fence about this.

3. The Side Project Approach

This is simple, and I embrace this approach 100%. No testing framework or just enough tests to handle the complicated stuff. Hacking on your own ideas is a good time to really explore the frameworks and languages you are doing. Getting these setup correctly with all the proper test frameworks can be a chore though. If it's just an initial idea or throwaway solution you're working on then why bother investing the time in writing tests?

I want to be a good developer and develop solutions that are thoroughly tested but when was the last time you just hacked on a bit of software to try something out? If I know enough of the framework and language to get by then I don't bother writing tests. It might take me an hour to come up with something or half a day, but if that's all it takes then why bother getting all the correct bits in place to test it.

There's definitely a time and place for testing strategies in development, where you're part of a team building a product or building a revenue generating product or service on your own, testing strategies can give us the confidence we need to ship code on a frequent basis.

For my own ideas though I would rather roll my sleeves up and get into the parts of the code I know or even try new things with a part of the language or framework I haven't used. Kind of like code exploring, filling in the blank edges of the map if you like.