Your brain is constantly trying to simplify the world. It takes a snapshot of what it sees, builds a picture that makes sense, and then works from that picture. Most of the time this works well enough. But when we plan projects, set goals, or try to predict where something is headed, these default modes of thinking can lead us in the wrong direction. In today's episode, I cover three of these defaults: linear thinking, static thinking, and infinite or non-discrete thinking. I also talk about how they show up in your career and in the way engineering leaders set vision for their teams.

• Static Thinking and the Snapshot Problem: We tend to fix our beliefs about people very quickly, which is why first impressions carry so much weight. If someone acts a certain way in one meeting, we assume that's how they act in every meeting. This is closely related to the fundamental attribution error, where we treat a person's behavior in one moment as a permanent part of who they are instead of a response to their environment.
• Linear Thinking and Exponential Change: When something is changing, we assume it will keep changing at about the same rate. AI agents are a good counterexample. Research suggests their effectiveness roughly doubles on a timescale of a few months, and even if the exact numbers are off, the curve is exponential. That kind of growth is hard to picture intuitively, and it probably won't last forever. At some point it will likely level off into something closer to logarithmic.
• Where Our Intuition Comes From: Nonlinear patterns are all around us in nature. Think about how quickly heat rises as you move your hand toward a fire, or how loudness changes as you get closer to a speaker. But our social lives mostly involve slow, roughly linear change, and over the course of human history our minds have adapted to that kind of linear model.
• Your Career Isn't a Straight Line: Many of us expect our salary and growth to rise steadily, in steps, for our whole careers. That expectation often breaks down, especially later on, and it makes exponential income growth hard to even imagine.
• Infinite Thinking and Missing Endpoints: We aren't naturally good at thinking in discrete stages. We rarely design our careers in phases or plan for how they end until those moments are right in front of us. Cultural habits like contributing to a retirement account do some of that planning for us almost by accident, but most areas of our lives get no such help.
• Two Traps for Engineering Leaders: When setting direction for a team or department, leaders often fall into one of two traps. The first is a "forever vision," an unbounded picture of perfection that the org is supposed to chase. The second is purely linear planning, where you only do the next thing in front of you and never step back to look further ahead.
• The Productive Middle: The most useful vision work usually happens on a timescale of months to years. That's harder than it sounds, because it calls for a concrete plan, a lot of saying no, and putting the pieces together in a discrete way that doesn't come naturally to us.
• Episode Homework: Becoming aware of these defaults is the first step. Add linear, static, and infinite thinking to your planning checklist. Next time you set a goal or a vision, ask yourself which of these defaults might be shaping your picture of reality.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

🗞️ Subscribe to The Tea Break

We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review!

Download audio: https://dts.podtrac.com/redirect.mp3/cdn.simplecast.com/audio/c44db111-b60d-436e-ab63-38c7c3402406/episodes/d8ff4482-bed7-4647-b93f-4e4b7561d67a/audio/9cd8ec85-960d-4863-ad74-f3c321035629/default_tc.mp3?aid=rss_feed&feed=dLRotFGk

Whatever happened to the future we were promised? Time for a Geek Out! To celebrate the end of the opening history bits, Richard pulls together all the most popular topics of "things we were supposed to get in the future." From flying and self-driving cars to fusion power, personal jetpacks, Star Trek replicators, space tourism, and more! While some things are coming true, in a form different from what was expected, other things continue to be very difficult - and there is no sign of when that future will come. The future is here, just not exactly the one we thought it would be!



Download audio: https://dts.podtrac.com/redirect.mp3/api.spreaker.com/download/episode/76101431/dotnetrocks_2027_the_future_we_were_promised_geek_out.mp3

Teddy Schleifer is a New York Times reporter who covers billionaires and their influence on politics. Schleifer joins Big Technology Podcast to discuss what the Democrats’ midterm sweep means for the AI buildout. Tune in to hear why voters are turning against data centers and how much a Democratic Congress can do to slow their construction with Trump still in the White House. We also cover the prospect of tech CEOs facing subpoenas, what the election means for Elon Musk, and California’s proposed billionaire tax. Hit play for an emergency episode on what happens when Silicon Valley embraces a president and voters give the other party control of Congress.

Learn more about your ad choices. Visit megaphone.fm/adchoices

Download audio: https://pdst.fm/e/tracking.swap.fm/track/t7yC0rGPUqahTF4et8YD/pscrb.fm/rss/p/traffic.megaphone.fm/AMPP1327607953.mp3

---

Dave Kerr created hacker laws, and now he finds himself reviewing agent-written code for them. Back on the show after six years, Dave names what he sees limiting teams today: keeping everyone’s mental model in sync with what’s actually been built. Adam declares it Kerr’s Law on the spot. We get into why Dave’s team treats code review as a deliberate slowdown, how Shellwright lets agents bring evidence to a pull request, and what living with bipolar disorder has taught Dave about noticing when the excitement of these tools stops being healthy.

Join the discussion

Changelog++ members save 9 minutes on this episode because they made the ads disappear. Join today!

Sponsors:

• Coder.com – Secure environments where devs and agents work in parallel. Open by design. Secure by default.
• KubeCon + CloudNativeCon – Get a generous discount by using changelogpod (think Earlybird pricing!). Learn more and register.
• WorkOS – WorkOS is building the infrastructure for the AI era. Explore three new product previews: Airlock for secure AI agent permissions, Atlas for deploying AI-built internal apps, and Passport for seamless, passwordless access to work apps. See the announcements, demos, and highlights in the WorkOS init() 2026 recap.
• Fingerprint – Detect threats, AI agents, and bots with device intelligence.

Featuring:

• Dave Kerr – Website, GitHub, X
• Adam Stacoviak – Website, GitHub, LinkedIn, Mastodon, X

Show Notes:

Kerr’s Law — A team’s ability to scale is limited by its ability to keep a shared mental model in sync with the system it builds.

• Dave Kerr’s website
• Hacker Laws
• Effective Shell
• Ark (Agents at Scale)
• Shellwright
• Tailscale
• Playwright
• asciinema
• k9s

Something missing or broken? PRs welcome!

Download audio: https://op3.dev/e/https://pscrb.fm/rss/p/https://cdn.changelog.com/uploads/podcast/689/the-changelog-689.mp3

Sooner or later you hit a setting that no DSC resource manages. A hosts file entry, a certificate with specific properties, some tweak that only exists as a PowerShell snippet on a wiki page. You know the PowerShell to fix it, but there is no resource to wrap it in.

One way is to reach for Microsoft.DSC.Transitional/RunCommandOnSet. It runs a command during the set operation, and that is all it does. There is no test, so DSC cannot tell you whether the machine is in the desired state. But it is a good fit as a temporary transitional resource while migrating DSCv3 resources.

There is another option: Microsoft.DSC.Transitional/PowerShellScript. It lets you bring your own getScript, testScript and setScript.

Note: If you are new to DSC 3.0 check out my blog series about it:

• Getting started with DSC 3.0 – Part 1: What is DSC and what changed?
• Getting started with DSC 3.0 – Part 2: Managing a Windows service end to end
• Getting started with DSC 3.0 – Part 3: Capturing the current state with dsc config export
• Getting started with DSC 3.0 – Part 4: Configuring IIS with multiple resources and dependsOn
• Getting started with DSC 3.0 – Part 5: Guarding your configuration with Assertion
• Getting started with DSC 3.0 – Part 6: Using the DSC MCP server with your AI coding tools

Why do we need this?

Every DSC resource implements the same operations: get, test and set. Most resources are written once and reused everywhere. With PowerShellScript you write those three operations yourself, inline in your configuration document.

It is a transitional resource, and the name says it all. It is a bridge between the declarative DSC model and the imperative scripts you already have. If you used the Script resource from PSDscResources in the past, the three properties will look familiar.

The three scripts

• getScript: returns the current state of the resource. It runs when you invoke dsc config get.
• testScript: returns $true when the machine is in the desired state and $false when it is not. It runs on dsc config test, and as the first step of dsc config set.
• setScript: makes the change. It only runs when testScript returned $false.

The interesting part is the relation between the last two. testScript is the gatekeeper. If you get it right, setScript only touches the machine when it has to, and running the configuration twice is harmless.

Putting it into action

Let's make sure a hosts file entry exists. Not something you would do in production, but small enough to see all three scripts at work.

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Hosts entry for dsc.local
  type: Microsoft.DSC.Transitional/PowerShellScript
  properties:
    getScript: |
      $hosts = Join-Path $env:SystemRoot 'System32\drivers\etc\hosts'
      $entry = Get-Content $hosts | Where-Object { $_ -match '^\s*127\.0\.0\.1\s+dsc\.local\s*$' }
      return @{ present = [bool]$entry }
    testScript: |
      $hosts = Join-Path $env:SystemRoot 'System32\drivers\etc\hosts'
      return [bool](Get-Content $hosts | Where-Object { $_ -match '^\s*127\.0\.0\.1\s+dsc\.local\s*$' })
    setScript: |
      $hosts = Join-Path $env:SystemRoot 'System32\drivers\etc\hosts'
      Add-Content -Path $hosts -Value '127.0.0.1 dsc.local'

Let's see the three operations in action (from an elevated shell, the hosts file is protected):

# Runs getScript only
dsc config get --file hosts.dsc.yaml

# Runs testScript only, nothing is changed
dsc config test --file hosts.dsc.yaml

# Runs testScript first, and setScript only when the test fails
dsc config set --file hosts.dsc.yaml

# Run it again: testScript now returns true and setScript is skipped
dsc config set --file hosts.dsc.yaml

The second set is the one that matters. Nothing happens, because the machine already looks the way we described. That idempotency is not something DSC gives you for free here. It is the result of a good testScript.

Remark: PowerShellScript runs in PowerShell 7. If your script depends on modules or features that only exist in Windows PowerShell, use Microsoft.DSC.Transitional/WindowsPowerShellScript. Same properties, but it runs in 5.1.

Using the output of setScript

Whatever your setScript returns ends up in the result of the resource. Use --output-format pretty-json and look at afterState.output:

$result = dsc config set --file hosts.dsc.yaml --output-format pretty-json | ConvertFrom-Json -Depth 20
$result.results.result.afterState.output

This is useful when a script creates something you need later, like the thumbprint of a certificate, and you want to hand it to the next step in your pipeline.

When not to use it

If all you need is to run something once during set, and you do not care about get or test, RunCommandOnSet is simpler.

If you find yourself copying the same three scripts into every configuration, that is the signal to build a real resource. Inline scripts are hard to test and hard to reuse. Use them as glue, not as a foundation!

More information

• Built-in DSC resources reference
• Microsoft.DSC.Transitional/PowerShellScript - PowerShell | Microsoft Learn
• Microsoft.DSC.Transitional/RunCommandOnSet - PowerShell | Microsoft Learn