DEV Community: Christopher

Your Code Isn’t the Bottleneck. Other People’s Approval Is.

Christopher — Fri, 16 Jan 2026 17:09:05 +0000

Read the full blog for free here: https://strategystack.io/blog/redtape

Most engineers think job security is about writing clean code, shipping fast, and being “good at communication.”

That’s the fair version of the world.

A lot of teams don’t run on fairness. They run on approvals.

The Hidden System Nobody Warns You About

On some teams, work isn’t done when the code is done.

It’s done when the right people have signed off:
product, business, QA, and usually one or two senior engineers whose opinion quietly decides whether your work is “acceptable.”

If you don’t treat that like a real dependency, you’ll learn the hard way.

Because the org won’t grade your effort. It’ll grade whether the feature was accepted on time.

“I Sent Them a Message” Doesn’t Protect You

This is where good engineers get hurt.

They finish the work.
They ask for review once.
No one responds.
Sprint ends.
Someone says, “Why wasn’t this approved?”

Now it looks like you didn’t deliver.

Even if you did everything “right” technically, you still missed the invisible gate.

In environments like this, you don’t just notify people. You drive the approval to completion.

Document Everything That Can Blow Back Later

If the team has high turnover, it usually has high ambiguity too.

And ambiguity is a weapon. Not always on purpose, but it becomes one.

So document:
what you understood, what you asked, what was confirmed, and who was responsible for sign-off.

Not for drama. For clarity.

When requirements change late, written context is leverage.

Don’t Start Coding Until the Ticket Is Real

A vague ticket is not a green light. It’s risk.

If you start building before you understand what “done” means, you’re volunteering for rework.

Ask questions early.
Confirm expectations early.
Get someone to define success early.

Early clarification makes you look sharp.
Late clarification makes you look behind.

Align With the People Who Can Block You

Every team has a few people who function as gatekeepers, even if their title doesn’t say it.

If you’re not aligned with them, your PR will stall or your approach will get challenged at the worst possible time.

A quick alignment chat early can save days of back-and-forth later.

Use What Already Works

If there’s an existing pattern in the codebase, copy it.

It’s faster.
It’s safer.
It’s easier to review.

Novelty is expensive. Consistency ships.

Use AI and Meeting Artifacts to Reduce Waiting

In big companies, people are constantly unavailable.

If you’re blocked, don’t just sit there refreshing Slack.

Use AI to pressure-test your understanding, generate options, and draft crisp questions.

Also mine meeting notes and recordings. Decisions get made verbally all the time and never make it into the ticket.

The engineers who move fastest aren’t always the smartest.

They’re the ones who build context without needing permission.

How To Avoid Looking Stupid At the End Of a Sprint

Christopher — Fri, 16 Jan 2026 17:07:27 +0000

Read the full article here: https://strategystack.io/blog/question-everything

If you don’t understand the outcome, the tech questions are noise. Most delivery problems start in meetings, not in code.

One of the hardest parts of a new story isn’t the implementation.
It’s the meeting where someone asks, “Any questions?” and you’re still trying to understand what the ticket even is.

You’re mapping the domain.
You’re decoding stakeholder language.
You’re trying to understand intent, scope, and constraints at the same time.

And now you’re supposed to ask “good questions.”

Most engineers default to technical questions:

What framework are we using?
Is this a new table or an update?
Is this synchronous or async?
Those aren’t bad questions. They’re just early. If you don’t understand the outcome, the rest is guesswork.

When you’re working with non-technical stakeholders, requirements are written in outcome language, policy language, or compliance language. Not engineering language. If you start at the tech layer, you’re building on fog.

The first question should always be:

“What should be true when this is done?”

Not how.
Not with what.
Not in which service.

Outcome first. Everything else follows.

Most delivery drag doesn’t come from bad code. It comes from misunderstood intent.

And here’s the uncomfortable truth…

Most engineers aren’t bad at coding. They’re bad at clarifying.

They try to listen, think, and write at the same time.

They miss context.
They miss nuance.
Their notes are useless later.
That’s not a skill problem. It’s a tooling problem.

This is where AI is real leverage.

Record the meeting.
Get the transcript.
Let AI structure the chaos.

Now you can extract intent, identify ambiguity, and come back with precise questions. Not guesses.

Domain understanding beats syntax every time.

The engineers who move fastest aren’t the ones who type the quickest.
They’re the ones who clarify the best.

That’s what quality software engineering looks like.

How To Train Predictable AI Agents using XML+JSON

Christopher — Fri, 15 Aug 2025 11:13:56 +0000

Prompting Predictable AI Agents: A Complete Guide

Instructions given to your agent greatly affects the consistency of its output. Once your agent receives suitable instructions, outputs are much more predictable and structured, resulting in less bugs and embarrassing mistakes.

Instruction File Formats

XML:

Preferred format for training models due to less complexity for the system training on it
Better for hierarchical instructions and complex nested structures
More readable for humans when dealing with multi-layered prompts
Natural way to separate different instruction components

JSON:

Best for creating multiple outputs from a single execution of an AI agent
More flexible with working on software contributions
Easier to parse programmatically in most programming languages
Better for structured data exchange between systems

How to Choose XML vs JSON

Choose XML when:

You need clear separation of instruction sections
Working with complex, nested prompt structures
Human readability is a priority
Building templates that will be reused frequently
Creating prompts with multiple conditional branches

Choose JSON when:

Building API integrations
Need to programmatically generate or modify prompts
Working with structured data inputs/outputs
Building systems that need to parse responses automatically
Creating dynamic prompts based on user input

Creating the Prompt

1. Define the Role

The role sets the context and expertise level for your AI agent. A well-defined role helps the AI understand what perspective to take and what knowledge to draw from.

Key principles for defining roles:

Be specific about the expertise level (junior, senior, expert)
Include relevant background context
Specify the industry or domain if applicable
Define the relationship to the user (assistant, advisor, reviewer, etc.)

Examples of good role definitions:

"You are a senior software engineer with 10 years of experience in Python and web development"
"You are a helpful customer service representative for a SaaS company"
"You are an expert data analyst specializing in e-commerce metrics"

2. Define the Goal

The goal clarifies what you want the AI to accomplish. It should be specific, measurable, and aligned with your desired outcome.

Components of a good goal:

Clear objective statement
Expected deliverable format
Success criteria
Any constraints or limitations

3. Write Instructions

Instructions are the core of your prompt. They should be detailed, unambiguous, and actionable.

How to Write Effective Instructions

Be Specific and Detailed

Vague instructions lead to unpredictable outputs. Instead of "analyze this data," specify exactly what analysis you want, what metrics to focus on, and how to present the results.

Use Clear Structure

Break complex instructions into numbered steps or bullet points. This helps the AI follow a logical sequence and reduces the chance of missing important details.

Define Output Format

Specify exactly how you want the response formatted. Include details about:

Length requirements
Structure (headings, lists, paragraphs)
Tone and style
Any specific terminology to use or avoid

Include Constraints

Be explicit about what the AI should NOT do:

Information it shouldn't include
Approaches to avoid
Length limitations
Sensitive topics to handle carefully

Provide Context

Give the AI enough background information to understand the situation, but avoid information overload that might confuse the core task.

How to Provide Examples

Examples are one of the most powerful tools for ensuring consistent AI behavior. They show rather than tell the AI what you want.

Types of Examples to Include:

Input-Output Examples: Show the AI exactly what kind of input it will receive and what output you expect.

Format Examples: Demonstrate the exact structure, tone, and style you want in responses.

Edge Case Examples: Show how to handle unusual or problematic inputs.

Negative Examples: Include examples of what NOT to do, which can be as valuable as positive examples.

Best Practices for Examples:

Include 2-3 examples minimum for consistency
Make examples diverse to cover different scenarios
Keep examples concise but comprehensive
Update examples based on real-world performance

How to Write Good Prompts

The CLEAR Framework:

Context: Provide necessary background information
Length: Specify desired response length
Examples: Include relevant examples
Audience: Define who the response is for
Role: Clearly define the AI's role and expertise

Additional Best Practices:

Test your prompts with various inputs
Iterate based on actual performance
Keep prompts as concise as possible while maintaining clarity
Use consistent terminology throughout
Version control your prompts for tracking improvements

Examples of Good and Bad Prompts

Example 1: Content Creation

❌ Bad Prompt:

<prompt>
Write about dogs.
</prompt>

✅ Good Prompt:

<prompt>
<role>You are an expert pet care writer with 5 years of experience creating educational content for dog owners.</role>

<goal>Create an informative blog post about dog training basics that will help new dog owners establish good behaviors in their pets.</goal>

<instructions>
1. Write a 800-1000 word blog post about basic dog training
2. Include practical, actionable advice
3. Structure with clear headings and subheadings
4. Use a friendly, encouraging tone
5. Include 3-4 specific training techniques
6. End with a brief summary of key points
7. Avoid mentioning specific dog breeds unless necessary for context
</instructions>

<examples>
Good section example:
"## Positive Reinforcement Training
Positive reinforcement is the foundation of effective dog training. When your dog performs a desired behavior, immediately reward them with treats, praise, or play. This creates a positive association..."

Bad section example:
"Dogs are bad when they don't listen. You should punish them when they're bad."
</examples>

<output_format>
- Use markdown formatting
- Include H2 headings for main sections
- Write in second person (addressing the dog owner directly)
- Include actionable bullet points where appropriate
</output_format>
</prompt>

Example 2: Data Analysis

❌ Bad Prompt:

<prompt>
Look at this sales data and tell me what's happening.
</prompt>

✅ Good Prompt:

<prompt>
<role>You are a senior business analyst specializing in e-commerce sales performance with expertise in identifying trends and providing actionable insights.</role>

<goal>Analyze the provided quarterly sales data to identify key trends, opportunities, and areas of concern that require management attention.</goal>

<instructions>
1. Review the sales data for Q1-Q3 2024
2. Identify the top 3 positive trends and top 3 areas of concern
3. Calculate month-over-month and quarter-over-quarter growth rates
4. Compare performance against industry benchmarks (if available)
5. Provide specific, actionable recommendations for Q4
6. Focus on metrics that directly impact revenue and profitability
7. Do not speculate beyond what the data supports
</instructions>

<data_context>
The data includes: monthly revenue, number of transactions, average order value, customer acquisition cost, and return rate across three product categories (electronics, clothing, home goods).
</data_context>

<output_format>
## Executive Summary
[2-3 sentence overview]

## Key Findings
### Positive Trends
[Numbered list with specific data points]

### Areas of Concern  
[Numbered list with specific data points]

## Recommendations
[Actionable steps with expected impact]

## Supporting Data
[Relevant calculations and metrics]
</output_format>

<examples>
Good finding example:
"Electronics revenue increased 23% QoQ driven by a 15% increase in average order value ($127 to $146) while maintaining stable conversion rates at 3.2%."

Bad finding example:
"Sales went up which is good for business."
</examples>
</prompt>

Example 3: Code Review

❌ Bad Prompt:

<prompt>
Review this code and make it better.
</prompt>

✅ Good Prompt:

<prompt>
<role>You are a senior software engineer with expertise in Python, code quality, and best practices. You conduct thorough code reviews focusing on functionality, maintainability, and security.</role>

<goal>Provide a comprehensive code review that identifies issues, suggests improvements, and ensures the code meets professional standards.</goal>

<instructions>
1. Review the provided Python function for correctness and efficiency
2. Check for potential security vulnerabilities
3. Evaluate code readability and maintainability
4. Suggest specific improvements with code examples
5. Identify any missing error handling
6. Comment on naming conventions and documentation
7. Rate the overall code quality on a scale of 1-10 with justification
8. Prioritize suggestions by impact (high, medium, low)
</instructions>

<review_criteria>
- Functionality: Does the code work as intended?
- Security: Are there any security risks?
- Performance: Can efficiency be improved?
- Maintainability: Is the code easy to read and modify?
- Standards: Does it follow Python best practices?
</review_criteria>

<output_format>
## Summary
[Overall assessment and quality score]

## Critical Issues (Fix Immediately)
[High priority items with code examples]

## Improvements (Recommended)
[Medium priority suggestions]

## Minor Enhancements (Optional)
[Low priority, nice-to-have changes]

## Revised Code
[Improved version of the original code]
</output_format>

<examples>
Good feedback example:
"**Security Issue**: Line 23 uses string concatenation for SQL queries, creating a SQL injection vulnerability. Replace with parameterized queries:cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

Conclusion

Creating predictable AI agents requires thoughtful prompt engineering. By defining clear roles, specific goals, and detailed instructions, you can significantly improve the consistency and quality of AI outputs. Remember to iterate on your prompts based on real-world performance and always include relevant examples to guide the AI's behavior.

The key to success is being explicit about your expectations while providing enough context for the AI to understand the task fully. With practice, you'll develop an intuition for crafting prompts that produce reliable, high-quality results.

Website: https://whoschris.dev
LinkedIn: https://www.linkedin.com/in/christopher-clemmons/

How I Built a Real-Time IoT Alert System with DynamoDB and Lambda In 4 Days

Christopher — Thu, 31 Jul 2025 22:36:42 +0000

Over the week, I built a new project for my portfolio. The purpose of this project is to demonstrate my opinionated approach to developing a cost-optimized, autoscaling and compliant alert monitoring system in the cloud.

Why a Cold Chain Monitoring Platform?

Simply, it's a system that monitors temperature sensors from warehouses and commercial vehicles, sends alerts and maintains records for compliance.

Pharmaceutical manufactures loose a lot of money by not being able to stay compliant and losses due to discarding merchandise that were exposes to unsafe temperatures. Temperature excursions can make medication and other chemical products ineffective or even dangerous.

It's serious.

This means that if someone isn't tracking the temperature of your medication, you can end up getting a bad batch that may cause a negative reaction when you take it.

This sounds like a real problem worth solving.

Defining the MVP

Breaking this down molecularly allowed me to focus only on the core features. By defining the functional and non-functional requirements ahead of time prevented me from building things I don't need.

Functional Requirements

Users can sign up and authenticate using AWS Cognito
IoT devices send temperature and humidity readings to AWS IoT Core
Lambda functions process sensor data and store it in DynamoDB
Users can query the latest 50 sensor readings via a secured API Gateway endpoint
Alerts are triggered and published to an SNS topic when temperature excursions occur
Admin users can view excursion counts and individual device status on a dashboard
An email notification is sent when an excursion is detected

Non-Functional Requirements

System must support at least 5,000 devices concurrently
APIs should respond in under 500ms under normal load
All services must be deployed using Infrastructure as Code (Terraform)
The application must enforce JWT-based authentication for all API endpoints
System must auto-scale based on demand using AWS Lambda concurrency
All data must be encrypted in transit and at rest
System uptime should meet 99.9% availability
Audit logs must be retained for a minimum of 90 days
Dashboard should be mobile-responsive and accessible

Project structure

cold-chain-platform/
├── terraform/
│   ├── modules/
│   │   ├── iot-core/
│   │   ├── lambda-function/
│   │   ├── dynamodb/
│   │   ├── sns/
│   │   ├── eventbridge/
│   │   └── s3-archive/
│   ├── environments/
│   │   ├── dev/
│   │   │   ├── main.tf
│   │   │   ├── variables.tf
│   │   │   ├── terraform.tfvars
│   │   │   └── backend.tf
│   │   └── prod/
│   └── versions.tf
├── lambdas/
│   ├── simulate_sensor/
│   │   ├── index.js
│   │   └── function.zip
 ├── other functions.../
│   │   ├── index.js
│   │   └── function.zip
├── docs/
│   ├── architecture.png
│   ├── api-spec.yaml
│   └── compliance.md
├── .gitignore
├── README.md
└── LICENSE

Client-Layer / Frontend:
AWS Amplify (Using React.js + Typescript) for rapid development and deployment of a UI for the monitoring dashboard. Amazon Cognito handles the authentication. The routes on the API Gateway have jwt authorizers that will only allow admins from the application's user pool to sign in.

Business Logic / Backend:
Lambda and IoT core processes and retrieves data from sensor. EventBridge is used as a broker to handle the notification events to SNS. In the project, I created an extra Lambda function to simulate temperature excursion events instead of wasting my money buying thousands of thermometers.

Data Layer / Database:
I went with DynamoDB because I needed something that could scale easily without having to worry about server management or performance bottlenecks. Since the system is event-driven and real-time, low-latency access was a must.

DynamoDB also gives me the flexibility to evolve the data model as needed without dealing with rigid schemas or painful migrations. It integrates seamlessly with other AWS services I’m using, like Lambda and SNS, and features like TTL and Streams made it a no-brainer for handling time-based data and triggering actions based on updates.

Security first

Each Lambda has its own IAM policies and strict permissions giving it the least amount of privileges possible. Combining AWS amplify with the other resources in this diagram ensures that data is encrypted in transit and at rest.

Below is a sample of an IAM policy in Terraform attached to a Lambda function only allowing database limited actions to DynamoDB.

resource "aws_iam_policy" "dynamodb_access" {
  name = "${var.function_name}-ddb-access"     # Name of the custom policy

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect   = "Allow",
          Action = [
          "dynamodb:PutItem",   # for process-reading
          "dynamodb:Scan",      # for get_process_reading_records
          "dynamodb:GetItem"    # optional, for more flexibility
        ],# Only allow inserting data
        Resource = var.dynamodb_table_arn      # Target DynamoDB table
      }
    ]
  })
}

SNS Notifications

I set a dummy temperature threshold to trigger email alerts using EventBridge. The Lambda function uses an IF/ELSE statement to determine if an email should be sent or not.

Challenges

Lambda timeouts: I was able to resolve the issue by simply increasing the timeout value. I tested this with 5,000 which is a moderate testing size for a demo.

  const simulations = Array.from({ length: 5000 }, (_, i) => {
    const temp = +(Math.random() * 10).toFixed(2); // Random temp between 0–10°C
    return {
      deviceId: `sensor-${i + 1}`,
      timestamp: now,
      temperature: temp,
      humidity: +(30 + Math.random() * 30).toFixed(2), // Humidity between 30–60%
      battery: +(50 + Math.random() * 50).toFixed(2),  // Battery 50–100%
      status: temp > 8 ? "ALERT" : "OK",               // If temp > 8°C → mark as alert
      type: "TEMPERATURE_READING",
      location: {
        facility: "Pfizer DC - Detroit",
        zone: `Zone-${(i % 10) + 1}`,
        gps: {
          lat: +(42.3 + Math.random() * 0.1).toFixed(6),  // Simulate Detroit lat
          lon: +(-83.0 - Math.random() * 0.1).toFixed(6), // Simulate Detroit lon
        },
      },
    };
  });

Another mistake that wasn't obvious is when I received a 500 Server Error with no explanation anywhere. I created a log group in CloudWatch that captured each AWS resource that's involved in the sensor reading lifecycle. I was able to see that the error was cause by me not stringifying the Lambda response from DynamoDB

exports.handler = async (event) => {
  console.log("🔒 Event received:", JSON.stringify(event));

  // Check if authorizer is attached and parsed
  const claims = event?.requestContext?.authorizer?.jwt?.claims;
  if (!claims) {
    console.error("🚨 Missing Cognito claims");
    return {
      statusCode: 401,
      body: JSON.stringify({ message: "Unauthorized: No claims" }),
    };
  }
  try {
    // 📥 Query the DynamoDB table for up to 50 of the most recent sensor readings
    const data = await client.send(
      new ScanCommand({
        TableName: process.env.DYNAMODB_TABLE, // Table name injected via environment variable
        Limit: 50, // Prevent loading too many records to maintain speed and reduce cost
      })
    );

    // ✅ On success, return the sensor readings as a JSON response
    return {
      statusCode: 200,
      body: JSON.stringify(data.Items), // ✅ API Gateway requires body to be a string
    };
  } catch (err) {
    // ❌ If something goes wrong (e.g., missing permissions or table), return a 500 error
    return {
      statusCode: 500,
      body: JSON.stringify({
        message: 'Error fetching data from DynamoDB',
        error: err.message, // Include the raw error for debugging visibility
      }),
    };
  }
};

Final thoughts and future improvements.

As I continue refining this platform, I’m also thinking about how to harden it for real-world enterprise use. Improving security means enforcing strict IAM roles, using customer-managed KMS keys, and enabling detailed audit logs through CloudTrail.

For compliance, adding automated AWS Config rules and security checks through tools like AWS Security Hub can help flag misconfigurations early.

Regarding reliability for real-world use, I’d look at adding retry logic, dead-letter queues, and chaos testing to make sure the system gracefully handles edge cases and unexpected failures. These are the kinds of things that turn a functional prototype into a battle-tested backend that real businesses can trust.

If you're building something similar or just enjoy talking backend architecture, hit me up — would love to hear what you're working on.

https://whoschris.dev

How to build a startup service for Node.js server (DEAD SIMPLE)

Christopher — Mon, 30 Sep 2024 23:12:11 +0000

Here is your text converted into rich text format:

How to build a startup service for Node.js server (DEAD SIMPLE)

September 30th, 2024 06:11

Tags: [work] [4 - Indexes/Computer Science | Computer Science] [system design]

If you just want an easy way to ensure that your Node.js app stays running no matter what, you came to the right place. This guide will ensure that you have a reliable auto-running Node.js backend for your full stack application.

1. Install pm2

Run the following command:

npm install -g pm2

Afterwards, verify the installation:

pm2 --version

Once you've verified the installation, go into the root of your Node.js project and add a file called ecosystem.config.js. This will be what pm2 uses to start up the Node backend automatically.

ecosystem.config.js

module.exports = {
  apps: [
    {
      name: 'rcm-server',
      script: 'npm',
      args: 'start',
      watch: true,
      env: {
        NODE_ENV: 'production',
      },
    },
  ],
};

2. Start pm2 service

Run the following command to bind your app's process to pm2:

pm2 start ecosystem.config.js

Then:

pm2 startup

And finally:

pm2 save

Be sure to run any output command it tells you to ensure it gets saved in pm2/dump.pm2

That's it. Really.

Simple DETR Object Detection with Python

Christopher — Thu, 13 Jun 2024 02:32:21 +0000

DETR (DEtection TRansformer) is a deep learning model designed for object detection. It utilizes the Transformer architecture, initially created for natural language processing (NLP) tasks, as its core element to tackle the object detection challenge in an innovative and highly efficient way.

Prerequisites

I’d assume you have a background in programming with python. If not it should be installed on your computer before continuing.

If you need to download Python, you can visit the official Python downloads page.

Download Python

Create your virtual environment

Create a virtual environment in python so you can run your packages separate from your host’s environment

python -m venv myenv

Activate virtual environment

Windows

myenv\Scripts\activate

Mac

source myenv/bin/activate

Install packages

We will need to install a few packages before we get started.

pip install transformers torch Pillow requests

Next, create an /images folder in the root of your project. This is where you will save your images to test your AI solution. Im using .jpg files from www.unsplash.com.

After saving an image into the /images directory, we can now start to write the code that will find our image and pass it into the Image.open() method.

import os
from transformers import DetrImageProcessor, DetrForObjectDetection 
import torch
from PIL import Image 

print("transformers", DetrImageProcessor)

current_dir = os.path.dirname(os.path.abspath(__file__))
images_dir = os.path.abspath(os.path.join(current_dir, 'images'))

print("Root directory:", images_dir)

image_path = os.path.join(images_dir, 'airplane.jpg') #

print("image path:", image_path)
print("Reading images from /images")

image = Image.open(image_path)

print("Processing image...")

Once this runs with no errors, we can confidently add the rest of our solution which will scan and provide the results of our image detection.

processor = DetrImageProcessor.from_pretrained("facebook/detr-resnet-50", revision="no_timm")
model = DetrForObjectDetection.from_pretrained("facebook/detr-resnet-50", revision="no_timm")

inputs = processor(images=image, return_tensors="pt")
outputs = model(**inputs)

target_sizes = torch.tensor([image.size[::-1]])

results = processor.post_process_object_detection(outputs, target_sizes=target_sizes, threshold=0.9)[0]

for score, label, box in zip(results["scores"], results["labels"], results["boxes"]):
    box = [round(i, 2) for i in box.tolist()]
    print(
            f"Detected {model.config.id2label[label.item()]} with confidence "
            f"{round(score.item(), 3)} at location {box}"
    )

After running server.py, you should get an output similar to this. The decimal numbers you see after location are the coordinates of the area in your image that your model detected the object at.

Reading images from /images
Processing image...
Detected bird with confidence 0.992 at location [55.82, 32.17, 225.04, 225.28]

Potential business value

Models like this can provide a lot of value to software services and products people interact with daily.

Image detection models can detect things like cancer in clinical trials, assist autonomous vehicles with identifying red light and emergency signals or even prevent unauthorized access to systems and physical resources by detecting the identity of a user.

Possibilities are endless.

Connect with me on LinkedIn