Cory House (Pluralsight/DomeTrain author and principal at ReactJS Consulting) shares the story of going “all-in” on JavaScript/React and how that focus grew into a successful independent consulting and training career. We dig into the tradeoffs of deep specialization vs breadth, how to spot real opportunities, and the “two-way door” idea for tech career moves. Cory also walks through his current pivot: using AI as a developer accelerator (how teams use it, where it helps most, what to watch out for) and how experimentation today — while tooling is cheap and rapidly evolving — is valuable. Along the way we surface mindset lessons (Cal Newport, Carol Dweck), how to balance giving away content vs paid courses, and practical tips for auditors/consultants trying to scale their impact.
As AI agents become more capable, there's growing eagerness to develop long-running tasks that operate autonomously with minimal human intervention. However, my experience suggests this fully autonomous mode doesn't apply to most documentation work. Most of my doc tasks, when I engage with AI, require constant iterative decision-making, course corrections, and collaborative problem-solving—more like a winding conversation with a thought partner than a straight-line prompt-to-result process. This human-in-the-loop requirement is why AI augments rather than replaces technical writers.
Jen Abel is GM of Enterprise at State Affairs and co-founded Jellyfish, a consultancy that helps founders learn zero-to-one enterprise sales. She’s one of the smartest people I’ve ever met on learning enterprise sales, and in this follow-up to our first chat two years ago (covering the zero to $1 million ARR founder-led sales phase), we focus on the skills founders need to learn to go from $1M to $10M ARR.
We discuss:
1. Why the “mid-market” doesn’t exist
2. Why tier-one logos like Stripe and Tesla counterintuitively make the best early customers
3. The dangers of pricing your product at $10K-$20K
4. Why you need to vision-cast instead of problem-solve to win enterprise deals
5. Why services are the fastest way to get your foot in the door with enterprises
6. How to find and work with design partners
7. When to hire your first salesperson and what profile to look for
—
Brought to you by:
WorkOS—Modern identity platform for B2B SaaS, free up to 1 million MAUs
The Art of Virtual Synth Design II : Surge XT : Open Source Powerhouse !
"It's fun working on stuff that works!"
Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Paul Walker, aka BaconPaul , who is a maintainer and one of the largest contributors on the Surge Synthesizer Team, and also a contributor to several other open source audio projects, including the CLAP plugin standard
We discuss Pauls early history with music and technology , and how he found his way to joining and forming the Surge team, and his ongoing role there.
We cover the history of Surge XT, and its initial development by Claes Johanson which he sold as a commercial product via his original company Vember Audio ( Released in 2005). We discuss how the development eventuated going the open source route , and how that makes it unique regards allowing access to the source code to all developers, over more traditional closed loop development of other major synths.
We discuss how the Surge Synth Team formed, the importance of the team dynamic and tools, (both technological and sociological) , other projects in the Surge Synth Team beyond Surge XT, and the constantly expanding catalogue.
We take a deeper dive into the features and direction of Surge XT, its unique architecture and feature set, and discuss area's like MPE, CLAP, MT-ESP (Microtuning ), accessibility, etc.
We also discuss the current state of Music Technology and the incoming zeitgeist being driven by AI, and much much more.
In our previous article Microsoft Dev Box Creation using Terraform, we explored how to create Microsoft Dev Boxes using Terraform. Now, we’ll take the next step: **deploying Dev Box catalogs and synchronizing them with a GitHub repository**. This ensures that your development environments remain consistent, version-controlled, and easily maintainable across teams.
In this article, we will extend the setup by:
Deploying Dev Box Catalogs using terraform.
Synchronizing these catalogs with GitHub for version control.
Why Dev Box Catalogs?
Dev Box Catalogs enable organizations to define, manage, and share standardized development environments — tailored to specific teams or projects. A catalog acts as a blueprint, containing Dev Box definitions, base images, pre-installed tools, and necessary configurations to ensure every developer has a consistent setup.
What Makes Dev Box Catalogs Valuable?
By leveraging Dev Box Catalogs, teams can streamline how they deliver and maintain development environments. This approach ensures developers can focus on writing code instead of setting up and troubleshooting local configurations.
A Dev Box Catalog allows you to:
Define customized development environments with pre-installed tools and dependencies
Maintain consistent configurations for specific projects or teams
Use version-controlled templates to manage changes over time
Terraform installed locally or via Azure Cloud Shell.
Azure CLI installed and authenticated.
GitHub repository for catalog synchronization.
Resources from Previous Blog
You should have already created:
Resource Group
Virtual Network and Subnet
Network Connection
Dev Center
Project
Dev Box Definition
Dev Box Pool
Now we will create the below set of resources as part of this deployment:
Dev Box Catalog
Azure Key Vault
Deploy the Dev Box Catalog and Key Vault to the 'West Europe' location.
Step 1: Create a Dev Box Catalog using Terraform
# This Terraform script creates a Dev Center Catalog in Azure.
#Creating a Dev Center Catalog
resource "azurerm_dev_center_catalog" "catalogs" {
name = "devCenterCatalog"
resource_group_name = azurerm_resource_group.resourceGroup.name
dev_center_id = azurerm_dev_center.devCenter.id
catalog_adogit {
branch = "feature/devCenterCatalog"
path = "/catalog"
uri = "https://github.com/devCenter-org/devCenter-catalog"
key_vault_key_url = "https://${azurerm_key_vault.this.name}.vault.azure.net/secrets/Pat"
}
}
**Explanation of Parameters: ** - `name`: Name of the catalog - `resource_group_name`: Name of the Resource group - `dev_center_id`: ID of the Dev Center resource - `uri`: URL of your GitHub repository - `branch`: Branch to sync (e.g., `main`) - `path`: Directory inside catalog - `key_vault_key_url`: Secure token for GitHub authentication
Step 2: Create Key vault and secure Your GitHub Token
Log in
