Matthew Lang

via PEDAL Consumption

Skipping the TDD cycle isn't always a bad thing to do. After all, sometimes you just want to write code.

Over the holidays I had some free time. An idea has been in my head for most of the year, but I never got round to scheduling anytime to work on it. I decided now was the chance to throw something together to see if this idea was worth exploring. To change things up a bit I decided to not follow my usual practice of TDD. Some might call that laziness and that might have been a minor factor, after all it was the holidays and this was just me trying something out, but the major factor in skipping TDD was that I had the knowledge to build the application quickly. Over the course of a couple of days I put together the first attempt at implementing this idea.

Aside from a couple of typos and minor bugs, the application is working fine and doing its job. The bugs were just oversights made by myself during those two days and they were easy to fix once found. I'm not surprised by the this as it is a simple application comprising of some basic CRUD operations and a single Rake task. Once everything was looking good, I deployed the application so that I could see it running for a few days. After a week it was clear that all was in working order. I've shared the idea with a couple of people who have so far been positive about it.

Now being a good developer I mostly write tests before I write code. It's the TDD way. This time though I skipped the tests in favour of getting something basic up and running. I had the knowledge and I ran with it. It was supposed to be just a prototype after all.

In the past I've stuck with using TDD when building even the smallest of products. At that point in my career however I was a less experienced developer. I was still figuring things out. The tests made sure that everything was working as I stumbled through different parts of the product. Now though, I have the knowledge and confidence to throw small web applications together without writing tests to in order to explore simple ideas for web applications.

Is it still a prototype then now that it has been shipped and is being used daily? Yes and no. The line between prototype and product is definitely blurred here. I would have to say that until the code itself was backed by a test suite, it's still just a prototype, an idea. So why not trash the code I have at the moment and start again from scratch using TDD?

I could, but I already know what code I need to write. Do I really want to scrap the whole thing knowing that I'm just going to write similar code again? In an ideal world I would probably do this but I knew it would be a while before I got free time like this again. The next obvious step then would be to add tests to the prototype and gradually refactor this code into something more stable. Something ready for the masses.

TDD is still a great practice to follow when writing software, but I think there's a time and a place for it. When writing software as part of your job, for a client, or as a contribution to an open source project, then yes, TDD should be used in these cases, especially if they are expected of you. However, when you are exploring code, ideas and simply playing around then I think it's down to yourself to decide. And if you decided not to TDD, don't sweat it.

TDD might be advantageous when learning a new language or framework but when you have the knowledge to build something quickly then why not. If it's worth pursuing further then start writing tests for the code that you have before things start to get more complicated.

I've been thinking for a couple of week now about learning Rust, but something that's been bugging me has been what to build with it. Rather than focusing on what to build first, I should really be focusing on learning Rust first.

This sketchbook of implemented ideas isn’t a paper book, but a collection of small programs. It could be as simple as a folder full of Python scripts or Erlang modules. It’s not about being right or wrong; many ideas won’t work out, and you’ll learn from them. It’s about exploring your interests on a smaller scale. It’s about playing with code. It’s about having fun. And you might just become an expert in the process.

— A Developer's Sketchbook for the Twenty-First Century by James Hague

Setting a goal for the year is made by many at the start of each year, but people frequently give up or just abandon their goal because it seems too far away. With a little change in tact though, there's a better way of hitting your goals for the year.

Set Smaller Goals

Instead of focusing on big goals for the year, what about setting smaller goals for throughout the year? Smaller goals are within easier reach, easier to track and it means that if the goal isn't hit you can try again the next month.

When goals are set for the year, people usually forget to set aside regular checks to ensure they are on the right track. After a few weeks many people simple give up. With smaller goals though, you can set yourself a more manageable and attainable goal that will give you the confidence to succeed on subsequent goals.

Continually Refresh

The start of the new year is traditionally seen as the only and best chance to start afresh but there's more than one opportunity available in the year to do this. New year, new month, new week or even new day. There's more opportunities to start afresh than you think.

If you set yourself goals for smaller periods of time then you give yourself more chances to achieve that goal. Right okay, you didn't do that bike ride in the time you wanted for January. Could you do it in February though?

The chance to start afresh is there every day, every week and every month. You just need to decide what you can realistically achieve in those periods of time.

... with NB.

Surprise them. Shock them even. Don't even complain once. About having eaten too much, the vacation being too short, the ridiculous queues at Starbucks on New Year's Eve afternoon. Don't let that stuff get to you. It's a little friction in the wheels of life. It may be the first week back. Heck it's the first Monday of the new year.

— Back to Work? by Nicholas Bate

Click through for the reason why you do this.

I would have to say that the Jack Ryan reboot was by far my most disappointing movie of 2014.

Chris Pine seems suffocated to be playing the straight-man hero (he is more at home in Stretch and Into the Woods), Kenneth Branagh is really not Russian, and really you just want to weep for Keira Knightley, whom everyone assumed would have a secret role to play in the film but is merely there to have a light bulb shoved in her mouth while she tearfully waits for her man to save her.

— 'Exodus,' 'Maleficent' And The Worst Films Of 2014 by Forbes

My own cinema going experience for 2014 was limited, but I'm glad to see there's a few must-see movies for 2015. Roll on 2015!

Sadly I failed to completely fill a whole notebook this year. Seems like a trivial goal to have, but having a notebook full of notes, ideas, mind maps and lists gives you more book than a notebook only partially filled with notes and other stuff. Armed with these suggestions though I'll have a better chance at finally filling a notebook.

via The Cramped

I was on a roll there for a while, but it's been difficult to get that consistentcy back again. I am working on it, it's just the hovering over the publish button that has frequently held me back.

Software engineers should write because it promotes many of the same skills required in programming. A core skill in both disciplines is an ability to think clearly. The best software engineers are great writers because their prose is as logical and elegant as their code.
— Software engineers should write by Shubhro Saha