Matthew Lang

I'm going to read this at the start of every week.

I've been reading fantasy books for over 20 years now. I was first exposed to the genre through a friend at school who gave me the Dragonlance Chronicles to read. It was hefty book but I was immediately hooked. Since then I've read hundreds of books in the genre enjoying each and every one.

Over the years I've favoured authors like J. R. R. Tolkien, Terry Pratchett, Raymond E. Feist, David Gemmell, George R. R. Martin, J. K. Rowling and David Eddings. There have been a few authors who I have only read one or two books from, but I tend to favour books from the authors I just mentioned.

In the last year though I've become less and less patient with the books I have been reading. I've abandoned four books in the last year because they didn't hold my attention. Books that I am reading are becoming predictable or simply just don't grab me when I am reading them. Now I'm finding it especially difficult to find a new book to read from the fantasy genre because I don't want the next book turning out to be another turkey.

I haven't been reading books from the fantasy genre exclusively, I have been reading other books in the last few years including the Master and Commander series, Conn Iggulden's Emperor and Conqueror series and a few other military history based works of fiction.

I'd even consider the zombie genre if it means I'll find more books to enjoy. Perhaps it's time for a switch.

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.