Dive right in!(?)

When you're beginning any new endeavor, your first temptation may be to just dive right into it. I know. I've been there, again and again. But, before you start, it's a good idea to have a measuring stick of where you are starting from. Without truly understanding your starting point, you’ll have no way of understanding where you are, or what you've accomplished.

What to measure

When you are considering starting something new, it may help to actually consider what it is you want to measure first. Is it knowledge level? Is it something that you've built? Is it a feeling of launching something? Is it some other yard stick? Identifying what your end goal is can help you track your progress as you implement and learn new things. Here are some typical end-goals I have used to help me define my my measurement guidelines more clearly:

• Building a new app with a new framework
• Feeling comfortable enough with a new language’s core features to be able to explain it to someone else
• Being able to do X, Y, and Z with a particular language or framework (this can take various forms)

Once you have begun to figure out what your final goal is, then you can start to figure out how to measure that goal. Let's take a few concrete examples so you can get a feel for it.

Learning a new framework

You've decided to pick up the latest front-end JavaScript framework for building web applications. What are your steps? How would you go about doing it? They might look something like this:

• Find a popular tutorial on Framework X and go through that until finished.
• Decide you like it well enough for a next step; find a book or more challenging tutorial on the framework and work through that.
• Tackle one of your own projects using this new framework. (It helps to pick a project that is fairly well-defined and you’re familiar with all of its moving parts.)

Your success at this point has three main steps:

• Finish the initial tutorial until you have a basic, but functional, application.
• Finish the more in-depth tutorial or book.
• Build your own application, quite possibly one that you've built before.

Now, at the end of all of this, you should probably have a decent idea of a few things:

• The main pieces of the framework and how they fit together
• What parts of the framework you don't fully understand yet and have just been taking for granted

You have a few choices now. Do you continue diving deeper into this framework? Do you like it well enough to devote more time to it (right now)? Have you satisfied your curiosity and now want to move on to something else?

Learning a new language

Now, learning a new language will probably be a bit different, and is, in some ways, much more challenging than a framework. With a framework, you are already familiar with how the language works; you’re just applying some new principles. But learning a new language, you are sometimes doing both, learning a new language and a framework simultaneously. This is a big mistake, one which I've done myself more than a few times. It's best to get through a language first, and then try and understand the framework. So, what might learning a new language look like?

• Work through some of the basic language tutorials so you can get a feel for it.
  • How do you build the language?
  • What's the syntax look like?
  • What's the formatting standard accepted by the community?
• Done with that, you might move on to some code katas or dive deeper in to common constructs.
• Then you might dig deeper into other language constructs that are wholly unfamiliar to you.
  • If you are mostly from an OOP background, many functional languages do things in a unique way that are very different to what you're probably used to.

For this your yard stick might be something along the lines of "I can do X, Y, and Z in this programming language."

[Note: I have a list of challenge sites that can be really good for language learning]

Learning a new technique

Now, this one is a bit more tricky to measure, especially since learning a technique in itself is a little nebulous. What does that mean, technique? Learning a new technique encompasses a few things:

• Taking advantage of, or exploiting, a particular language's built-in features to do something unique.
• Learning a new computer science data structure or algorithm that you had not previously tackled.

Just to dive a bit deeper into this, I'll try and cite a few examples so you have a better idea. Language features that have been exploited:

• In Ruby and Groovy, you can do what is called Metaprogramming, or the ability to rewrite programs on the fly.
  • This also allows you to write Domain Specific Languages (DSLs) that sit on top of these languages.
• In Lisp, you can also do Metaprogramming, but to a much greater degree, which also means much more in-depth DSLs.
• In Scala, you have a few interesting concepts like Actors, Pattern Matching, etc.

These are just a few examples. So, what are some Computer Science (CS) techniques? Some of these you know, and use, but don't know how they were implemented:

• Hash tables
• Binary search trees
• Heaps
• Graphs
• Sorting Algorithms
• Search Algorithms
• Dynamic Programming
• Djikstra Shortest-Path Algorithm

How to measure

Now that you have a decent feel for what you're measuring, you may be asking yourself how you are going to measure your progress. In a more traditional learning environment, you may have things like quizzes and tests to help your teacher be able to measure your individual progress. Are you understanding the material? How do you compare to your peers?

Well, in the real world there are no tests, no quizzes, simply the question: can you use this to help accomplish a particular goal? And maybe a follow-up question of how quickly can you use this knowledge to accomplish this goal.

You might then choose to measure your progress by how much revenue your application makes (or saves depending your goal). But is this really tracking your own personal success? Possibly. It really depends on what you're trying to achieve. For me, personally, this doesn't really answer the true question of success, though. Have you failed if you've learned something through that failure? Have you truly succeeded if you haven't learned enough to repeat that success?

No, for me the true measure of success comes in a few forms, especially when it comes to learning something new:

1. Can I explain the core problem that a given framework, language, or technique is trying to solve?
2. Can I give another developer a 10 - 15 minute walk through of something interesting I learned and actually teach them something new?
3. Are there aspects of what I'm trying to learn that force me to think through problems differently?

Learning is an incremental thing; when you do it continually and consistently, you will gradually improve. But, and this is a big but, you must be methodical about it. Randomly diving into framework after framework, or language after language, without documenting your progress or what your particular goal is, may leave you feeling unfulfilled.

I like to think about measuring my progress as a daily, incremental thing. It has become a habit. I have a long-term goal that I want to reach, but if I am consistent and continually work on my project and goals every day, then I know I will get better at them, little by little. If I write every day, I will become a better writer. Same goes for coding. If I code every day, and focus on areas that I feel I'm weak in, then I will become a better coder.

Should you measure

The next question then becomes should you measure? For me, this is a bit of a misnomer. I have shifted from trying to focus on a specific end goal and started to focus on a daily goal. That goal being to work on my side project every single day. I have some other things that I like to throw in there like specific milestones for my particular project or actually releasing something, but overall my real goal, and the thing that I measure myself against, is my daily programming habit.

Within this habit, this is what I like to focus on:

• Have I programmed for at least 30 minutes that day?
• For this period (2 weeks, 4 weeks, 6 weeks, etc.) what am I focusing on? Anything specifically I'm trying to achieve?
• Take copious notes on what I'm learning each day and where I would like to focus on for the next session.
• Are there areas that I can apply this knowledge to elsewhere? Does my knowledge help me in other aspects of my work or life?
• At the end of my block (2, 4, or 6 week) I look back and take stock of what I've actually accomplished. Can I write this up?

Wrapping up

Everyone approaches their learning journey in their own way. What I like to do is to be able to share my own journey with others as well as read about what others have done. Without this, I never would have come up with the concept of 30-Minute Project.

So, when it is all said and done, I like to try and share my own journey:

• Where did I struggle? What did I do to get through that area?
• What aspects of the framework, language, or technique did I really like?
• What didn't I like? Or what might I change?
• What are some of the good resources that I stumbled across?
  • Blog posts, mailing lists, Slack groups, Reddit groups, documentation, etc.
• Will I continue doing more with this? Why or why not?

Sign up for my mailing list and get your free ebook

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project