For reasons beyond my understanding, I've lately had the urge to explore a handful of technologies that I previously had only dipped my toes in. For weeks now my Firefox has looked like this:

This is an all-too-familiar sight among software engineers. I can't recall the number of times I've glanced over the shoulder of a colleague to find an internet browser open with, literally, hundreds of tabs 🤦‍.

This type of situation indicates lack of focus and is therefore best to avoid if at all possible. My job is one thing, it's common for a software engineer to address multiple tasks in parallel. But personal learning is another matter, one that I've got complete control over. Seeing my internet browser a mess is frustrating and, again, indicative of a larger problem.

Recognizing Complexity

This concept isn't limited to just technology (although, it suffers greatly from it), it can apply to most things in life. Attempting to balance ⚖️ curiosity and exploration with time and completeness is a skill refined over a lifetime. Time is the limiting factor everyone thinks about. Completeness on the other-hand is less frequently considered.

Here's a real example I'm at grips with now. Fellow computer nerds may relate to this one. Haskell is a programming language. I've had some exposure to the language in the past, particularly in university. I find the language (and it's paradigm) fascinating, but am definitely beginner level when it comes to skill. I'd like to learn more about Haskell so I can program interesting things with it.

It's at about this point when I should begin to recognize complexity. For example, when am I "done" learning Haskell? It's a complex language with numerous directions I can take it from a learning perspective. Should I read text books? Should I attempt to plan some project to do in Haskell, then do whatever steps are necessary to finish the project? If so, what type of project is a reasonable?

As you can imagine there are many possibilities. Perhaps the most noteworthy takeaways from this example are (1) I want to learn Haskell and (2) I need to define the scope of my learning.

Defining Scope 🔭

In the example above, it's clear that I need to establish some plan to effectively accomplish my goal. Learning Haskell is arbitrary in that is everyone will have a different definition of what it means to have "learned" it. Perhaps this is the best first step. Define the criteria that constitutes completion of the goal.

My subjective take on this is currently (1) I'd like to become familiar with the core language constructs so that when viewing Haskell code, I can understand it and (2) attempt to write a complete (and useful) program to demonstrate my ability to use the language.

I like to refer to the process of selectively choosing goals amidst complexity as defining scope. At this point you're probably thinking this is obvious. From the perspective of a software engineer, this sort of thing is more relatable. For me, applying this mindset to my personal goals has been more challenging.

Freedom associated with personal time eases the mind into less productive thoughts. Normally this isn't an issue, after all everyone needs a break from work. But when I'm going out of my way to learn something new in my own time, it can lead to poor results.

This is why I've recently made better attempts to define scope. Curiosity and exploration are guided by scope to yield better outcomes. It keeps the mind clear, the sky blue. The process of defining scope is naturally a restrictive action, making it good for fighting complexity.

Take Action

For my learning Haskell goal, I've decided to define scope by coming up with the following goals:

• Complete the Write Yourself a Scheme in 48 Hours book.
• Attempt to write a command-line program that provides estimated costs of traveling from an arbitrary location to all of the National Parks in the United States.

The first goal will help me learn the language constructs and how to read and write some non-trivial portion of the language. The second goal will likely require learning how to make web requests, how to interface with databases, and how to work with community packages - all using Haskell. Of course this list is not comprehensive. The point is scope has been defined, which allows me to focus. I can adapt as things move along if needed.

In Summary...

Complexity is a beast that will fog your mind if you let it. There are just too many possibilities. Investing in defining scope upfront is a great way to keep your mind clear and the goals in sight. Good luck.