Matthew Lang

My friend Curtis has been busy penning a new book.

Congrats on the launch Curtis!

I read an article today where the author outlined her opinion on using the right tool for the job. Actually it was more like an advertisement for the authors book, but that isn't the problem.

The problem with the article is that the author immediately made assumptions about the person she was meeting with. Just because the person showed up with a pen and notebook, the author made an assumption that this person was using the wrong tool for the meeting.

Here's the thing. Everyone has their own choice that works for them.

Whether it's the latest tablet on the market, a netbook or your own choice of pen and paper, the tools that work for you the best are the ones that you have tried after eliminating countless others.

Let's look at text editors. A text editor is what programmers use on a daily basis. Working with code means that programmers need shortcuts to frequently used code templates, viewing files side by side and other key features.

I've chopped and changed over the last couple of years but I have always went back to the one that I work with best. Yet I know other programmers that have opted to use other text editors. Do I criticise these programmers for their choice?

No. It's what works for them.

I know better than tell someone that they're using the wrong tool for the job.

Can't wait to show my oldest son this!

via Distracted By Star Wars

It's been a busy couple of weeks freelancing. However there is one thing that I didn't factor into working this way and that was making time for building my own products.

Working on your own is demanding. You're aiming to deliver the best work you can within a set allotted time for your client as well as keeping an eye out for more opportunities in the future. I've only just seen the tip of the iceberg with freelancing. I'm sure there's a lot more things I need to be doing.

By the time I've put in a days work I'm mentally exhausted. The prospect of sitting at the computer for another hour at night now doesn't seem so appealing.

Now that I'm more flexible though in the hours that I can do, I need to start thinking about etching out some time during the week to build and market my own products. Cutting back to four days a week would allow me that chance. As well as working on products it would give me a chance to do some writing as well.

I like the flexibility that freelancing offers but I need to make sure that I am giving myself enough time to work on projects if my own.

The other problem is that I'm still stuck in the typical work week mode. I still feel like I have a job. Granted I'm way more happier working this way, but I should be working out how many days I should be doing a month to earn enough for living and putting some aside for when there are droughts in the work load.

This doesn't necessarily mean doing five days a week, but the balance should be in the favour of paid work until my products can earn enough to swing the balance in their favour.

In the meantime it's back to work.

Estimating. It's a word that can strike fear into people who are new to the realms of programming, project management, freelancing and other careers. The daunting prospect of estimating the length of time at which you will be able to complete a set piece of work.

I have over ten years experience in the realm of software development and sometimes I still get it wrong. I've seen developers get their estimates wrong by a couple of weeks and project managers miss their target deadline by months. So why are estimates so hard then?

The first reason is that the estimate is based on a bigger block of work, rather than multiple smaller ones. Estimating a project from just an outline of the project is a rookie mistake. When you estimate on a large single block of work, you are basically playing a guessing game. In fact your estimate is always going to be wrong when you do this.

Instead, break your big block of work down into smaller blocks of work. The more granular you get, the easier the estimate is going to be. It won't always be correct, but your estimate will be more accurate.The second reason is information. We are limited by our little brains in how much information we can retain when estimating on a project.

When it came to estimating on projects for ERP software customers, I had to remember that different customers had different workflows in their systems. No two systems were the same. I had to factor in that a customer will have specific workflows in their system that I need to either work around or work with. This job was made a lot easier by the fact that I used notes that I kept on each customer's system so that I was ready to make better estimates in the future.

Now I know this might not be easy to do for a new project where you have little information, but carrying any information that is relevant from one project to the next is going to make estimating on blocks of work a lot easier.

Estimating isn't a black art, it's simply something that requires you take the time to break blocks of work down into smaller chunks and if you can, have the right information at hand to make better estimates on those blocks of work.

A single device that can be used on the go as well as having the same functionality as a desktop computer when you dock it!

The Ubuntu phone marks a significant milestone that nobody else in the mobile business has managed to nail yet. It runs the same codebase as the rest of the Ubuntu family, meaning it can be docked and used as a real computer or synchronized with a slab and turned into a tablet.

— Convergence is key by Owened

The only answers that matter are dollars spent. People answer when they pay for something. That’s the only answer that really matters.

So put a price on it and put it up for sale. If people buy that’s a yes. Change the price. If people buy, that’s a yes. If people stop buying,
that’s a no. Crude? Maybe. But it’s real.

— How to price something by 37 Signals

... how can I keep a personal, private journal online?

Having multiple social networks can be a real headache if you're trying to manage them all at once. When I created my App.net profile and made that my new home, I stopped posting to Twitter for a few months. Also I have only just re-created a LinkedIn account in the last few months. Recently I have stuck with posting only to one network, but with Twitter and LinkedIn sitting in hibernation, I thought it might be a good idea to use them. With the freelancing way of working now in full swing, I am toying with the idea of using Twitter and LinkedIn to share updates to my availability for contracts and interesting links from the web development world.

Using these networks to market myself as a freelancer is a great way of using these networks without me just abandoning them for one network. The truth is that these days people are rarely exclusive members of one single network. I know there is people who share all their updates across all networks, but I think that is counterproductive. This can take up a lot of your time, especially when you start getting replies from different people on different networks.

What I will be doing is continually posting to App.net anything that I wish, but for my Twitter and LinkedIn accounts, I'll be sharing blog posts on freelancing, web development and availability as well as sharing interesting links on web development using Ruby and hopefully other languages. I'm getting the tools in place I need to make this happen, namely a Buffer account and perhaps some triggers setup on IFTTT if needed.

Hopefully this will result in more leads for freelancing work and also increase my reputation in these networks as a web developer who is passionate about what he does. We'll see how it goes.

Couldn't actually get a name for this bike. Great build though.

via FGGT