DEV Community: Ian Carlson

No Red Pills, Just Hygiene – A Dating Guide for Single Male Engineers

Ian Carlson — Sun, 28 Dec 2025 20:11:32 +0000

I never thought I'd be writing about this topic, yet here we are. I feel like this issue has become so endemic to young male culture that the obvious must be clearly stated.

These tips are solely for young single men who are frustrated with dating women. I'm not an expert. This isn't professional advice. I'm a white, male, married engineer who dated for many years, and I have known many engineers who struggle with this issue. I feel like I have some practical advice to give that doesn't involve Andrew Tate or Red Pill culture.

The Engineering Approach to Dating

The crux of the problem is that many single men do not put in the required effort to attract a woman (or any person, for that matter). Some of it is laziness—we've all been there. Some of it is genetics. Some of it is circumstance. Generally, you don't have control over all those things, so you have to let them go and focus on things that truly serve your long-term goals. Only you can truly decide what those are and start moving in that direction.

In a way, you can address the courtship problem with an engineering mind. Dating is a system. To get the desired outputs, you need to determine the correct inputs. This is traditionally done through trial and error. However, it seems like instead of experimentation, men are giving up entirely. Sometimes it's conscious, sometimes not.

Regardless, there are some basic things you can try, which will probably also make you a happier person:

Hygiene – Bro, brush your teeth, use mouthwash, shower regularly, use soap. It's not that hard.

Get a good-paying job – Harder, but doable.

Sleep as best as you can – Even harder, but doable.

Exercise – At least 3 times a week at a gym or studio with other people.

Eat well.

Get some decent clothes and shoes. Shoes are important.

Do activities that involve women – This is a pretty big topic. Weirdly, I don't think the gym is great for meeting women, especially if they're working out by themselves with headphones on. However, if it's a group fitness class, that's usually a better bet. (It is still important to stay healthy, so a gym with no babes is still worthwhile). Salsa or swing classes are usually pretty good. Yoga classes as well. Try in-person speed dating if possible.

Cut back on "Bro/Video game" time – You may need to reduce this. It's ok; it's not the end of the world. Balance is good.

Make some friends who are women – Age doesn't matter. Just don't be too weird.

Get a dog or cat – But actually take care of it.

You don't need to do all of these things, but I would say most of them are pretty important. They all require effort. I know, it's tough. I'm partially saying this in jest, but I also believe it. You don't have to be a pickup artist or a model to go on dates. I'm not a swinger, just a married man who dated in the past and sees many men struggling.

Reading the Signals

Also, remember: it's not rude to ask someone out for coffee if you're already having a good chat and she is showing signs of interest. Let's go into some basic signs of interest from her, shall we?

She is contributing to the conversation.

She appears to be happy in your presence.

She is touching any part of your body.

I know this sounds ridiculously obvious to some people, but you'd be surprised how clueless some men can be. I was at one time. If she's not demonstrating any of those things, then you should probably end the conversation respectfully, or just treat them like any other respectful person. No harm, no foul, no biggie.

In the post-Me Too era, many men may think that any show of interest is bad. Quite the contrary. It's ok to show interest. Just do it respectfully.

New AWS Lambda Durable Functions – Do they replace Step Functions?

Ian Carlson — Sun, 14 Dec 2025 16:06:37 +0000

The serverless landscape just shifted beneath our feet. With the release of AWS Lambda durable functions this December 2025, Amazon has introduced a new feature that developers have been asking for since the dawn of FaaS (function as a service).

In short, durable functions allow you to write stateful, long-running workflows entirely within your lambda code using familiar await syntax. You can pause execution for days, weeks, or even up to a year without paying for idle compute, and pick right back up where you left off with local state intact.

Currently available exclusively in the us-east-2 (Ohio) region, this feature is slated for a wider global rollout in Q2 of 2026. But even with its limited availability, it poses a big question for cloud architects: With the ability to handle retries, waits, and complex state management directly in code, is the reign of AWS Step Functions over?

This article breaks down the new functional overlap, the distinct differences in developer ergonomics and pricing, and where each tool belongs in your 2026 serverless stack.

A Quick History Lesson

To understand why this update is such a big deal, we have to look at history. AWS Lambda and AWS Step Functions have been staples of serverless architectures for years. Lambda provided the raw compute, and Step Functions provided the orchestration and low-code interface.

Step Functions was originally introduced to solve a specific pain point: the infamous "Lambda calling Lambda" anti-pattern. Chaining functions together manually in code was brittle, hard to debug, and surprisingly expensive. Step Functions offered a robust, managed alternative designed to handle long-running, multi-step, transactional workloads. It took the burden of state tracking, error handling, and retry logic out of your code and into a managed service platform.

For years, the separation of responsibilies was clear. If you needed business logic, you wrote a Lambda. If you needed to coordinate that logic with a low-code interface, you built a Step Function state machine. This approach was particularly empowering for non-programmers or operations teams because Step Functions uses a configuration-based workflow (ASL - Amazon States Language) paired with an excellent visual editor. It allows you to drag-and-drop hundreds of zero-code integrations—connecting S3 events to DynamoDB puts to SQS queues—without writing a single line of Python or Node.js.

The Friction of State Machines

However, Step Functions hasn't been perfect. For a long time, it was strictly stateless between steps, meaning you had to pass-through large JSON payloads from one state to the next just to keep track of context.

Furthermore, the "configuration-first" nature of Step Functions created a barrier for pure software engineering workflows. You cannot easily execute a complex Step Function on your laptop. Debugging often involves deploying to the cloud, running an execution, checking the console logs, tweaking the ASL JSON, and redeploying. It works, but the feedback loop is painfully slow compared to local unit testing.

Where They Now Overlap

Functionally, Lambda Durable Functions and Step Functions now occupy the same neighborhood. If you look at their capabilities on paper, the lines are blurry. Both services now offer:

Zero Cost for Waiting: Both services allow you to pause execution for up to a year without paying for idle compute time.
Built-in Resilience: Both have robust mechanisms to catch errors with exponential backoff and retry failed steps or sub-routines automatically.
State Persistence: Both "remember" exactly where they left off after a sleep period or an unexpected crash, ensuring workflows complete reliably.

If both tools can wait for a month and retry a failed API call, how do you choose?

The Great Divide: Code vs. Config

The real difference lies in ergonomics and the development lifecycle.

AWS Lambda Durable Functions is unapologetically code-first. It brings workflow orchestration inside the function. You use standard programming constructs—if statements, for loops, and try/catch blocks—to manage your flow. If you want to wait for a week, you don't drag a "Wait State" box onto a canvas; you simply write await context.wait({ seconds: 30 }) in your code.

This unlocks the holy grail of serverless development: Local Debugging. Because it is just code, you can use standard unit testing frameworks (like Jest or Pytest), mock the durable steps, and step through your entire orchestration logic with breakpoints locally on your machine before ever touching the cloud. You can share libraries, use distinct variable scoping, and manage complexity using standard software engineering patterns. You can also perform full integration testing from your laptop – by generating temporary keys from the AWS console, you can securely interact with cloud services over authenticated and encrypted connections to AWS services.

AWS Step Functions remains configuration-first. Where it shines is in Visual Observability. When a complex business process fails at 3 AM, an on-call engineer (who may not be a coder) can look at the Step Functions graph in the AWS Console, see exactly which green box turned red, inspect the input and output data at that exact moment, and understand the failure.

It also excels at Integration. If your workflow is mostly "gluing" AWS services together—e.g., Take file from S3 -> Transcribe it -> Save results to DynamoDB -> Email user via SES—Step Functions lets you do this with essentially zero code. Doing the same in Durable Functions would require importing the AWS SDK for four different services and writing boilerplate code for every single step.

The Pricing Equation

Finally, let's talk about the wallet, because the billing models are fundamentally different.

Step Functions (Standard Workflows): You are billed based on State Transitions. Roughly $25 per million transitions.
Lambda Durable Functions: You are billed based on Requests + Compute Duration. You pay for the time your code is actually executing on the CPU.

Let's look at a basic example: A workflow that loops 10,000 times to process small items.

In Step Functions: You pay for every single step in that loop. A loop with just 3 states (Task, Choice, Wait) running 10,000 times equals 30,000 state transitions. That bill can climb surprisingly fast for high-throughput looping.
In Lambda Durable Functions: You pay for the aggregate compute time it takes to run the loop's logic. Since modern Lambda runtimes pause and resume incredibly efficiently, iterating through a loop in memory with short bursts of CPU activity is virtually free compared to the cost of 30,000 discrete state transitions.

Conversely, for a workflow that consists solely of "Wait 6 months, then send one email," Step Functions is incredibly cheap (only a few transitions), while Durable Functions is also cheap (zero compute during wait), but involves slightly more overhead for management.

Conclusion

So, does AWS Lambda Durable Functions replace Step Functions?

If you are a developer: Yes, mostly.
If you live in your IDE and value unit testing, fast local debugging cycles, and managing complex logic through code constructs rather than JSON configuration, Durable Functions is the tool you have been waiting for. It removes the context-switching tax of managing ASL files and lets you build complex, durable backends using the languages you already love.

If you are an architect or ops-focused: No.
Step Functions remains the king of high-level infrastructure orchestration. Its superior visual observability, hundreds of zero-code integrations, and ability to be easily audited by non-technical stakeholders make it indispensable for "macro" workflows that tie together disparate AWS services.

The sheer number of AWS services can be overwhelming, but a lot of that is just due to how software naturally evolves and the need to keep old things working—which businesses definitely appreciate. But for me personally, I'll be choosing Durable Functions over Step Functions in most cases going forward because I'm a developer first.

Mastering AWS CDK Dependencies: How to Avoid the "Stuck Stack" Deadlock

Ian Carlson — Sat, 06 Dec 2025 16:59:42 +0000

Mastering AWS CDK Dependencies: How to Avoid the "Stuck Stack" Deadlock

As applications built with the AWS Cloud Development Kit (CDK) grow in complexity, developers often encounter a specific, frustrating architectural hurdle: the CloudFormation export deadlock.

It usually begins innocently. You might have a DatabaseStack and an ApiStack. To allow the API to access the database, you pass the DynamoDB table object from one stack to the other. Behind the scenes, CDK creates a CloudFormation export/import relationship.

Months later, when you attempt to rename a resource or refactor the DatabaseStack, the deployment fails with a blocking error:

Export Output:MyTableExport is in use by stack ApiStack

You are now in a dependency deadlock. You cannot update the producer (Database) because the consumer (API) is referencing the export. Conversely, you cannot update the consumer to stop using the export because the deployment process relies on the valid state of the producer.

There are robust architectural patterns to prevent this (Consolidation and Runtime Decoupling), but first, we must address the immediate operational issue: How do you resolve an active deadlock?

Immediate Remediation: Breaking the Deadlock

If you are currently facing this error, standard deployments will not work because CloudFormation enforces strict referential integrity. You must manually break the dependency chain using a multi-step deployment process.

Step 1: Sever the Dependency (The "Detach" Deploy)

Modify your Consumer Stack (e.g., ApiStack) to stop referencing the Producer Stack's output.

The Code Change: Temporarily hard-code the value you were previously importing. For example, replace the imported Table Object with a string literal: const tableName = "my-actual-table-name".
The Deploy: Deploy only the Consumer Stack (cdk deploy ApiStack).
The Result: CloudFormation updates the API stack. It removes the Import reference, freeing the Export.

Step 2: Update the Producer

With the export no longer "in use," you are free to modify the Producer Stack.

The Code Change: Apply your intended refactor, rename, or deletion in the DatabaseStack.
The Deploy: Deploy the Producer Stack (cdk deploy DatabaseStack).
The Result: The deployment succeeds.

Step 3: Re-bind the Resources

Now that the infrastructure is in a clean state, you can restore the connection using one of the sustainable strategies outlined below.

Strategy 1: The Simplest Solution (Stack Consolidation)

Before implementing complex decoupling patterns, it is worth evaluating whether multiple stacks are necessary for your use case.

Historically, developers split applications into NetworkStack, DatabaseStack, and ApiStack to avoid hitting the CloudFormation limit of 200 resources per stack. AWS has since increased this limit to 500 resources. Consequently, most medium-sized applications can comfortably fit within a single stack context.

The Case for Consolidation

When resources exist in the same stack, CloudFormation manages dependencies internally using Direct References rather than Export/Imports.

Eliminates Deadlocks: CloudFormation automatically determines the correct order of operations for updates and replacements.
Atomic Deployments: The entire application either deploys successfully or rolls back completely, preventing inconsistent states.
Simplified Code: There is no need to pass properties between stack classes or manage complex interface contracts.

For single teams managing individual services, consolidation is often the most pragmatic approach.

Strategy 2: The Scalable Solution (Runtime Decoupling)

If organizational boundaries or lifecycle differences (e.g., stateful vs. stateless resources) require you to maintain multiple stacks, you must decouple them to avoid future deadlocks.

To do this, we shift from Deploy-time dependencies (hard CloudFormation Exports) to Runtime dependencies.

Stack A writes a configuration value (e.g., a Table Name) to a specialized store, such as AWS Systems Manager (SSM) Parameter Store.
Stack B provides its Lambda function with the key to that parameter.
The Lambda fetches the value at runtime.

In this model, the stacks are unaware of each other's existence; they share only a contract regarding the parameter key.

Implementation: The SSM Parameter Store Pattern

Step 1: The Contract (Shared Configuration)

Define the parameter name in a shared constant file. This ensures both the producer and consumer reference the exact same location in the Parameter Store.

// lib/config.ts
export const TABLE_PARAM_KEY = '/my-app/prod/dynamodb-table-name';

Step 2: The Producer (Database Stack)

Create the resource and publish its identifier to SSM.

// lib/database-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as ssm from 'aws-cdk-lib/aws-ssm';
import { TABLE_PARAM_KEY } from './config';

export class DatabaseStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 1. Create the resource
    const table = new dynamodb.Table(this, 'MyTable', {
      partitionKey: { name: 'pk', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
    });

    // 2. Publish the value to Parameter Store
    new ssm.StringParameter(this, 'TableNameParam', {
      parameterName: TABLE_PARAM_KEY,
      stringValue: table.tableName,
    });
  }
}

Step 3: The Consumer (API Stack)

The API stack does not import the DatabaseStack. It simply passes the parameter key to the Lambda environment and grants the necessary read permissions.

// lib/api-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as ssm from 'aws-cdk-lib/aws-ssm';
import { TABLE_PARAM_KEY } from './config';

export class ApiStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 1. Create the Lambda Function
    const apiHandler = new lambda.Function(this, 'ApiHandler', {
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'index.handler',
      environment: {
        // Pass the KEY, not the value
        TABLE_CONFIG_KEY: TABLE_PARAM_KEY, 
      },
    });

    // 2. Grant Permissions
    // Construct a reference to the parameter to grant specific access
    const param = ssm.StringParameter.fromStringParameterName(
      this, 
      'TableParamRef', 
      TABLE_PARAM_KEY
    );

    param.grantRead(apiHandler);
  }
}

Step 4: Runtime Logic with Caching

Fetching parameters from SSM involves an API call, which introduces latency and cost. To optimize this, we utilize the Lambda Execution Context to cache the value. Variables defined outside the handler persist between invocations as long as the execution environment remains active ("warm").

// lambda/index.mjs
import { SSMClient, GetParameterCommand } from "@aws-sdk/client-ssm";
import { DynamoDBClient, PutItemCommand } from "@aws-sdk/client-dynamodb";

const ssmClient = new SSMClient();
const dynamoClient = new DynamoDBClient();

// GLOBAL CACHE
// These variables persist across warm invocations
let cachedTableName = null;
let cacheTimestamp = 0;
const CACHE_TTL_MS = 60 * 1000 * 5; // Cache for 5 minutes

const getTableName = async () => {
  const now = Date.now();

  // 1. Check if cache is valid
  if (cachedTableName && (now - cacheTimestamp < CACHE_TTL_MS)) {
    console.log("Using cached table name");
    return cachedTableName;
  }

  // 2. If not, fetch from SSM
  console.log("Cache expired or empty. Fetching from SSM...");
  const command = new GetParameterCommand({
    Name: process.env.TABLE_CONFIG_KEY 
  });

  const response = await ssmClient.send(command);

  // 3. Update Cache
  cachedTableName = response.Parameter.Value;
  cacheTimestamp = now;

  return cachedTableName;
};

export const handler = async (event) => {
  try {
    const tableName = await getTableName();

    const command = new PutItemCommand({
      TableName: tableName,
      Item: {
        pk: { S: "user_123" },
        data: { S: "some data" }
      }
    });

    await dynamoClient.send(command);
    return { statusCode: 200, body: `Written to ${tableName}` };

  } catch (error) {
    console.error(error);
    return { statusCode: 500, body: "Error" };
  }
};

Beyond Parameter Store: Advanced Decoupling

While SSM is the standard solution, specific requirements may dictate alternative stores.

1. Sensitive Data: AWS Secrets Manager

If the shared value is sensitive (e.g., database credentials, API keys), do not use SSM Parameter Store. AWS Secrets Manager is the appropriate tool. The implementation pattern remains identical: the Producer writes the secret, and the Consumer fetches it at runtime using the SDK, ensuring data remains encrypted and rotatable.

2. Service Discovery: AWS Cloud Map

For more complex, dynamic architectures, AWS Cloud Map offers a robust alternative to SSM. It allows you to register abstract resources (like S3 buckets or Event Buses) as "services" with custom attributes.

Why Cloud Map?

Logical Naming: Resolve my-app/user-service to dynamic endpoints.
Health Checks: Unlike SSM, Cloud Map can verify a resource's health before returning its address.
Metadata: Attach rich metadata (version, region, protocol) to the resource registration.

Conclusion

Dependency deadlocks in CloudFormation are a common rite of passage for CDK engineers, but they are not inevitable.

If your architecture allows, Strategy 1 (Consolidation) is the most efficient path, resolving dependencies natively within the CloudFormation engine. For distributed systems requiring modularity, Strategy 2 (Runtime Decoupling) provides the flexibility needed to evolve stacks independently without fear of "locking" your infrastructure.