From the Jocko Podcast 344 - Modern Combatives

Principles for fighting

• Systematic Training
  • it's a process, not an event
  • to be effective, must be part of a system
  • until we learn techniques that form the system foundation, we are unprepared for follow-on training.
  • shortcuts or teaching developers "what they need to know" is counterproductive.
• Continous Training
  • must not end upon graduation from a training course.
  • the majority of the training must happen outside of what we learn or are doing on a day to day basis
• Foundation/continuous training
• Competition drills
• Live training
  • involves training against a fully resistant training partner, which approaches the reality of doing [what-we-do] in a live environment.
  • there are many methods, combine several approaches to ensure proper training
• Integrated training
  • engagements do not happen in a vacuum, they happen as part of a mission
  • give the [insert role here] the tools they need to successfully complete their missions
  • you can't just make it part of the day-day to see how these things affect our days.
• Combat feedback

"The pretty lie is always more appealing the ugly truth"

There are parallels to software developers, software delivery teams, and software organizations.

You are going to have to put in the time

The phrase “Just because you can, doesn’t mean you should” is probably my most used quote when discussion Inc technology, and particularly in software development.

As part of some great leadership training over the last few years, I’ve learned it’s important to understand and think about the the origins for the quotes and phrases that we use.

Having a "technical partner" to work with Human Resource or Learning & Talent teams, finding ways to apply learning and talent development strategies to Software Development.

• onboarding programs
• competency matrix and progression
• tech talks
• team survey’s (ex: The five keys to a successful Google team)

Looking into Bicep as IaC that was referenced in John Reilly's article about Migrating from GitHub Sites to Azure Static Websites.

After adding a "post" and front matter on the home page, all formatting has been lost.

Failed on run Update index.md - Run 15

Specific error:

"sass" from sass conflicts with installed executable from sass-embedded

Create a new repository for the Proof of Concept.

Basic process

1. Using Test-Driven Development (TDD), complete first Red-Green-Refactor; push to changes.
2. Create initial pipeline to build project; push changes;
3. Require successful build for Pull Requests into Main branch.
4. Add unit test results to pipeline.
5. Add test coverage to pipeline.
6. Continue TDD.

Add Presentation Layer

1. Start with the basic process
2. Add continuous deployment to pipeline.
3. Continue TDD

Add Persistent Storage

1. Start with the basic process
2. Add continuous deployment to pipeline.
3. Continue TDD

From Dr. Royce's Blog:

Ray Kurzweil is an inventor and has been focused on the exponential speed of technology evolution and how it relates to human evolution. His kurzweilai.net is a great please to find out what the latest in technology in a number fields.

The Daniel Burres Blog and the Burres Technology Links are a great source of information on technology that should be on your radar screen. You can also sign up for an email on technology trends from his website or use an RSS reader.

Forrester Research Is similar to Gartner in that it is a consulting and IT Research company. It features the Forrester Wave as a way of rating technology and provides isite into the maturity of technology.

Gartner Group A consulting and research organization that has provided information on emerging technologies used by businesses for years. It was the creator of the hype cycle, Gartner Magic Quadrant and the Total Cost of ownership model.

Add a disclaimer to the website since I will be publishing content related to my work.

Disclaimer: The opinions and content on this site are my own personal opinions and do not represent my employer’s view in any way.

GitLab is a company I’ve watched for over the years and along with Octopus Deploy, gave us a playbook that we used to start a previous small business. I’ve always loved both groups because of their transparency, sharing, innovation, and the vulnerability to give the world visibility in the success and failures along the way.

Came across GitLab’s Remote Manifesto. While it is an all-remote manifesto, it feels like it is more like any organization’s 2022 version of the The Joel Test: 12 Steps to Better Code (circa 2000). While the reference may date me 😬 it still feels like I’m in my 20’s and just getting started.

The [GitLab] Remote Manifesto

All-remote work promotes:

1. Hiring and working from all over the world (instead of from a central location).
2. Flexible working hours (over set working hours).
3. Writing down and recording knowledge (over verbal explanations).
4. Written processes (over on-the-job training).
5. Public sharing of information (over need-to-know access).
6. Opening up documents for editing by anyone (over top-down control of documents).
7. Asynchronous communication (over synchronous communication).
8. The results of work (over the hours put in).
9. Formal communication channels (over informal communication channels).

My original Life Plan was created in 2014 and is in need of updating.

Start by using the same layout from the first one:

• core values
• big hairy audacious goal (BHAG)
• personal mission statement
• action plan
• accountability and measures

GitHub has some compelling new features for security.

• Evaluate the CodeQL functionality to learn what it can do
• Determine if CodeQL has any application to GitHub Pages

Paraphrased from Jocko Willing and rang true to the many times I’ve dealt with production outages, security incidents, and wide-spread outages like I experienced first hand during some of the first viruses/malware I remember like the Melissa Worm, ILoveYou Worm, and Vbs.OnTheFly (aka the Anna Kournikova).

If we’re not training, we're not prepared; if we’re not prepared, we overreact; when we overreact, we cause problems.

Initial thoughts:

• working 36 hours straight; the challenge, the rush, and the almost fatal danger
• recoding malicious vbs to clean itself-up
• asked to get in front of all it leaders, doing so, bombing (exhaustion, lack of planning), learning from it, and support/mentorship from those present after the meeting
• college speech from incident; impact to future communication (procrastination, false-positives from that)

Would be good to post my resume from LinkedIn on the website page to make it more public.

As a user, I would like to use third-party journal and markdown applications to compose post content and then export the content into my website, so I can focus on content writing without having to think about technical details like formatting, source control, etc.

As the site owner, I want to quickly add pages, so I can focus on adding content and not worry about naming and structure.

As part of taking the oath, research whether it's possible to not violate copyright to copy Uncle Bob's "Programmer's Oath" on the site.

Why?

• Keeps this front and center
• Publicly making this statement to be held accountable

To Do:

• Check to see if it's possible to replicate oath, with attribution links, on the website

2014 Core Values

• Family
• Morality
• Discovery
• Compassion
• Discipline

Got this from the book “The Undoing Project” by Michael Lewis.

Danny would tell his students: “When someone says something, don’t ask yourself if it is true. Ask what it might be true of.” That was his intellectual instinct, his natural first step to the mental hoop: to take whatever someone had just said to him and try not to tear it down but to make sense of it.

As a developer, I would like to evaluate GitHub Issue templates, to see if they will help make it easier to maintain issues and features.

These can help reduce documentation outside of the system (such as wiki’s, etc).

In managing software teams, it's important to carefully manage a balance between teams achieving results and attaining competence.

Most everyone loves to achieve a goal or reach a milestone, however, like with most things it's critical to find a balance. I think there's a saying about "Too much of a good thing..."

Introducing Test-Driven Development (TDD) and adding tests, is different than achieving proficiency (or even mastery) with TDD. Submitting multiple pull requests per story is different than understanding the benefits of merging code often, safely leveraging dark launch and feature toggling techniques, and working towards more frequent deployments with less change.

Achieving a goal is a boost and can help with motivation. Like consuming sugar, however, the "boost" is typically followed by a "crash." Competence in an area is much harder to attain. Similar to a "runner's high" or "flow" it takes longer to achieve but can offer consistency, and quality, and yield even greater results.

The data suggests (Accelerate) successful teams have a higher deployment frequency, get a requested feature to a user faster (lead time), faster recovery times, and lower failure rates (DORA metrics). As Accelerate quotes Jannes Smit, "You have to understand why, not just copy the behaviors."