The value of 'getting started'

When confronted with a project, one that will involve learning new skills for you to be able to complete that project, there are a few ways often used to tackle those particular problems.

One of these ways, which I have observed many times, is centred around front-loading your learning. Dedicating time to "learning" the particular skill before applying it, my particular experiences are with technology. Be it implementation of a network with specific technologies or the development of software with different languages, frameworks or libraries.

People sometimes feel the need to learn a certain amount of the skill before they begin to apply it. We often hear about how different people learn in different ways, and I'm pretty much with that, but I see this method fail or at least have significant negative consequences often enough that I think at the very least there are many people who should look towards other ways of approaching this process.

I once employed this approach often and found myself struggling, it wasn't until I was met with deadlines, until pressure to produce results was applied that I began to employ a 'just get started' approach.

Analyse the task, identify the problems

When, in the past, I have been tasked with a project which involved skills I didn't currently have, the problems that worried me the most were naturally the ones I was unsure about how I'd approach solving them.

It was my worry, my concern, that I wouldn't be able to solve the problem that pushed me towards dropping the "read a load of textbooks, web articles, tutorials, etc and then try and start" approach. In my mind, even before starting the project, even before starting planning for the project, I had broken up the project into smaller problems prioritised by the things I was unsure of how to solve and those weighed heavy on me.

Nothing could lift that weight, no amount of reading, no amount of understanding and practicing the particular skill set I required would help. The only thing that helped was just trying things. I didn't really have a good grasp on the skill I needed to solve the problem in its entirety, but I could pick up what I needed piece by piece as I got through that problem - "when we get there" was my philosophy.

It eased my worry, it made me focus on smaller, digestible problems which made solving them easier and helped fuel a sense of progression. In my old approach, I would be constantly trying to shoehorn the problems I eventually would have to tackle into the learning of a particular skill (e.g. Multicast networking in C# .NET), but the problems were too big and the amount of knowledge I still needed to acquire still felt so vast.

But by breaking even small problems, into even smaller problems, by learning as I went along I found myself developing the skills quicker and more confidently than I usually would have and it gave me the confidence to iterate quickly on the work I had already done.

An example

One project I had which involved a fair bit of learning was one to develop an application to (reverse) proxy multicast traffic, involving management and reliability features. I had never done any real networking programming in the past and especially not in C# .NET, my plan to create this project involved many technologies and libraries which I had never even read into, let alone had experience with.

The experience of trying to acquire all the knowledge I knew I needed was overwhelming. I kept delaying starting actually writing code because I felt I wasn't ready to, I didn't know enough.

But eventually, as time went on, I realised I needed to get started, I was running out of time. So I started by cutting up the primary problems into many, many smaller problems.

For example: How do I receive multicast traffic on a particular given multicast address? So I went away started just messing around with code, to try and start receiving multicast traffic, it was an easy problem that didn't take me very long at all - next step, manage the incoming data, lets just see what happens when I take incoming UDP data streams and start trying to manipulate it.

Was this code usable in my project? Not really, but it got me learning and applying the knowledge I required much quicker than I otherwise would have. It helped me understand the small piece of this problem and as result I not only feel like I solved this problem quicker, but perhaps most importantly I felt like I came up with a better solution because of it.

I had some experience to draw from, the iterative nature of developing these prototype solutions in turn helped me iterate through my understanding of the problem. Much of the project went like this, I set myself minuscule goals and learned the skills and technology as I went along, as I was implementing my solutions.

Just get started

I'm sure for many, a lot of this seems like obvious advice. But if you do find yourself struggling in these situations, just give this approach a go. Front-loaded learning as a prerequisite for a project can pile on the stress: Not only do you have to learn a whole new set of skills, but you also have to figure out a way to use those skills to solve all the problems in the project.

Well don't. Take my example, I had never done any network programming in C# .NET, never done any multicast network programming at all, so I aimed low. I just wanted to write some code that subscribed to a multicast network address: I learned the tiny amount of code and solved that particular problem in isolation and moved onto the next small problem: find a way to see if data is being transmitted on that address.

You reduce these problems to as small as you need to until you no longer feel overwhelmed by the problem at large.

In conclusion, drop the idea that you must go through and read all about a particular skill before you start, drop the idea that you need to complete a codeschool course before you get started using a particular programming language or framework. Just.Get.Started. You can return and use these resources any time you wish to learn a specific 'thing', but I think many people will feel better for not giving into the idea that you must know something before you use that something.