Matthew Lang

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

The other week I read about a popular journaling app for the iPhone that allows you to populate your journal by aggregating your posts from your various social networks. I was saddened to hear that this was being touted as a selling point for journaling software. Here's why I don't see it as a benefit.

When you aggregate posts and actions from various social networks, you're effectively just pulling the random stuff that you throw out to the world on a daily basis. Often it's a spur of the moment thought or opinion. How many times have you posted publicly you were going to do something but didn't see it through? I've lost track myself. Promises of using different programming languages and frameworks have all been broken because that post that I made publicly is a spur of the moment action. Aggregating media is not a form of journaling because it pollutes your journal with whimsical statements and promises that are often written on the spur of the moment.

Journaling is the act of writing down your thoughts in private. Whether it's a digital journal or pen and paper, journaling is the act of organising your thoughts and putting them down so that you can reflect on it now and later. It's a log of your thoughts, opinions and actions. Your successes and failures. Sometimes you'll like what you write, sometimes you won't. When you start noticing trends in your journal entries, then you can start to take action.Ten journal entries in the same month about your wish to write a book say more about your passion and willingness to do this than a one off tweet on Twitter. It's these trends in your journal entries that let you identify what you want to do rather than what you would like to do.

Your journal is your life in the words that you write to yourself, not to the world.

Should you TDD your MVP?

This question came up on the Hacker News website a few days ago. Reading through the comments there was a very mixed response as what people preferred to do.

First let me describe a couple of things for readers of a non-programming persuasion. TDD (or test-driven development as its more commonly known) is a way of writing code. Essentially it boils down to writing a test for the code that we are about to write. This test fails until we implement the correct code to make it pass. The MVP mentioned here is a minimum viable product. This is the simplest implementation of a product that will deliver value.Got the acronyms sorted? Okay, let's crack on.

I have built a couple of MVP's with test-driven development. I have to say that using TDD to drive the product worked well for me. It gave me the confidence to ship the product once I knew it working. And that really for me is what an MVP is all about. Shipping the simplest thing that can work. We know it is working as we have the tests to prove it and from working code we can then be confident in shipping a product that provides value.

An MVP without tests is simply a throwaway application in my eyes. It's code that serves a short term purpose such as learning something new or proving a simple technique.Others might argue that this is exactly the point of a lean startup. To test an idea. However in order to test that idea for a product we need to have something that the product can offer the customer, and that needs to be value that the customer can see. Value that you can certify is working correctly.

Each to their own really, but I'll keep TDD'ing my MVPs in the meantime.

Nice hoodie for cutting about town.

via Pedal Consumption