The first objective should be familiarization with the commands, and you can do that by the site “https://learngitbranching.js.org" and completing the challenges there. It can be through blind repetition or applied in some repo. It doesn’t matter; you need to get in the habit of adding commit and pushing (on your branch). This part is pretty simple, but try to space out the practice, it’s easy to abstract the commands a little and focuses on the pictures that they want you to copy.

After some basic familiarization, you should at least know the commands, and you can start to apply them into a personal repository of some sort. Pushing your changes from your private branch instead of a master branch does make a large difference. Secondly, reading the documentation will help you, and is a must for gaining some freedom; getting familiar with the structure and syntax will take some adjustment. Most people play as they practice, and if you aren’t opening up Pull Requests, rebasing code from a potential error, you aren’t learning. It’s essential to make the mistakes, spending time figuring out your problems will help you remember, and you will know why something is or isn’t happening.

Next, in my opinion, would come workflows and GitHub actions. YML files and testing does eventually amount to a not so smooth process (initially), but as you experiment and get the syntax down and you’re able to run the code or simulate its nature on a machine that isn’t your own. This process is easily one of the more complex parts of GitHub since it provides an ability to build and run your code. There are online YML syntax linters, and you can even try to learn through the GUI (I won’t hate you), so you can better implement it on your own machine. After performing a couple of Github Actions and Pull Requests, you should have a basic idea of how to get your code up approve code.

Unless you are some savant, you cannot learn this without experimentation. Your code needs to fail, and you need to figure out why, because when you are in a production or enterprise environment, you will be expected to figure things out.

The first thing that I was able to take away from the book was that Management is Management, and many of the techniques that have been honed in factory management can be applied to software even though much of the work is invisible. Deploying software is conceptually the same as shipping out goods, which enables you to think about how the work flows from one part of an organization to another. Bringing Security Development and IT Ops together that way can reduce the time that it takes to form your service or good. Cooperation between these careers enables a quick and efficiently generated product to get to market faster. Stopping a flawed process conserves resources creates less work later, which is likely to be unplanned work, the most deadly of all the types of work because you don’t plan for it. Say you ship an application or feature if there is a security issue then it might take more work trying to fix a deployed application than it did to deploy it in the first place. Think of cardholder information being exposed, and a potential lawsuit. Money and time can both be sunk trying to fix a problem, and when all resources matter, it’s hard to justify rework. In addition to that, automation is simple, and in terms of a simple idea, it’s easy but automation gets more and more complex as the system grows, and when you aren’t sure of the tools that can and will help you, it’s increasingly difficult to implement. I also thought that using the improvement kata would be quite effective in the business and personal sense because when you are getting better, you definitely aren’t getting worse(as Eric said). Over the long run, this poses an exponential benefit over time, showing potential massive returns.

Lastly, the single most important non-IT related topic that I learned is that you need a team that you can trust. Bill’s first few weeks weren’t easy, and it didn’t get any easier after he got his old job back, but he already some others on his side. When it comes to relationships, CEO Steve, getting off his pedestal to ask his team to trust each other was the best move that he could have done for him and the business. This not only got others to view him as approachable, but he got them to start trusting each other to get more done. Prior to this, Steve was trying to do it all, and it became evident when Bill left, and Patty and Wes spoke of him getting “hands-on keyboards” and making the Phoenix deployment even worse. The shift in power that the trust set in motion enabled Bill and John to come together and realize how much more IT needed in an organization because a modern-day business simply cannot exist without it.