Friday, June 19, 2020

6 Things I've Learned About Goals

It seems every guru you listen to, every success book you read, and every course you take stresses the importance of goals. Additionally, each one of these pushes a different way of setting and pursuing goals. I read a lot of books on success, and one of my favorites is 9 Things Successful People do Differently by Heidi Halvorson. Here are six things I've learned about goals from personal experience:

  1. Pick the right strategy. There are dozens of strategies for setting goals, and some of them are just derivatives or hybrids of the other ones. One of the ones that was drilled into my head as I was growing up is SMART goals: Specific, Measurable, Attainable, Relevant and Time bound. What I've learned is that there is no one strategy to rule them all, every person thinks about their goals in different ways, so pick a strategy that complements how your mind works.
  2. Monetary and material rewards don't work. A lot of strategies advocate setting rewards for meeting your goals. I am all for this, but I would advocate that monetary or material rewards should be secondary rewards. I've come to find that improvements to my mental state and happiness are far more valuable rewards than stuff. In his book Lost Connections, author Johann Hari identifies nine underlying causes of depression, such as disconnection from meaningful work, and disconnection from nature. Set your goals so that the outcome of the goals improve your happiness. It is far better to do what you love for less pay than to make more and hate your job, even if that job you hate enables you to buy more stuff.
  3. Physically look at your goals every day. In The Secret by Rhonda Byrne, the author talks about having a vision board and several anecdotes are shown in the movie adaptation. While I no longer buy into the message of "positive thinking is all you need to be successful" (I think this glosses over several other factors), I do believe very sincerely in the vision board concept. One of my goals is to own several rental houses to create passive income so that I can spend less time working and more time with my family. I got on my computer and put together a page with little pictures of houses, exactly how many I want to own, then I captioned it with my exact goal. I printed this page and taped it to the wall next to my desk so that I see it every day. It keeps that goal in the front of my mind and keeps me from changing it on a whim (something I tend to do frequently if I don't physically write things down). Your vision board should correspond to however your mind works and should fit with your strategy from my first point. Maybe instead of pictures you would like a spreadsheet of numbers, or a list with check boxes, or something else. Do what works for you.
  4. Start with why. My all time favorite speaker and author is Simon Sinek. One of his books, called Start With Why, illustrates the importance of knowing the reasons for doing what we do. Whenever we find work to be meaningless (and therefore unfulfilling), it is often because either we don't know the reason(s) for doing the work, or the reason(s) don't matter to us. This also ties back to Johann Hari's concept of disconnection from meaningful work. When you decide to set a goal, you need to start with a good, strong foundational reason for attaining that goal. Without this, it will become too easy give up later when difficulties arise. My reason for aggressively pursuing passive income is not to become rich, to have lots of money, or to drive a Lamborghini. Those are superficial reasons that really don't matter to me deep down, despite them being "cool". My reason is to supplement my income enough that I can drop to part time work, or even not need to work and can spend more time with my future children. Know your reasons why, and be sure to put those reasons on your vision board with your goals.
  5. Eliminate unreasoned goals. Setting goals can sometimes be like loading up your plate a buffet. You get back to your table with an overflowing plate, stuff yourself, and still have food on your plate. On multiple occasions I have created pages and pages of goals, only to realize a few weeks later that half of them really didn't matter to me. When setting your goals, go back to point number four. If your reason for that particular goal isn't strong, if that reason won't be with you for at least the time frame of the goal, it's probably not a good goal to set. That being said, there's nothing wrong with your reason being a strong "because I want to". One of my goals is to become fluent at speaking German, and my reason is "because I want to". I had a goal at one time of creating a YouTube channel "because I want to", but that faded and I got rid of that goal. It's okay to set these goals and then eliminate them later. Sometimes we don't realize that our "why" isn't good enough until later on, but at some point you need to eliminate goals you don't care about so that you can focus more energy on goals you do care about.
  6. Take time for yourself. Burnout is real. You can't spend 12 hours per day, 7 days per week working. Even if your body can handle it, your mind will burn out (there's a reason labor laws exist and why 40 hours per week is generally the work week limit). You should spend time on each of your goals once a week at a minimum, but you also need to rest. Your rest and recovery time will be different than everyone else's, but it is vital to avoiding burn out. Even if you don't feel tired, take a quick break once in while. Once you burn out, it's very difficult to get back into the flow. Head it off before it happens.
These are the six things I have learned over the past several years that I think are most important for setting and achieving goals. Set yourself up for success by finding what works for you and going after what you want. Life isn't about getting rich, pleasing other people, or having stuff. Life is about happiness, fulfillment and experience. Go get it.

Monday, May 4, 2020

An Overview of Git

What is git?

Git is one of the most popular and widely known version control tools. It's been used for countless open-source projects, commercial products, and even for non-coding projects like to write books. Git keeps track of changes to you code (or other content) and allows you to create incremental versions, as well as keep a history of changes. You can even roll back to previous versions or "cherry pick" parts of previous versions you want to bring back. 

How does git work?

Git was intended to be a serverless system, but most setups today have a central server (repository) often known as "origin". Origin is typically where the "master" code is stored (more on this later). Contributors (developers, designers, writers, etc) typically create a copy of this code, known as a branch, for working on. The contributor has an instance of git installed on their own computer that has its own local database. They use their local instance of git to copy (clone) their newly created branch of code to their own computer. They use whatever tools they prefer to make changes to the files in their branch. When they are finished, they "stage" these changes to tell git to track them and "commit" so that git records the changes in it's local database. Once they've made all of the changes they want, they can "push" the code to origin to store what they've done in the central repository. Take a look at the graphic below for an illustration of this process.
Once all of the desired changes have been made on a branch, that branch can be merged into the master branch. Remember that git tracks changes within files, not just files. When a contributor merges a branch to another branch, the changes the contributor made to their branch are made to the other branch. This allows contributors to work on different parts of a project at the same time and commit changes to the project without stepping on work other contributors have done. It's confusing, I know. Below is an example of my favorite branching strategy that will hopefully help clear it up.

Branching Strategies

There are a lot of different branching strategies used in git (and other version control tools). Here, I will show you my favorite one using an example. Use the diagram below to follow along. Let's suppose we have Carl and Mary both working at Awesome Inc. They are developers working on the flagship product: Awesome Software. On the left, you'll see there is a "Master branch". This is the master copy of the code. The blue dots represent releases (e.g. version 1, version 2, etc.). Here is what happens:
  1. The project manager creates a development branch from the master branch. At first, the development branch is an exact copy of the master branch. Changes are not made directly to the development branch, all changes happen in "feature" or "bug fix" branches.
  2. Carl is going to add a feature to the project, so he creates a new branch, known as a "feature branch" from the development branch. Feature branches are typically short lived. Carl finishes his changes, but before they can be merged into the development branch, they must go through a "code review" where other developers on his team look at his code and either approve or disapprove it. If it gets disapproved, Carl goes back and refines his changes. Once approved, he can merge his code into the development branch.
  3. Mary is fixing a bug in the code. She also creates a new branch, known as a "bug fix" branch, from the development branch. Like feature branches, bug fix branches are typically short lived and address only the bug they are created to fix. Mary's code goes through the same code review approval/disapproval process that Carl's code went through. Once approved, she merges her code into the development branch.
  4. Testing is a major part of development. Often unit tests are included in the feature and bug fix branches. The development branch is also frequently tested, usually automatically (a topic for another day).
  5. There are typically dozens or even hundreds of feature branches and bug fix branches merged into a development branch before it is considered ready to be released as a new product version. The development branch also undergoes extensive testing and review (the people who do this testing and review depend on the organization). At the bottom of the diagram you will see a light blue dot labeled "New version release". Once the testers and reviewers are satisfied, the development branch is merged with the master branch. At that point, a new version of Awesome Software is created from the master branch and released to customers. Notice the development branch is kept. Development continues on this branch to produce future releases.
This is just one example of a branching strategy and you will likely encounter others, some simpler and some much more complex. This one just happens to be my favorite.
Using version control is hugely beneficial to development projects, especially larger ones with multiple developers. If you use a suite like GitLab, you can even build automatic testing and deployment into your version control process, leaving you more time for coding and making releases easier. It is definitely worth learning. In a future post, I'll go through the basic workflow of using git with a project.