“Your mind knows that you are going to Song-do. But you must not tell your body. It must think one hill, one valley, one day at a time. In that ways your spirit will not grow weary before you have even begun to walk. One day, one village. That is how you will go, my friend.”

-Crane-man (A Single Shard by Linda Sue Park)

When I decide to start working on a new project, my favorite thing in the world is thinking about the end result and envisioning how I will feel after I’m done. Getting to the point of actually starting has always been hard for me. There seems to be some sort of mental hurdle I need to jump, and the uncertainties that surround any project often keep me from getting started and working on it at all.

When this happens, I ask myself: what is the easiest first step? Which part of the project can I define and tackle first? Identifying an easy first step is powerful is because completing that step gives you a sense of confidence and momentum that will make climbing the mountain less scary.

For example, I spent a lot of time before I came to Hacker School floundering on my Go compiler project. The weekend before Hacker School began, I spent a lot of time thinking about how to structure my time, but I was scared about my ability to take on the project and I didn’t have a first step in mind. On the first day of Hacker School, I talked with Tom Ballinger and he told me that many people that are interested in compilers start by building an interpreter. I recognized that as an easy first step that was well contained, and working on an interpreter equipped me with the knowledge and confidence I needed to actually start building a compiler.

I have found that, by the end of your first step, the next one is more clear: After I learned what I needed from my interpreter, I dropped it and easily moved on to the lexer, the first part of my Go compiler.

But sometimes the next step isn’t clear. After I finished the lexer, I wasn’t sure how to proceed with writing the part of the compiler, the parser. I knew I needed to write one, but I didn’t know where to start. That’s a sign that you’re uncomfortable with the problem you’re trying to solve, and your next step is to learn and experiment with the problem domain until you’re comfortable moving forward. I read many things, talked with many people, and had many false starts with the parser before I was ready to actually begin working on it.

Having just finished the parser, I’m in another in-between state of learning and experimenting with semantic analysis of my abstract syntax tree. I’ll identify an easy first step soon enough, though!