Matthew Lang

Life as a freelance developer isn't always plain sailing. I can deal with the bulk of my day to day activities including requirements gathering, designing and implementing features with code, testing and of course deployments. It's what I am paid to do by clients.

The one thing I have trouble with is rush jobs to meet a deadline. As a developer I would ideally like to write tests for all my code, re-factor it and get it to a place where I feel comfortable shipping it. In the real world though that doesn't always happen. Sometimes it's only hours you get to either rush some code changes through. A depressing experience for any developer who takes pride in their work.

In scenarios like this I like to remember that although the code I am shipping in not tested or re-factored to my preferred standard, I can always pick up the code the next day after the deadline has passed. Before I pick up any other tasks tomorrow, I'll ensure that the sub-standard code I previously shipped is correctly tested and re-factored appropriately.

Keeping a journal seems quite an easy task to do, but remembering to update it and keep it going can be something else. I've kept my journal going for 18 months now and these little tips are what have helped me journal for this long.

Set a reminder

Set a reminder for your to do your journal entries. Last thing at night before you read a book or an hour before you go to bed are ideal times. Any kids you have will be sleeping, so you'll get a few minutes of distraction free writing.

Setting this reminder will hopefully turn into a habit where you will pre-empt the reminder and journal every day without being prompted by a reminder. If you find yourself forgetting to journal, then simply set up your reminder again.

Journal just two or three sentences at a time

Keeping a journal doesn't mean you should be writing epic chapter length journal entries every night. Just two or three sentences are sufficient. If you want to write more then do so, but just a summary of the day is sufficient for those non-eventful days.

Keep your journal close

Whether it's pen and paper or journaling with your preferred app, keep your journal close for those times when you want to write something down. You never know when you're going to want to write something down.

Don't knock yourself for missing a day

Journaling every day can be difficult. Family life, career, holidays, work trips and other things can distract you from journaling for a day. If you miss a day then don't worry about it. It's only one day. Get back to writing a journal entry the following day and make sure your reminder is set for a few more days until you get back into the habit of writing a journal entry every day.

... with our pilot through the ocean of life, Kurt Harden.

... from Michael Wade.

To zoom in more on the detail. There's millions of topics to write about if you look close enough.

via FGGT

Striving for perfect code is a goal of many developers and programmers. We want our code to be simple to read, concise using the best idioms that our programming language has to offer and of course backed by an army of tests to prove it works. You want your code to be perfect. This is achievable in our own projects and products that we have invested our own time in, but what about work for clients and employers?

Your development time is measured as a resource whether you are a full-time employee or as a gun for hire freelancer. How do you justify spending hours getting the code you have written to be the most perfectly implemented code you can achieve?

You don't.

As an agile developer, the code you have written should be testable and easy to read. With a little bit of extra time, it should also be concise to the point where you have re-factored duplicate code, extracted some methods and maintained basic programming principles but also ensured that it is still readable. So what about taking a step further and making it even better?

Hold fire. The code you have written for the feature or bug or whatever it was is now working and tested. You've spent a bit of time refactoring. Now commit your changes and move onto the next card for the application.

In your eyes you have committed sub-standard code. With a bit more time you could have taken it further and made the code better. This path can go on and on if you're not careful.

In your client's eyes or employer's eyes you have committed working code, you haven't taken too much time to do it, and it works. They will be happy with your efforts.

The perfect code you are aiming for is never going to perfect and nor will it last. In a few months, the framework you have written your code with is going to be updated. Chances are the perfect code you have written could be improved upon again. In a year or two, the programming language your application is written in is going to be updated. There goes your perfect code. Then when the programming language has been superseded by a new kid on the block, the application you invested so much of your time in is rewritten in a different programming language. Your perfect code is gone forever.

Unlike the written words of Hemingway or Tolkien that have endured decades, your code is simply a stop gap to making a product or service operational. By all means exercise some time to make improvements on the code. Remove duplications, re-factor it, but always keep an eye on the clock. Spending too much time trying to achieve perfectly written code is not a good use of your time or the time of your client or employer.

The wrong approach. It's a major downfall of mine. Trying to solve a problem by approaching it wrong and looking for a difficult solution. The thing is I'm not looking for the difficult way to solve the problem on purpose, I just keep happen to be looking in that general direction.

Take the problem I had today.

For three hours I tried to find the solution to a problem I was having in a clients application. I spoke to the client at the end of the day to give them an update on my progress and five minutes after the call the solution was clear.

The client didn't provide the solution. It was just one of those moments when everything fell into place and all of a sudden the solution became clear. I wish these moments presented themselves more often.

The truth is I simply need read up more on the programming languages and frameworks I'm working with on a daily basis. The everyday knowledge only gets you so far. When you've exhausted that you need to look towards the more advanced parts. It's only when I learn these advanced parts that I will truly rid myself of looking at problems with the wrong approach.

It's a well known fact that if you're a reader of my blog, you'll know that I love the App.net service. A subscription based network for those that want something more than just ads in their timeline. Since taking up residence on App.net, I've found that I am no longer as active on Twitter.

These days I check it about once a week. Only out of habit really. Previously I was following just 50 accounts on Twitter and today I cut that number in half. I'm now following just 25 accounts. The plan over the next few weeks is simply get this following count down to zero and then delete my account.

I just don't get as much value from Twitter these days. I don't find client work on Twitter, I don't use it for marketing myself as a freelancer (that's what my website is for) and it's been a long time since I marked anything as a favourite there. Really it's just another placeholder for me on the web, but is it really that important to have a Twitter presence now? Once I delete my account it will be gone forever. I might be lucky enough to get my username back if I sign up again but the chances of that happening are remote.

Anyone else out there considering giving Twitter the chop?

Sure. Why not? Your blog is your digital footprint in the world and it is more easily found than physical business cards.

I've adopted this idea of Patrick's for my own stuff. The card only contains things that I want to do personally for that day.

Client work goes in my Moleskine where I need a more permanent record of day to day progress.

After reading Matt Gemmell's post on designing blogs for readers, I decided to assess my own blog for a re-design.

Here's the parts of my blog I'm not that happy with at the moment:

• I used another template for my site that was similar to the default Octopress theme. They're fine themes to use but I've always wanted to design a theme that suits my requirements.

• The side bar is a busy place. Perhaps too busy. While I do want to have extra information like links to other accounts and other information, I feel this information would be better suited at the bottom of the blog. This way the reader isn't distracted during the reading of my post.

• The fonts used in the current theme make it difficult to differentiate headings from paragraphs. Easy to fix, but I don't want to put a band-aid on the current theme. I want to start from scratch.

With this information I've decided to put together a new layout for the site over the next few weeks. I'm putting a couple of products to the side for the moment. For the next few weeks I am really busy with client work, so I want a side project that doesn't demand too much of my time. This will fit the bill nicely.

via FGGT

Dedicating yourself to a project weekly means you don't have to switch contexts. I wake up in the morning, get myself ready and then I start on the tasks for a weekly project. I don't have to decide what clients gets my priority today, I just work on the project for the week.

— Weekly Pricing for Web Development by Curtis McHale

I love this idea. Basically it amounts to charging for iterations or sprints. Nice to see Curtis picked up on my task switching post as well.

I can afford to lose some time during the day as I am working with mostly one client at the moment on a number of their applications, so a little lost time is to be expected.

Tonight I took the final step in making the move away from Google. After much deliberation I made the move to migrate my Google Apps email account to FastMail. It was certainly less painful than I thought it would be and took the best part of an hour to get all three email accounts over to FastMail.

As for the other services from Google, I've found suitable replacements for many of their services over the last few weeks.

• Switched to Pages and Numbers from Google Docs - I don't have that many documents to manage and I don't need them when I am on the move, so setup will be sufficient.
• Switched to Feedbin from Google Reader - Feedbin is still young but it's growing and it's supported by the Reeder app for the iPhone. A no-brainer decision there.
• Switched to Gauges from Google Analytics - Github's analytics service is ideal for my needs at the moment. It's dashboard provides all the information that I need at a glance and of course it has a greap API that's easy to use.

There are of course other Google services that I never really took too like Google+, Chat, Picasa, and their Drive service. I already use alternatives for these that I find to be much better so I never really got round to using these.

So why move from Google?

It was the all your eggs in basket argument. Google aren't going to go away anytime soon, but simply having all my information in one place was nerving. I wanted more control over my data, so I elected to find alternatives that would do just that.

I'm happy with the choice that I made in Google free. It's not for everyone, but having more control and investing more into products and apps that provide a better service certainly does give a better feeling than handing all my information over to one provider.

Quick to change and always adapting. Nicholas Bate knows how the smart organisation works.

Curtis McHale offers some advice for those that are just a little bit too quick to write off change.

Thanks to Execupundit for this reminder that it is 70 years since the Dambusters raid. The Spitfire was my favourite as a kid and still is.

... with Nicholas Bate.

Yesterday I talked about annual reviews and how organisations can often get a simple process wrong, but are annual reviews immediately flawed due to their annual occurrence?

A year is a long time. A lot can happen in a year. I left a job, started a new job, got made redundant from the new job and then started freelancing all within a year. I hope you're not as unlucky me to get made redundant, but maybe you move about a lot inside an organisation? What if you're never in the same job for more than a couple of years. Does that make the annual review a redundant process?

In the UK there has been a rise in the last few years of self-employed workers and recently portfolio careers have proved to be popular with workers who want more of a variety in their career. The job for life is gone, so why are organisations still subjecting their workers to annual reviews?

Perhaps a more agile approach is needed with more frequent feedback. A year between reviews is too long, but what about quarterly reviews of your work with your line manager? How about monthly? At what point would your line manager know that you are enjoying your job and making a positive contribution to the company?

As a freelancer I have to continually look at my skill set and improve on areas that are rusty and also consider new programming languages and frameworks every few months. I have a core skill set that I am strong with but I also have to consider other skills if I want to make myself attractive to future clients. I give myself a review every month so that I know what work I have completed, whether I have completed it on time and what is in the pipeline ahead for me. I can afford to do this though as it is just me.

I'm just glad I don't need to sit through anymore annual reviews for the foreseeable future.

It was my oldest son's parents night at his school tonight. We had a fair idea what his teacher was going to say about him and his progress. We weren't disappointed.

The format is simple. You get 10 minutes with the teacher in which time they will go over the your child's progress (that you have already read the week before) and then you get to ask any questions about your child and identify any area where they can try and make improvements. Fortunately our son is doing great so there was just a couple of minor areas for him to improve on.

If you think the format is familiar then you would be right. Parents night is just the kiddie version of the annual review that many permanent workers go through. However, how is it that organisations can get this wrong when the basic format seems so simple?

I've experienced the annual review first hand in a number of companies. Very few of them actually did an annual review on a regular basis and even fewer followed through from the previous annual review.

A neighbour of mine worked in a really well known international bank where annual reviews were not done by your line manager but by someone even higher up. In an organisation such as this where the number of employees runs into thousands, there was a good chance that the person doing your annual review doesn't even know you to look at. In this case our friend did indeed get their annual review done by a director who had only met him twice. Not exactly a good example of an annual review.

Twice a year my son's school give a parents night without fail. They provide a report for your child that you get a week before parents night so that you can raise any questions during parents night. They give feedback on your child's progress and give suggestions on areas where your child can improve. They do it for all the kids in the school. That's hundreds of kids.

It's not hard to do.

Today I did my first Capistrano deployment. Yes, that’s right. My first. Any experienced Ruby developers might be wondering how I haven't used Capristrano in the past. I simply chose not to use it.

When Rails was in its infancy, Capistrano emerged as the default way for Rails developers to automate their deployments, but one thing that put me off was the amount of work that would be involved in getting it up and running. Scripts, SSH, source code management, web servers and databases. It all sounded a bit much.

Then Heroku came along and I smiled. I could deploy my application with a single command. In the past I’ve always opted to use Heroku and during my brief stint in an agile team we used Engine Yard for hosting our applications. Again deployment was as easy as a click of a button.

I’ll admit it. I’m lazy. I hate having to muck about with configuration settings, command line arguments, options and other little details to get things working.

As a developer I’ve come across hundreds of tools, editors, applications, libraries and services that help me do my job. One thing that sticks for my preferred selection of tools that I continue to re-use are the ones that just work and require little work to get working. Platform services like Heroku and Engine Yard fit this criteria perfectly.

Yes I probably should have some knowledge on using Capistrano but the ease of a single click deployment is hard to beat.

At the end of the day I just want to ship code.

In my ideal day I would have one very important thing to do and that's it. Nothing else. I haven't had an ideal day for a while though due to the simple fact that they rarely happen in the real world.

At the moment I am trying to currently balance two projects for one client. They're similar projects with similar scope and similar terminology. Already today I have wasted 30 minutes looking at the wrong code base due to my brain not registering the task switch that happened 30 minutes ago.

I'm toying with the idea of a visual reminder on my desk to remind me what project I should be working on. Or maybe even a bigger zsh prompt is required so that it shows me the current branch in huge writing.

One thing is for certain. I need to make a bigger deal about switching contexts so that I don't lose anymore time like today.

Finally a bag big enough to hold all my son's Lego with the added bonus of it actually allowing you to see all the Lego you have.

I grabbed my first rectangle very shortly after waking. I will likely stare into several throughout my day. For work and for pleasure and as a way to simply pass the time. Heck, my regular gas station has them built into the pumps now. My guess is that when one is distracted by the local weather or the two-for-one beef jerky special they tend to buy more gas.

— Glowing Rectangles by Patrick Rhone

Patrick Rhone is challenging himself to reduce his time spent on these wonderful glowing rectangles.

Maybe you should too?