Mad Skills - New Claude Feature

Anthropic released a new feature called Skills and I have been messing around with them. When I first read about skills it was not clear how they help. They sounded like what I have using Projects for in ChatGPT - a workspace with it's own context (memory). What I found is that they are different, but it is possible to use a Skill from Claude in ChatGPT.

My partner and I were playing a lot of Pokemon Go recently. So it seemed logical to create a skill using Claude to help answer some of the strategy questions we were discussing with one another.  

I created three data files that 1/ rules of the game, 2/ the requirements and rewards for each level, and 3/ some gameplay strategy data. I asked Claude to generate a Skill that helped players identify actions they can take to optimize their gameplay to meet various goals. I also included some examples of good optimizations and bad ones to help. Even given what I though was a thorough prompt, Claude came back with several questions to help define the scope of the Skill. Once we were satisfied it was "good enough", it produced a few files, the primary of which was a .skill file.

I played around with the Skill and it did a reasonable job. They key to getting the Skill to run was to 1/ ensure that it was uploaded and enabled in the Skill manager, and 2/ when prompting in Claude using keywords that ensured it knew to use the skill. The keywords are something that I went back and forth with Claude on when building the skill. In the end, it felt similar to using and MCP where there was an inference / mapping that Claude has internally to know what to call / use.

I think of Skills as having a predefined list of prompts that automatically called when needed.

Out of curiosity, I took all the files that Claude output for the Skill and uploaded them into a ChatGPT project. The question I was trying to answer is whether the Project would retain the context of all the prompting / data and behave similar to the Skill. Since the .skill file is just a zip, I uploaded each of the file individually. And it did work, albeit not as well as it did in Claude. My guess is that there were two contributors to the less outcomes; the first being that they are different models and the Skill benefited from the model that created it. Second that the ChatGPT Project did worse over time as the context of the Project grew with each subsequent chat (I am assuming you know how Projects work).

My takeaway. I like Skills,especially the help I get from Claude in creating them. I wish I could have more than 10 active at any time. That said, I will likely use a combination of both Claude Skills and ChatGPT (maybe projects). Why? I don't run into any daily limits with ChatGPT. I have the Pro version of Claude and I regularly run into limits and have to way until the next day for it to reset. It's frustrating that something like this and not the quality / usefulness of Skills is the reason for this bi-model usage. 

Addendum: I pay for ChatGPT and Claude now.

Very Sparkly (Evolving Thinking on GenAI)

Tired of my GenX references yet? No? Good, here is another one.

Let me explain. As you may notice from my more recent blog entries, "AI" is something I have been frequently thinking about. Especially trying to work through the hype, where GenAI is very sparkly and attention grabbing, to a place where I see how AI makes things better. Further, what is the intersection of my years of engineering and building AI solutions? Is there one? Take for instance this entry from a year ago where this journey started to gain traction for me. Or me thinking about Vibe coding back in July.

I’ve been thinking about what “engineering” even means now that anyone can spin up an LLM and build something that looks like it works. It’s too easy to confuse “the demo runs” with “the system works.” So here’s where I’ve landed - four realities that to consider. These are not my original work (thanks Nate), but landed in my conciseness at the exact right time.

1. If you can’t write the invariant, you haven’t engineered it.
This is the difference between vibe coding and engineering. “Make it work” is not the same as “define what working means.” AI gives you plausibility, not correctness. The invariant is what keeps you from gambling with probabilities and calling it architecture.

2. If you can’t measure it in production, you didn’t build it.
Anyone can make a demo now. Real engineering starts when actual users show up and start breaking things in creative ways. Observability isn’t a bonus -it’s the only way to know if the magic still works after it leaves the notebook.

3. If you can’t explain why it failed to a regulator, you haven’t owned it.
“The AI did it” won’t fly with the FDA, SEC, or anyone with a pulse. If you can’t walk a smart non-engineer through what went wrong, you don’t understand your own system. Ownership means accountability, not just implementation.

4. Good system design still matters.
Data is still the asset. Models are temporary. The LLM you love today will be obsolete in six months. Build so you can swap the engine without rebuilding the car. The fundamentals haven’t changed - only the excuses have. The data represents your value / asset, the LLM is a processor to help you realize the value of your data.

Bottom line: these form a lifecycle - specify, verify, and own. The tools changed. The responsibility didn’t.

 

Can You Feel the Vibe?

“Vibe coding,” if we have to name it, is the instinct to follow an idea straight into a running system before the bureaucracy wakes up. It’s intoxicating. It’s useful. And left alone, it’s shadow IT with better syntax highlighting.

So: keep the spark, lose the shrapnel.

The Instinct Is Fine. The Invisibility Isn’t.

People aren’t vibe coding because they hate process; they’re doing it because process is slow at the exact moment their brain is fast. You know this dance:

• The idea shows up fully formed (or close enough).

• You need a REPL, a repo, and a data source—now.

• Every extra form to fill is a chance the idea evaporates.

We can wag our fingers about “proper intake” or we can design a place for this energy to land safely. The behavior isn’t going away. Pretending it will just pushes it deeper underground.

Design a Sandbox, Not a Maze

Imagine a paved path that feels like a dirt trail. That’s the job.

I want a sandbox where anyone can mash ideas into code, hit “deploy,” get real feedback… and where we still capture an audit trail, enforce basic guardrails, and promote winners to the grown-up pipeline automatically. Freedom up front, governance in the substrate.

Call it Spark → Prove → Promote:

1. Spark (Fast & Loose, but Logged):

   • Spin up a temp repo/branch from a template (vibe-template), auto-tagged as experimental.

   • Ephemeral env with pre-approved IAM role, read-only test data, and a 24-hour TTL.

   • Everything auto-logs: who did what, when, and which data they touched.

2. Prove (Make It Real Enough):

   • Smoke tests or a tiny checklist: “Does it run? Is there a README? Any secrets in code?”

   • Observability baked in (stdout goes to a sandboxed log store; errors page you, not the on-call team).

   • A lightweight “promote” button that kicks off a review workflow.

3. Promote (Graduate or Archive):

   • If it’s useful, a pipeline migrates code to the main org, assigns owners, and wires alerting.

   • If it’s junk, auto-archive and clean up the infra. No guilt, no clutter.

A win is a win. A miss evaporates without leaving landmines.

Guardrails Without Killing the Vibe

Here are the rails I care about. Most are invisible at run time, very visible at audit time.

• Identity Everywhere: Every scratch environment is tied to an actual person and a ticketable artifact (even if the ticket is created behind the scenes). “Anonymous Lambda” is not a vibe.

• Data Diets: Only synthetic or scrubbed data in Spark. Production data is opt-in, logged, and red-flagged. Boring but mandatory.

• Ephemeral by Default: Time-to-live on resources. If no one renews, it self-destructs (with polite warnings).

• Policy-as-Code, Quietly: Template repos include OPA/Snyk/whatever scans that fail hard on secrets and license issues. People shouldn’t have to think about it; it just works.

• Observability from Line One: Drop a logger, get a dashboard. If your experiment crashes, you get the ping, not PagerDuty at 2 a.m.

• Clear Promotion Path: Don’t make success painful. One click (or simple PR label) should kick off “make this production-ready” automations: code owners, IaC modules, secrets rotation, etc.

Tiny Example: The “Vibe Template” Repo

# vibe-template/.github/workflows/ci.yml
name: vibe-ci
on: [push]
jobs:
  test-n-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: pytest --maxfail=1
      - name: secret-scan
        uses: trufflesecurity/trufflehog-actions-scan@v3
      - name: opa-policy
        run: opa eval --fail-defined -i policy.rego -d src

Nobody asked for a pipeline. It’s just there—fast, opinionated, and loud only when something’s wrong.

Three Questions Before You Push “Run”

If you’re about to vibe code (or bless someone who is), ask:

1. Can this leak anything we’d be fired for leaking? No? Proceed.

2. Will anyone be paged if this melts? Yes? Rethink. Make the blast radius yours.

3. If it works, do we know the next step? Success without a path is just future pain.

If you can’t answer those in 30 seconds, your sandbox isn’t sand enough.

What This Looks Like for Real Orgs (i.e., Us)

• Platform Team: Builds and owns the vibe platform: templates, ephemeral envs, guardrails code. Think “internal Heroku for experiments.”

• Security/AppSec: Codifies “thou shalt not” as policies embedded in the template, reviews the promote stage, not every commit.

• Engineers/Analysts/Whoever Codes: Use it guilt-free. The rule: if you’re outside the sandbox, you’re in grown-up land and the rules apply.

• Leadership: Measures outcomes: # of experiments, # promoted, lead time from idea to prod, incidents caused by experiments (ideally zero). If the metrics go the wrong way, adjust guardrails—not the concept.

Why Bother?

Because the alternative is either (a) slow innovation or (b) silent innovation. Option (b) feels faster until the audit hits, or the clever Lambda starts costing $20k/month in egress fees.

We can have speed and safety. We just have to engineer it. (Shocking, I know.)

---

TL;DR (Because I Know You Skipped)

• Vibe coding is happening. Engrave it in policy or pretend it isn’t—your choice.

• Build a paved sandbox: Spark → Prove → Promote.

• Guardrails = identity, data boundaries, ephemeral infra, policy-as-code, built-in observability, smooth promotion.

• Success path must be easier than stealth path. That’s the only lever that actually works.

Keep the spark. Lose the shrapnel.

The need to be right?

Maybe you've been here too—that irresistible urge to be right. Whether in meetings, conversations, or even casual debates, there's something deeply satisfying about knowing the answer or how to do something. But here's the tricky part: the need to be right can become a serious obstacle in leadership.

Leaders can be driven to continuously prove themselves correct, often unintentionally silencing their teams. When we put being right above getting it right, we risk creating an environment where others hesitate to share ideas, challenge perspectives, or offer valuable insights. The result? Innovation stalls and creativity takes a back seat.

Think about the best leaders you've worked with. They probably didn't insist on always being the smartest person in the room. Instead, they focused on bringing out the best ideas, regardless of who proposed them. They were comfortable admitting they didn't have all the answers, opening the door to collaboration and collective problem-solving.

Here are the things I am working on to continuously improve in this area.

1. Humility. Recognize that no one has a monopoly on good ideas—not even the boss. Being open to learning from your team creates trust and invites diverse viewpoints.
2. Prioritize outcomes over egos. My goal is to achieve the best result rather than validate my personal viewpoint. I need my team to fulfill the vision and outcomes. Giving them room to do it their way allows them to learn from experience rather than being told.
3. Listening. Slow my brain down and not plan my response. Just listen. Discuss without answering or directing. I have been rewarded by watching people arrive at the "right" thing in an entirely different way.

Remember, leadership isn't about proving you're right but empowering your team to find the best path forward together. So the next time you feel that urge to argue your point, pause and ask yourself: "Am I trying to be right, or am I trying to get it right?" 

P.S. This is good advice in a relationship.

The Way the Rest of the World Builds Stuff

Turns out that once you leave Amazon, there is a lot to learn about the way the rest of the world builds systems. That was part of the reason that I joined a relatively small company; building things at scale is different.

For context, we are a relatively new company formed when two smaller organizations merged. They each brough different technology and the related skills with them. For instance, we have systems on GCP, Azure, and AWS. Some applications make use of Kubernetes, some rely on WordPress. 

Today we discussed how teams / services implement continuous delivery and where one team's capabilities better align to our vision / roadmap. We walked through the use / use cases for the following technologies. It was humbling and exciting to hear about a handful of products that I have little-to-no experience with.

The following are a few of the places we discussed.

1. Flux CD - https://fluxcd.io/
2. GitHub Structure like = https://fluxcd.io/flux/guides/repository-structure/
3. Argo and/or Flux - https://ferrishall.dev/flux-cd-vs-argo-cd
4. Rancher Desktop - https://rancherdesktop.io/
5. Helm - https://helm.sh/

Learning new stuff is fun.

A Brief History of Time - AI Style

My wife and I are trying a new approach to a book club and incorporating AI.

There are some books that we (both) have that we have tried to read, read part of, or never really go going on. Our choice of book is something of interest, but we experienced friction / lack of motivation, and never started / finished it. We are hoping that this new approach will create a better understanding of the book than we would get from just reading cover to cover.

We are "reading" them using the LLM of our choosing, ChatGPT, Copilot, etc. and it goes something like this. Hey ChatGPT, give me a summary of chapter 1 of "A Brief History of Time" by Stephen Hawking. We read the output and then we use our curiosity to explore further. For instance, some of my follow up questions were...

• 
  How well did Ptolemy’s model work? Was it 100%. Why did it take so long to get to the heliocentric model?
• What is the notion of predictive power in scientific theory. Why is it important? What is the most influential / significant use of it?
• How is the age of the universe calculated? How has it evolved over time?
• How can everything be moving away from each other but still galaxies collide?
• What is the force of gravity that our galaxy and the andromeda galaxy exert on one other? Which exerts more force on the other? Are either gravitationally bound to other galaxies?
• How can I envision dark matter? Is it clustered together in different places, like puffy clouds. Or is it spread out like fog over vast areas? Is it moving? Can we indirectly see dark matter outside of its gravitational pull, like lensing?

After asking more questions I wrapped up with...

Is there any concept in the first chapter of brief history of time that we haven’t explored in our conversation here?

Which led me to ask a bunch of other questions. This continued for about an hour. I already read the first half of the book, and it covers topics I already have a little understanding of. This approach allowed me to explore in different nooks and crannies that I probably just took at face value when I originally read the book. This approach feels somehow...better. I am not just reading the words but also thinking about them and trying to understand deeper and/or map them to my world view.

The next step after both of us have wrapped up independently exploring a given chapter is that we discuss it together - like a book club. What did you find interesting? Surprising? Don't quite get yet? Did you explore areas that have little or nothing to do with the book (squirrels)? I expect our discussion to be "interesting" in that we come at things from different angles; I am more the analytical/science person, and she is much more the spirit/artist.

There is also the side benefit (not to be underestimated) of doing something together to keep things interesting. Stay tuned.

Trying out AI - Rebalancing my Investments

I keep looking for ways to leverage AI both at work and in my personal life. Recently, I asked for help rebalancing my portfolio. The following is a series of prompts that I used to get there.

The first step was to document my holdings. I have accounts across several management companies and about 100 different assets. I tried to export them from each company, but none had an export feature. This is where I started using ChatGPT to parse my statements and export them as a table. 

Using the attached investment account statement, extract the current holdings from the document and give them back to me as a CSV file.

I worked with ChatGPT to correct this, as it would only read a page of the data. We went back and forth several times before I got the results I needed, including looking up the expense ratio for every mutual fund and EFT. Next, I described how I wanted my portfolio to be rebalanced.

   

Balance my portfolio rooted in Nobel Prize-winning economic theories would emphasize diversification, broad market exposure, and risk management. Allocating across asset classes using the following: Portfolio Allocation Equities (60%-70%) Domestic Equity (35%-40%): Broad exposure to U.S. stocks via total market or S&P 500 index funds. Include a small-cap tilt (e.g., small-cap value funds) to capture the small-cap premium identified by Fama and French. International Equity (20%-25%): Diversify across developed markets and emerging markets. Consider including small-cap international funds to enhance diversification and returns. Value Tilt (10%-15%): Increase allocation to funds focusing on value stocks (high book-to-market ratios) to capture the value premium Fixed Income (30%-40%) Domestic Bonds (20%-25%): Investment-grade government and corporate bonds for stability. A portion in inflation-protected securities (e.g., TIPS) to guard against inflation risks. International Bonds (10%-15%): Include exposure to developed market and emerging market bonds to diversify currency and interest rate risks. Alternative Assets (Optional: 5%-10%) Real estate investment trusts (REITs) for exposure to real estate. Commodities or other diversifying assets if aligned with the investor’s goals. Cash and Cash Equivalents (5%-10%) For liquidity and short-term needs, including high-yield savings, money market funds, or short-duration Treasury bonds. Design Principles Market Efficiency: Avoid active stock picking or market timing, as the Efficient Market Hypothesis suggests these strategies rarely outperform Diversification: Use a fund-of-funds approach to spread investments across many asset classes, sectors, and geographic regions, reducing unsystematic risk. Small-Cap and Value Tilt: Emphasize small-cap and value stocks to capitalize on their historical outperformance as identified in the Fama-French Three-Factor Model. Risk Management: Use a mix of equity and fixed-income securities to align with the investor’s risk tolerance and investment horizon, reflecting principles of Modern Portfolio Theory. Low Costs: Prefer passive index funds or ETFs to minimize expenses and maximize net returns. The attached file lists my holdings across accounts, with the last column being the account name those holdings are in. Balance all my holdings listing unique transactions. Below is a table with a list of my holdings across accounts. The first row is the column names. The last column being the account name those holdings are in.

It took a bit of coaxing to get a final portfolio. First, I have my holdings across five separate accounts, and getting ChatGPT to balance across accounts took a bit prompting. Some accounts had cash that would not get invested, so I had to remind it that the goal was to have between 5-10%. Another prompt resulted in more mutual funds with high cost ratios, which I wanted to minimize. So I added a prompt specifying that any mutual fund or ETF should have a cost ratio of .05%.

Once I had a portfolio rebalancing working the way I wanted, I asked for a list of transactions needed to archive that portfolio. This resulted in some weird side effects where there were too many trades resulting in lots of transaction fees, so I added an instruction to minimize the number of trades. If I already owned Apple in one account, don't sell it if also going to buy it in another account.

Transaction sheet - holdings and quantity have been changed (using yet another prompt)

I ended up with a list of trades to perform across each account. I don't know about you, but I have taken notice of that warning at the bottom of the screen recommending that any output should be double checked. So that set of prompts began.

I asked for the details of why each security was chosen, what rule(s) / criteria were used and what the amount specific was chosen. The output was very informative and is what I used to check the BUY transactions specified. I didn't find anything wrong. I further probed by asking which other securities were considered for each buy and why the one recommend was selected over the others. The following is one of the securities from that details.

Fund Selected: Fidelity Total Market Index Fund (FSKAX) • Expense Ratio: 0.015% Selection Logic: • Broad Market Exposure: FSKAX tracks the Dow Jones U.S. Total Stock Market Index, providing comprehensive exposure to the entire U.S. equity market, including large-cap, mid-cap, and small-cap stocks. • Low Expense Ratio: At 0.015%, it is one of the lowest-cost options available, aligning with your preference for minimizing expenses. • Fund Size and Liquidity: With significant AUM, it offers high liquidity and stability. • Alignment with Strategy: Provides a foundation for the Domestic Equity portion of your portfolio, supporting diversification and market efficiency principles. Other Assets Considered: • Vanguard Total Stock Market Index Fund (VTSAX): Expense Ratio of 0.04%. Not selected due to a higher expense ratio compared to FSKAX. • Schwab Total Stock Market Index Fund (SWTSX): Expense Ratio of 0.03%. FSKAX was preferred due to the existing relationship with Fidelity and slightly lower expense ratio.

I found this all very helpful and it helped me to trust (or not) the trades recommended. 

What have I done with all this information? Nothing, yet. It's not clear to me if this was anything more than an intellectual exercise. It was very cool and I learned a couple of things - patience being a big one. It took me ten hours (over four days) to complete all of this. This is a reasonable time investment considering an advisor offered to do the same thing for an annual fee that was in 2% of holdings range!

It's all Ball Bearings (AI) These Days

I saw recently that Google and Amazon announced how much AI they use to generate code, Google in percent, and Amazon in hours saved. There has been a lot of hype that it is all AI these days. Over the summer, I played around with different AIs to get my head in this space to see how much is hype.

I built a few Python apps in Google Colab to detect license plates in a video stream from my bike rides. Colab uses Codey and Gemini, and they did an excellent job of getting me started as someone who didn't know Python or the libraries available. I am a trial-and-error learner who tries something and, when it doesn't work, refers back to references to figure out why. At one point, I had a working app and asked how I could change the implementation to be multi-threaded, which it did. It didn't work, but that resulted from Colab and not the code generated.

In my new job, I make a point to use ChatGPT, GitHub Copilot, and/or Claude a few times a week. Last week, I asked it to create two apps for me; a random people picker as a spinning wheel and an out-of-office (OOO) helper. The spinner took me about 15 minutes to get right, so I repeatedly asked Copilot to modify the implementation to get it the way I wanted. In the end, it was close, and I made minor changes to the CSS. The exciting thing about this approach was that I iterated with Copilot to turn the implementation instead of finding completed implementation(s) and Frankensteining them together.

Where it has yet to work well for me at work is melding technology with the specifics of my organization. For instance, what does an executive dashboard look like for our ecosystem? Or what is the best way to configure the on-call paging system across our teams? Sure, I asked if there were any best practices or pitfalls others have run into, and the answers were very generic, which is what I would expect.

My experience and intuition suggest that we can benefit from leveraging AI. As I build the 2025 roadmap, I am encouraging the team to consider how AI or AI-powered products can help us achieve more and faster.

Exploring DORA

We are considering implementing DORA metrics to help track and improve our outcomes. I had never heard of the term DORA, but most of the metrics rolled into this moniker I have a history with. As part of the discussion around DORA, we met with a few vendors whose products integrate with GitHub, Jira, etc., to surface metrics. While we didn't end up purchasing a product to help here, it wasn't because we needed to see the value of DORA. On the contrary, we value the outcomes that DORA metrics (et al.) are after; it is more about timing. Through acquisitions, mergers, and growth, we have a diverse group of teams, each at different maturity levels and mechanisms around SDLC. Starting to track DORA-esque metrics when a team may be working to climb up on the maturity curve seems premature for a few reasons. First, we should focus on helping teams up-level their SDLC. For instance, CI/CD is good, so everyone should do that. Second, most mechanisms have some metrics as outputs that we can leverage. If you're doing Scrum, are you tracking the key metrics or meeting every two weeks to plan work? Lastly, we need to be careful when comparing across teams that don't do the same thing or have similar needs. The apples and oranges analogy exists because it works.

As a team leader looking to uplevel the entire engineering organization, DORA and products that capture related metrics sound attractive from a centralized visibility perspective. Being new to the organization, I know relatively little about each team's maturity level, but many feel there is room to improve. Does that mean we are not going to track any DORA metrics? Of course not; we will track the ones with shared mechanisms and leverage that data. Measure, identify, improve, repeat.

P.S. I was pre-Dora The Explorer. But my kids weren't. Geography interests me, so this Dora is fabulous in my book.

Suddenly I Need to Think About My Safety

Personal safety has changed for me. 

I have not posted much, if anything, about my experience as a transgender person. Mostly because I am a private person. If you want to know why I don't like condiments, no problem. But at work or on social media, I tend to separate my private life from my public life. I think it's no different than people not bringing up topics like their marriage or conceiving a child; it's about having boundaries.

Boundaries are about safety. At work, boundaries support myself and those I interact with. Who knows what is going on in someone's life that will trigger them and make them feel unsafe. That doesn't mean I suppress my private life or who I am, but I will not push it onto others. Like in a previous post, I don't know what is happening in anyone else's life, and I respect that they may want to keep it that way.

Building on boundaries...some folks no longer have boundaries; they are willing to say almost anything, especially on social media.

I've been watching the show Will and Harper on Netflix and was troubled in a couple of ways by the part where they went into a Texas steakhouse together. If you're not familiar with the story, Harper is a friend of Will's from Saturday Night Live and is transgender. Will Ferrell, being who he is, attracted a lot of attention from the other patrons at the restaurant. Some of those patrons wrote terrible things about Harper and tagged Will on social media.

I relate to that story because safety is something I need to think about now. My transition is not something I talk about, and most people are respectful enough not to ask. I appreciate that since, as a transgender person, I often don't feel safe. I say this not to compete with any group; but because of the realization that I went from the top of the privilege hierarchy to a spot much lower. There are many states that I would be uncomfortable spending time in, Texas among them. I recently needed to travel to Dallas for work, so I took several precautions to ensure my safety. My former privilege told me that I was overreacting. But wait, there was my experience in Nashville a few years ago when I was alone and physically/verbally confronted by some huge/drunk men. I was terrified and stunned, this was an entirely new experience for me. It worked out "OK" because I literally ran away, but it was one heck of a wake-up call.

It's this fear/concern for safety that exists for most transgender people and drives the generalized suspicion we feel. It is hard for me to be suspicious that way, but some things have transpired this year, and those suspicions explain many things. Too many things. This is where allies become essential to help with boundaries and safety. The next night in Nashville I asked a friend to walk me back to the hotel, but what about the less obvious things? I need your help there too. 

The revelation for Will Ferrell around what life was like for his friend is something that I wish everyone could understand. It was clear from his reaction how big of a revelation it was for him - how his actions led to the threats on social media. Harper and I are both white trans-women who transitioned relatively late in life and so enjoyed the benefits of our privilege for longer than we won't. It is so much worse for people at the intersection of race and gender!

I need your help to remain safe beyond my physical safety. Stand up to locker-room talk, gossip, social media, bias at work, etc. activities. It will require you to step outside your comfort zone. I hope you can find the courage.

 

Try Noodling on That

The name of this blog is a reference to words uttered by a friend of mine. He also added the word "noodle" to my vocabulary, which is synonymous with thinking in this context. Not to be confused with a Noodle the pug who prognosticated on what type of day we could expect to have.

Whether to myself or someone on my team, I often use the phrase "noodle on that" when the answer is non-trivial and analysis and logic are not yielding a solution. It can be relatively straightforward—I need an answer to this problem—or something more abstract—like ideation. Either way, there are times when looking for an answer is more like chasing something elusive. Finding the answer is often further compounded by some time pressure - I need to solve this by XX.

Enter Noodling.

Several times, the answer presented itself to me - but only when I took the pressure off myself. For instance, I was cramming for a math final, and the answer to a particularly gnarly calculus problem came to me in my sleep. It woke me up, presumably so I could write it down (ha). Another time, the answer came to me in the shower. Someone once attributed this to all the positive ions stimulating my brain. Whatever the reason, it's a thing - Shower Epiphanies.

As a manager, I have often suggested that they take a break from trying to solve the problem directly and noodle on it. Give yourself a break. Let the pressure off. Give your subconscious a chance to work on it. My anecdotal data is that it works the majority of the time. This has the additional benefit of letting people work it out for themselves. My belief is that things feel better when people figure something out on their own, as opposed to me giving them the answer. 

See you on comfy mountain. IYKYK.

A Brief History of Integrating

I was recently asked how I would integrate systems with similar functionality but different code bases and infrastructure. It got me thinking about how I feel I have been solving the integration problem throughout my career and how it (not surprisingly) keeps coming up. My answer was: It depends on what you have and where you want to land. I have many questions: how much of the data is the same? How reliable is the data? Is there an appetite to reduce any duplication? What is the desired recency (age) of the data? Is there a goal to become more homogenous? Regardless of the answers, I have employed several strategies/technologies over my career.

One of the first implementations I worked on was a practical solution for a PC-based application to leverage COBOL code on the mainframe. The company had invested years in the code and was not ready (or able) to rewrite it. We built an LU6.2 gateway to call the mainframe and pass data to the COBOL file's copybook. This was such a common need that later, Microsoft wrote an LU6.2 connector to create a code proxy from the copybook for you. Here we are 24 years after Y2K, and I am willing to bet that the banking and finance sectors still have a bunch of COBOL being used.

During the Object-Oriented boom, there was a big push to build an Enterprise Service Bus (ESB). We talked about technologies like MQSeries, CORBA, and RPC as ways to implement an ESB. I never saw an ESB I liked, probably because so many were never finished. Instead, I watched enterprise architects trying to resolve the enterprises' requirements into something for everyone. It's hard enough to nail this down for a single business line in an enterprise, much less many/all of them.

To some extent, we used databases as the point of integration. One system would be declared the data owner and copies of that data would be made for use by others. At the time, I saw this strategy fail more often than it succeeded because the copy would become stale and not meet our customer's expectations. Nowadays, we make copies, but it's less about integration and more about scale. To succeed, we had to figure out how to work in the world of eventual consistency.

As I shared these examples, I couldn't help but think of a few other topics. But these are the ones I wanted to share. If you've been in this industry for any time, I'm sure you have your own integration history. Integration is a persistent problem, a challenge that we all face, and it's safe to say that it's not going away anytime soon.

Things That Make You (Me) Go Hmmm

I saw a snippet of Captain Hindsight from South Park the other day, and it made me think of a couple things that have been rattling around in my brain lately. My initial college major was teaching history and political science; I changed after my freshman year to computer science. I still like teaching and history. Lately, I have been looking into challenging history as I was taught, looking to understand more of the complexity and unbiased events. For instance, I have been reading about the 1980 "October Surprise" story surrounding the release of the hostages from Iran. The timing of the release of the hostages was always a little suspicious, but not so much that I thought there was something else going on. In retrospect, there is much circumstantial evidence that it wasn't on the up and up. 

Hmmm. 

Where am I going with this? Hang with me.

You would have to live under a rock not to have heard unfavorable news about Boeing over the last few years—the 737-Max, 777 a whistleblower dying, and door plugs not being secured. Some people point to a more significant cultural change at Boeing that can be traced back to Harry Stonecipher, a protege of Jack Welch. For more on the Boeing story, see "Flying Blind" by Peter Robinson.

Hmmm.

I am getting to the point, really.

This got me thinking more about Jack Welch and how he made Six Sigma a pillar of his business strategy. As someone who has led medium-sized teams and big projects, I have always been cautious of Six Sigma. Like most things, it was started to meet a need and add value, but my experience has been that it's become something else. At GE, it was weaponized and became a "religion" to help with the culture. Want an example? Stack-rating employees, considering the bottom 5% of expendables, can be traced back to practices at GE. This practice has become common at most companies I have knowledge of. As a manager, I have had to use this practice on high-performing teams and replace the "bottom" person. The position stayed open for a long time because the person we managed out was very good and not easily replaced. Now imagine teams/organizations playing politics and/or pushing an agenda and how this can be used as a weapon.

Hmmm.

Funny how more information comes out over time, and it changes the narrative. Makes good fodder for someone who likes to learn.

Is Doing the Right Thing - Right?

For most of this year (the last nine months), I have been pondering whether doing the right thing is right. Let me clarify. For me, doing the right thing in the context of honesty or integrity - is ALWAYS the right thing. Is doing what I feel is the right thing to do - the right thing? I have been noodling on specific circumstances that have me questioning whether I did the right thing based on how they turned out. 

There were two circumstances where I put others' needs ahead of my own, and it didn't work out. It is not nearly as noble as when Spock sacrificed himself in Wrath of Khan, but it is my little drama. The binary part of me looks at these situations and sees the only alternative as never putting others first and looking out only for myself. Even writing that down makes me grimace, as it goes against my core beliefs. So, the answer must be in the vast gray area between what I did and doing nothing. In the classic answer for all questions, it depends.

Regarding the two circumstances I have been pondering, the others were not in their integrity, making that the easier thing to focus on. I put others (people, projects, etc.) first and myself second, and it didn't work out as I had hoped. As I healed from that, I was able to begin considering where my learning was. Even if it's a one-off, I won't trust that person in the future.

I have been thinking about reciprocity in this context; doing something for others (entities or people) without expecting what I may get in return. Being a manager/leader is being in service. The thing I struggle with is whether that also requires selflessness. My recent experience is that selflessness in the workplace is a minefield. First, it's not very likely to happen - it's just the nature of companies, especially large ones. Second, I must acknowledge that I sometimes have expectations hiding behind my actions. They may be as simple as looking for a smile, but expectations nonetheless. That doesn't make my decision/activity wrong; it just exposes that I had some expectations. It's the missed expectations that led to my disappointment.

Ultimately, I feel good about what I did and my reasons for doing it. I would make the same choice again, looking out for any expectations I have. It also means that being selfless does not mean sacrificing myself. So, maintain my integrity, do what I believe right, and watch out for personal risks.

Who I Work With is a Choice

Since leaving Amazon, I have been recharging and considering what I want to take on next and with whom. I followed a similar process in 2013 when I last looked for my next opportunity. Then, I gathered a list of the top 10 companies I respected and focused my search on those. I needed to align my principles with the companies that aligned with them. This led me to also form a list of companies that didn't align with my principles and exclude them from my search. As a result, I passed up some well-paying opportunities.

For instance, Amazon was on the list in 2013 because of my experience with no-hassle returns and Amazon Prime. Secondarily, it was the technology, tools, and innovation.

A lot has changed since 2013, including my prioritization of principles. For instance, after the 2016 election, I am paying more attention to politics. It's not a party affiliation but rather a candidate and their policies. It is a contradiction to say you support me as a transgender person and then support policies that limit my freedoms. It's also about the larger company culture concerning diversity, equity, inclusion, social impact, and corporate responsibility.

From what I hear and see, the job market is in a cycle where it's challenging to land a job. I can feel the tension between landing a job and standing by principles. It's a choice.

Ultimately, it's not a choice for me. I have not been happy when I have worked with less principled teams. I am the type of person who wants to wake up in the morning and is glad to be working with the company/team. That does not mean it's easy or there are no challenges. But it does allow me to be myself, be comfortable asking for help, know that I will get help, and pay it forward by helping others.

Do or do not. There is no try.

I recently dreamed I was in a large audience where an unidentified leader asked for a volunteer to lead a big project. They looked at me, and I said something like I will try, but I couldn't do it alone. Someone else stood up and said they would take on the project, and I could feel the audience staring at me with disdain. So much so that it woke me up.

I am not the type of person who looks for a lot of meaning in my dreams, mostly because I don't remember them. But this one woke me up, and I spent the rest of the early morning lying in bed, considering why it bothered me.

This was similar to talking to others and asking them how we get something done, and their answer is something like, "We don't have the resources." That wasn't the question; the question was, what would it take? My dream was similar because the question was not, "Would you deliver this project by yourself." It's not a question of ensuring a successful outcome; it's a question of pulling together enough for a reasonable discussion on feasibility.

The response I would guide my dream self to give is: Sure, I will lead that big project for you. Then, I would document what it's going to take to get it done and present that to the stakeholders. 

This dream bothered me because I was settling for trying when I knew better.

My Experience of APIs

I watched Nate Jones's TicTok last week. He talked about how APIs are becoming the interface to data. As I noodled on his words, I agreed with him, and it got me thinking about my history with APIs - more generally than his point.

I have been developing or calling APIs for a long time, and this got me thinking: weren't the MSDOS interrupts (related post) a form of API? We all know the right answer, so we will not say it out loud and move on.

But seriously. I remember creating an API for the DOS terminate and stay resident (TSR) module I wrote as the proxy for the server-based DBMS we wrote. This API used INT2F as the interface to the TSR.  We didn't expect CBASIC programmers to code to INT2F, so I had a callable C library that abstracted the internals. What we built was closer to something like ODBC, a generic API for retrieving data requiring you to write the query.

There was a period when our systems had a business layer and a data layer; the business layer represented business semantics, and the data layer represented the sproc/view/query/table structure. Weren't these all APIs? During the object-oriented period (which sounds like the Jurassic period), I didn't refer to them as APIs then; they were methods on an object.

We went from RPC to SOAP to REST, each an evolution to build distributed systems. All these are forms of APIs as well. Why? APIs are about creating a dependable contract that callers can depend on to create an outcome—not about the specific implementation technology. The "interesting" part of the API design process was how to design for reusability. And by interesting, I mean the part we spent a lot of time discussing. In the Enterprise IT space, we had enterprise architects who created taxonomies, libraries, and APIs that modeled the data and/or the business processes. Building models/services for the entire company didn't work, and a "single responsibility model" and "separation of concerns" were needed. Even now, we have engineers who have API design as a skill we depend on and use at some level of governance.

From these evolutions (and more) of APIs, I have learned they are hard. Why? Because API design is hard. Why? Because reuse is hard. This is why when we talk about APIs today, we don't think of them as static. Instead, we build them to be extensible as the needs evolve. Even designing for evolution, I have had more than my fair share of painful API deprecations.

I still love a good API design session.

Surprisingly good project estimation

At Amazon, we went through several cycles/iterations of planning. Regardless of how Agile an organization operated, we needed to map capacity to the roadmap to understand how much we could deliver in a given year. This does not mean we actually delivered exactly what we initially planned since requirements and priorities changed over the course of the year. But it did allow us to have a starting place that we used to have a shared vision across engineering and stakeholders.

For each iteration, I would strive for better accuracy by asking technical leaders to revise their estimates. Effort was the input we refined the most, asking teams to go from swags to more educated estimates. How much were they relying on existing services? How much had never been done before? I had a list of prompts to help them assess the complexity/unknowns and, therefore, the risk. I would take all that and put it into my model (i.e., Excel), which would auto-magically create a calendar plan.

Invariably our leaders always requested when we would be "done," typically in the context of something like Prime Day or re:Invent. To answer this question, I would use a scaled-down version of the organization planning spreadsheet. Typically, the project was underway, and varying levels of design were complete. Most of the time this meant that the effort estimates were better, and the number of resources available was known. For each estimate, I would ask managers to provide me with the factor they used to compensate for PTO, meetings, etc. - I called it non-keyboard time.

Anecdotally, the static model usually yielded a surprisingly accurate date. I would use it to drive discussions around resource and/or feature tradeoffs depending on which knob we were using to tune the outputs (typically the launch date).

Such a simple model gave many people heartburn—"How could something so simple model something so complicated?" I tried "enhancing" the model to account for other factors, for instance, parallelization. However, it was too complex to model and required too much from engineering managers or technical leads. Parallelization is needed when building a plan but doesn't work when doing estimation—it simply didn't improve the model. 

The problem was that many leaders would simply not believe the model. I found this very frustrating since they would usually choose a somewhat arbitrary date as to when they wanted to be done and tell me to use that. I would challenge that approach and eventually agree since it was obvious that they were going to get their way (an anti-pattern of Amazon's Have Backbone, Disagree, and Commit). Side note, one time, I escalated a case of this, and while the VP I escalated to was appreciative, the Director threw a tantrum in the meeting. So much so that the VP later contacted me to apologize for the Director's behavior.

In project retrospectives, we discussed how we course-corrected throughout the project. It turns out that the early model outputs were right—scary right?

I have been around long enough to know that when bringing in the date, leaders are often pressuring the teams to keep their foot on the gas. Something to watch out for is that this practice can lead to the outcomes I describe in my "Secure Apps Take A Village" post. Some of this behavior comes down to a couple of challenges leaders (including me) have to grapple with - trust and giving up control. Trust (and verify) what my teams are telling me, and accept that I don't have the same level of control I used to. Both are probably topics in and of themselves.

Things that I ran into...

1. Inflated efforts. Managers and leads pad their effort estimates to ensure they meet commitments. First, how do you know if it's inflated? Who better to know the complexity of a system than the people closest to it? If managers are really doing this, then do they understand what is being asked of them? How will it be used? If managers are padding, they are responding to a fear typically rooted in the organization's culture. This is something to go deeper into to figure out how to make it work for you.
2. Low efficacy factors. Given that keyboard time is an input into the model, this will directly impact the date/resource calculation. Is a low number accounting for a less experienced team? Or is the manager using the same number every time? Why—to pad dates? I used a generously low number, which was painful to write down but proved to be more accurate. For instance, this was especially true for teams that had high operational overhead.
3. What is DONE? Of course, done is something that not everyone defines the same way. As the owner of a launch, done to me meant the system was launched and open to customers. Invariably some folks would define done as some level of completeness for their code. Ensure that everyone is aligned on what done means. I would typically use code complete, including all automated tests and the binaries, in a shared test environment. I used this as done since the cost of integration testing and other launch activities was typically shared across teams, and I could estimate those differently.

Secure Apps Take a Village

I reflect on recent experiences and the tension between rolling out features and ensuring the product is secure. Features are flashy. They make good keynotes and/or demos. Features get customers excited and make money.

Security is about the backend. It's not flashy. It's hard to demo security; you probably wouldn't want to even if you could. But when something goes sideways, a security issue will lose you customers. It's like giving your competition bullets—"Hey, did you hear about that security breach at Acme?"

Security is getting more complex and more challenging to do well. Sure, we are smarter and better understand vulnerabilities. However, applications are also becoming more complicated (e.g., log4j and versioning). Complexity makes security harder—it just does. The bad actors are as determined as ever, and their methods continue to evolve.

I attribute much of this tension to the organization's culture. A typical culture pattern is when leadership compresses engineering estimates, and as time runs out, security verification takes place. This leads to pressure to complete verification and remedy errors without impacting the date. Regardless of the number of times that leaders tell people how important security is - actions speak louder. We must ship at this point in the project, leaving uncomfortable conversations and hard choices. 

The tension between shipping and being secure starts early, when most of the time is spent discussing/planning customer-facing features. Sure, security comes up, but in my experience, it gets a different in-depth consideration. If we are lucky,  the challenging security conversations/decisions are before we launch - and not after. Talking about security feels more like a bad thing when it's this late. Further contributing to this tension is when leaders push to make a date, a security issue is identified, and in response, they make statements akin to - "Security is always a priority, so when I push on the date, my expectation is that the system is still secure."

Imagine a product where this culture goes on for a long time; the product is very successful and lucky that lurking security issues are private. With some certainty, this culture will catch up with you, and a critical mass of security issues will arise, requiring engineering resources. Sometimes, the number and/or severity of the problems is so great - that feature delivery is paused, and most of the team is focused on remediation. I bet that for every case like this in the press, many more are not public.

Too often, I have seen teams rely on the hero model: people who, early on, take the risk of spending time on security—which, in my opinion, is under-acknowledged/appreciated. Or the heroes who scramble to fix issues after they are found—typically in a severe time crunch. The hero model is not sustainable and is unreliable for ensuring secure systems. Further, the hero model is often a symptom of something "wrong."

So, let's stop relying on heroes, best intentions, hollow statements, and punishing the bearers of bad news. In a fiercely competitive world, features are prioritized, and security often gets less attention, sometimes even becoming an afterthought. This is a culture war that needs to be waged. 

We must start by considering security not just as a necessity but as a feature as important as any other. We need to talk about it early. We need to do security reviews early and often. For instance, start a threat model on the first day, keep it up to date, and assess design decisions in the context of how it would change the threat model. Activities like this involve staffing security-oriented teams and embedding them into the project teams. Then, empower them to ensure positive security-oriented outcomes. A culture of security is independent of volunteers who take on additional responsibility to ensure a secure system.  We need mechanisms to help people do the "right" thing. Then, acknowledge (early) security wins, such as actions to avoid an event.

A culture of security is hard to change, and as leaders, we need to be honest with ourselves about it — are we backing up our words in ways that will lead to the outcome we want? Look in the mirror. Yes, the words mean something, but it takes more than words.

PS: If you're unfamiliar with the African phrase "it takes a village" - see here.

Classic Tech Books I Still Have My Shelf

Relating some of the books I still have on my bookshelf. They are totally obsolete but found myself reminiscing around what they represented from my past and why they still took up space on my shelf.

One thing to know about me is that by default, I am a book collector. I once had a collection of over 200 technical books on my shelf. That was before the great purge where I donated most of the books and hung onto 30 or so. The great book purge is a story for another time. Suffice it to say that the books that survived were either timeless or ones that I had a fondness for. Here are a few of the fond ones.

The Pink Shirt Book. What would I have done without this book? If you were programming to the "IBM PC" at the time, this was a must have. I pulled it off the shelf and it flopped open the chapter on INT 21. This was the system services interrupt the keyboard, files, etc. I also found a dog-eared page for the INT 27 terminate and stay resident (TSR) details as well. TSRs were the services of the time. This was mostly assembler, then bumping up to C as soon as I could.

The Genie Book. I used this book in conjunction with the Norton Pink Shirt book. It came out after the Norton book, but had more details on writing TSRs, multitasking, and expanded memory. I pulled this book off the shelf and there is a page that was used so much that it was sticking out - having come off the binding. Now that is one well used page. When grabbing the image for this post, I found that this book was available on the Internet Archive (archive.org). E-versions of technical books is one reason I was comfortable getting rid of so many of my technical books (see future purge post).

The Microsoft C 5.0 Quick Reference Guide. This is an actual picture of my copy because I could not find a stock photo. Note the cup stains on the cover. It was a C reference, the page I used the most for C were the escape sequences for printf (e.g. \n, \r) and the language type ranges (e.g. difference between long and float). I still use this reference occasionally for the last table on ASCII codes - the decimal, hex, and character representation of 0 to 255. If you have seen The Martian, then you know.

The Intel 386 Microprocessor Hardware Reference Manual. Yikes, I am not sure why I am hanging onto this one, I have not used it since the time when I needed it. I have flipped through it a couple of time since and seen all the timing and logic diagrams and thought - we actually did this stuff. I primarily used this around interrupts (maskable vs. non-maskable) and for figuring out peripheral timings for external serial devices. We were doing some pretty hard-core stuff at the time. I recall a device we borrowed from one of the hardware manufacturers that sat in between the CPU and the socket. It allowed you to debug at the CPU level and single step through code. I remember we called it the skateboard because it resembled one but have not seen or heard of one since. Hardcore.

It's worth noting that many of the folks I worked with during this time are still friends. We were young and thought anything was possible. On top of that we had a leader who inspired us to live on the edge and accomplish amazing things.