As a developer, I’ve always been fascinated by the potential of Web3 and its applications. Recently, I embarked on a journey to automate Web3 tasks using Python, and I’m excited to share my experience with you. In this article, I’ll take you through the process of creating a Python script that automates daily NFT mints on the Ethereum blockchain. # Introduction to Web3 Automation Web3 automation refers to the use of software to automate tasks on the blockchain. This can include tasks such as sending transactions, interacting with smart contracts, and minting NFTs. Python is an ideal language for Web3 automation due to its simplicity, flexibility, and extensive libraries. # Setting Up the Environment Before we dive into the code, let’s set up our environment. You’ll need to install the following libraries: * web3: a Python library for interacting with the Ethereum blockchain * json: a library for working with JSON data You can install these libraries using pip:

python import json from web3 import Web3

# Connecting to the Ethereum Blockchain To connect to the Ethereum blockchain, you’ll need to set up a provider. A provider is an API that allows you to interact with the blockchain. You can use a provider like Infura or Alchemy. For this example, I’ll use Infura.

python w3 = Web3(Web3.HTTPProvider('https://mainnet.infura.io/v3/YOUR_PROJECT_ID'))

Replace YOUR_PROJECT_ID with your actual Infura project ID. # Creating an NFT Minting Script Now that we have our environment set up, let’s create a script that mints an NFT on the Ethereum blockchain. We’ll use the web3 library to interact with the blockchain and the json library to work with JSON data.

python def mint_nft(token_name, token_symbol, token_uri): contract_address = '0x...CONTRACT_ADDRESS...' contract_abi = json.loads('...CONTRACT_ABI...') contract = w3.eth.contract(address=contract_address, abi=contract_abi) tx_hash = contract.functions.mintNFT(token_name, token_symbol, token_uri).transact() return tx_hash

Replace ...CONTRACT_ADDRESS... and ...CONTRACT_ABI... with your actual contract address and ABI. # Scheduling the Script to Run Daily To schedule the script to run daily, you can use a scheduler like schedule or apscheduler. For this example, I’ll use schedule.

python import schedule import time def job(): mint_nft('My NFT', 'MNFT', 'https://example.com/metadata.json') schedule.every().day.at('08:00').do(job) while True: schedule.run_pending() time.sleep(1)

This script will run the mint_nft function every day at 8:00 AM. # Conclusion In this article, we’ve created a Python script that automates daily NFT mints on the Ethereum blockchain. We’ve set up our environment, connected to the blockchain, created an NFT minting script, and scheduled the script to run daily. With this script, you can automate your Web3 tasks and focus on more important things. Remember to replace the placeholders with your actual contract address, ABI, and Infura project ID. Happy coding!

FinanceIQ — AI-Powered Finance Tracker Built with Notion MCP

What I Built

FinanceIQ is an AI-powered personal finance tracker that turns Notion into a fully automated financial command center. It ingests your bank’s CSV exports, categorizes every transaction using AI, detects suspicious or anomalous spending, generates monthly financial reports, and fires budget alerts — all written directly into Notion via the Notion MCP.

No spreadsheet juggling. No manual tagging. Your finances, organized and analyzed — living right inside Notion.

Video Demo

Show Us the Code

🔗 github.com/himanshu748/dev-challenge-2

How I Used Notion MCP

Notion MCP is the backbone of FinanceIQ. Rather than building a standalone dashboard that lives in isolation, I wanted all financial data to live natively in Notion — so it’s searchable, shareable, and editable like any other Notion page.

Here’s exactly how Notion MCP powers each part of the workflow:

1. One-Click Workspace Setup

On first run, FinanceIQ uses Notion MCP to automatically create:

• An Expenses database with the right properties (date, amount, category, anomaly flag, etc.)
• A Reports page where monthly summaries will be written

No manual Notion setup required — the agent handles it entirely through MCP.

2. Transaction Import & AI Categorization

When a user uploads a CSV (from Chase, Bank of America, Wells Fargo, or Mint), FinanceIQ:

• Parses each transaction
• Sends it to a HuggingFace-hosted Mistral model (via MCPClient) for categorization into 10 spending categories
• Flags anomalies: transactions that are 3x the category average, duplicates, or suspiciously round amounts
• Writes each transaction as a new row in the Notion Expenses database via MCP

3. Monthly Report Generation

The /report endpoint aggregates data from Notion, runs it through the AI, and writes a structured monthly report page back into Notion including:

• Income vs. expenses summary
• Category-by-category breakdown
• AI-generated spending recommendations

4. Budget Alerts

Users can set monthly budget limits per category. FinanceIQ compares actuals against limits and — when thresholds are exceeded — creates a dedicated Budget Alert page in Notion via MCP with details on which categories overspent and by how much.

What Notion MCP Unlocks

The key insight: Notion MCP lets an AI agent treat Notion as a live, writable database — not just a document viewer. That means FinanceIQ can autonomously create structure, push data, and generate reports without any manual copy-pasting. The financial intelligence stays inside Notion where users already live and work.

Tech Stack

Getting Started

# 1. Clone the repo
git clone https://github.com/himanshu748/dev-challenge-2

# 2. Install dependencies
pip install -r requirements.txt

# 3. Configure environment variables
cp .env.example .env
# Add your HF_API_KEY and NOTION_TOKEN

# 4. Start the server
uvicorn main:app --reload

Then open http://localhost:8000 in your browser.

Required environment variables:

Escrever código está mudando, mas a qualidade deveria cair?

Entenda, não estou aqui para criticar o código gerado pelas LLMs, afinal, ela provavelmente escreve muito melhor que eu, desde que receba as instruções corretas.

E é justamente aí que mora o problema. Nessa nova era do desenvolvimento, onde todo mundo está fascinado com o que a IA consegue fazer, pouca gente está prestando atenção no que está pedindo pra ela. Quando você pede algo genérico, a IA entrega algo genérico. Funciona? Funciona. Mas sem querer, você pode estar gerando um backlog de débito técnico silencioso na sua base de código.

Design patterns

Lembram quando os maias precisavam estudar design patterns para resolver problemas de arquitetura e falar a mesma língua que o resto do time? Pois é, estudar patterns continua importante, mas o motivo principal mudou. Não é mais só sobre comunicação entre devs, embora isso ainda importe. Agora, patterns funcionam como instruções de alta precisão para a IA. São a diferença entre receber código que “funciona” e código que é extensível, testável e que não vai te assombrar em seis meses.

Exemplo

Imagine que você vai criar um sistema de processamento de pagamentos. Você tem cartão, boleto e PIX. Cada tipo de pagamento tem regras diferentes, embora no final todos tenham a mesma finalidade, cobrar o cliente. Para isso, a gente poderia optar pelo padrão Strategy.

Agora vamos pensar em como um dev sem esse conhecimento pediria isso pra IA.
Ele descreve o que precisa, e só:

"Crie um serviço em NestJS que processa pagamentos via cartão de crédito,
boleto e PIX."

A IA vai entregar algo funcional, provavelmente um PaymentService com um método cheio de condicionais. Vai funcionar? Vai. Mas pensando em manutenção futura é horrível, difícil de testar.

Código da service gerado pela IA (Sonnet 4.6 no Claude Code):

import { BadRequestException, Injectable } from "@nestjs/common";
import { ProcessPaymentDto } from "./dto/process-payment.dto";

@Injectable()
export class PaymentsService {
  process(dto: ProcessPaymentDto) {
    switch (dto.method) {
      case "credit_card":
        return this.processCreditCard(dto.amount, dto.description);
      case "boleto":
        return this.processBoleto(dto.amount, dto.description);
      case "pix":
        return this.processPix(dto.amount, dto.description);
      default:
        throw new BadRequestException(
          `Método de pagamento inválido: ${(dto as any).method}`,
        );
    }
  }

  private processCreditCard(amount: number, description?: string) {
    return {
      method: "credit_card",
      status: "approved",
      amount,
      description,
      authorizationCode: this.generateCode(),
      processedAt: new Date().toISOString(),
    };
  }

  private processBoleto(amount: number, description?: string) {
    const dueDate = new Date();
    dueDate.setDate(dueDate.getDate() + 3);

    return {
      method: "boleto",
      status: "pending",
      amount,
      description,
      barcode: this.generateBarcode(),
      dueDate: dueDate.toISOString(),
      processedAt: new Date().toISOString(),
    };
  }

  private processPix(amount: number, description?: string) {
    return {
      method: "pix",
      status: "approved",
      amount,
      description,
      txid: this.generateCode(),
      pixKey: "[email protected]",
      processedAt: new Date().toISOString(),
    };
  }

  private generateCode(): string {
    return Math.random().toString(36).substring(2, 14).toUpperCase();
  }

  private generateBarcode(): string {
    return Array.from({ length: 44 }, () =>
      Math.floor(Math.random() * 10),
    ).join("");
  }
}

Agora pensa comigo num prompt feito por alguém que sabe o que quer, e sabe dizer como quer:

"Crie um serviço de processamento de pagamento em NestJS, usando o pattern Strategy.
Defina uma interface PaymentStrategy com um método process(). Implemente uma classe
concreta para cada meio de pagamento (cartão, boleto, PIX).
Use o módulo de injeção de dependência do NestJS para resolver a estratégia correta
em tempo de execução."

A diferença aqui fica clara. Não estamos falando apenas de ter citado o nome do padrão. Estamos falando de passar pra IA uma planta arquitetural. Ela sabe exatamente o que você espera.

O resultado? O output gerado vai ser extensível: precisa adicionar outra forma de pagamento como Apple Pay ou Stripe? É só criar uma nova classe. Nenhum outro método é afetado, o que reduz drasticamente a chance de efeito colateral. E cada meio de pagamento pode ser testado de forma isolada, com seu próprio teste unitário.

import { BadRequestException, Inject, Injectable } from "@nestjs/common";
import { PaymentStrategy } from "./interfaces/payment-strategy.interface";
import { CreatePaymentDto } from "./dto/create-payment.dto";

export const PAYMENT_STRATEGIES = "PAYMENT_STRATEGIES";

@Injectable()
export class PaymentsService {
  constructor(
    @Inject(PAYMENT_STRATEGIES)
    private readonly strategies: PaymentStrategy[],
  ) {}

  process(dto: CreatePaymentDto) {
    const strategy = this.strategies.find((s) => s.method === dto.method);

    if (!strategy) {
      throw new BadRequestException(
        `Método de pagamento inválido: ${dto.method}`,
      );
    }

    return strategy.process(dto.amount);
  }
}

Interface da nossa Strategy:

export interface PaymentResult {
  transactionId: string;
  method: string;
  amount: number;
  status: string;
}

export interface PaymentStrategy {
  readonly method: string;
  process(amount: number): PaymentResult;
}

Estratégias concretas:

BoletoStrategy:

import { Injectable } from "@nestjs/common";
import {
  PaymentResult,
  PaymentStrategy,
} from "../interfaces/payment-strategy.interface";

@Injectable()
export class BoletoStrategy implements PaymentStrategy {
  readonly method = "boleto";

  process(amount: number): PaymentResult {
    return {
      transactionId: `BOL-${Math.floor(Math.random() * 10000)}`,
      method: this.method,
      amount,
      status: "pending",
    };
  }
}

CreditCardStrategy:

import { Injectable } from "@nestjs/common";
import {
  PaymentResult,
  PaymentStrategy,
} from "../interfaces/payment-strategy.interface";

@Injectable()
export class CreditCardStrategy implements PaymentStrategy {
  readonly method = "credit_card";

  process(amount: number): PaymentResult {
    return {
      transactionId: `CC-${Math.floor(Math.random() * 10000)}`,
      method: this.method,
      amount,
      status: "approved",
    };
  }
}

PixStrategy:

import { Injectable } from "@nestjs/common";
import {
  PaymentResult,
  PaymentStrategy,
} from "../interfaces/payment-strategy.interface";

@Injectable()
export class PixStrategy implements PaymentStrategy {
  readonly method = "pix";

  process(amount: number): PaymentResult {
    return {
      transactionId: `PIX-${Math.floor(Math.random() * 10000)}`,
      method: this.method,
      amount,
      status: "approved",
    };
  }
}

Lembrando que isso aqui é um código de exemplo, não vai gerar pix, fiquem tranquilos.

Cenas dos próximos capítulos

Esse é apenas o começo. Nos próximos posts dessa série, vou explorar outros design patterns e repetir o mesmo exercício: prompt genérico vs. prompt com pattern, lado a lado. O objetivo é sempre o mesmo, te provocar a escrever prompts melhores, que geram código que não vai virar uma bola de neve nos seus projetos.

A ideia é simples: mostrar que na era do desenvolvimento assistido por IA, saber o que pedir é tão importante quanto saber codar.

Mais em: https://ojeremias.dev/

The Model Context Protocol (MCP) is rapidly becoming the standard way AI agents discover and use tools. But most MCP servers today use the stdio transport — they run locally and communicate through standard input/output. That’s fine for desktop use, but what about cloud deployment?

In this post, I’ll walk through how I migrated an MCP server from stdio to Streamable HTTP, deployed it on Vercel’s free tier, and got it listed on Smithery.ai — all in a single afternoon.

The Problem: stdio Doesn’t Scale

When you build an MCP server with stdio transport, it works great locally:

npx -y @anthropic/mcp-server-my-tool

But platforms like Smithery.ai, which host and proxy MCP servers for thousands of users, need an HTTP endpoint they can call. The MCP specification defines two remote transports:

1. SSE (Server-Sent Events) — the older approach, being deprecated
2. Streamable HTTP — the new standard (March 2025 spec)

The Architecture Decision

I had three options:

I chose Vercel Serverless because it’s free, auto-scales, and most MCP tool calls are simple request-response patterns that don’t need streaming.

The Implementation

The key insight: MCP’s Streamable HTTP transport sends JSON-RPC messages via POST. For simple tool calls, you don’t need SSE — you can return the JSON-RPC response directly.

Here’s the core handler:

// api/mcp.ts
import type { VercelRequest, VercelResponse } from '@vercel/node';

export default async function handler(req: VercelRequest, res: VercelResponse) {
  if (req.method === 'GET') {
    return res.json({ status: 'ok', transport: 'streamable-http' });
  }

  if (req.method === 'POST') {
    const { method, params, id } = req.body;

    switch (method) {
      case 'initialize':
        return res.json({
          jsonrpc: '2.0', id,
          result: {
            protocolVersion: '2025-03-26',
            capabilities: { tools: { listChanged: false } },
            serverInfo: { name: 'my-server', version: '1.0.0' }
          }
        });

      case 'tools/list':
        return res.json({
          jsonrpc: '2.0', id,
          result: { tools: MY_TOOLS }
        });

      case 'tools/call':
        const result = await executeToolCall(params);
        return res.json({
          jsonrpc: '2.0', id,
          result: { content: [{ type: 'text', text: JSON.stringify(result) }] }
        });

      case 'notifications/initialized':
        return res.status(202).end();
    }
  }
}

Session Management (or Lack Thereof)

The full MCP spec requires session management via Mcp-Session-Id headers. On Vercel Serverless, each invocation is stateless. My solution:

• Generate a session ID on initialize
• Return it in the response headers
• Accept it on subsequent requests (but don’t actually track state)

This works because my tools are stateless — each call is independent. If your tools need session state, you’ll need a database or KV store.

Deploying to Vercel

{
  "rewrites": [{ "source": "/mcp", "destination": "/api/mcp" }],
  "functions": { "api/mcp.ts": { "maxDuration": 30 } }
}

vercel --yes --prod

That’s it. Free HTTPS endpoint, auto-scaling, zero maintenance.

Testing

# Health check
curl https://your-server.vercel.app/api/mcp

# Initialize
curl -X POST https://your-server.vercel.app/api/mcp 
  -H "Content-Type: application/json" 
  -d '{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

# Call a tool
curl -X POST https://your-server.vercel.app/api/mcp 
  -H "Content-Type: application/json" 
  -d '{"jsonrpc":"2.0","method":"tools/call","id":3,"params":{"name":"my_tool","arguments":{"query":"test"}}}'

Publishing to Smithery

Once your HTTP endpoint is live, publishing to Smithery is straightforward:

1. Go to smithery.ai/servers/new
2. Enter your server ID (e.g., username/server-name)
3. Paste your HTTP endpoint URL
4. Click Continue → Skip (if no connection params needed)

Smithery will probe your endpoint, detect your tools, and generate a quality score. Our server got all 5 tools detected immediately.

Lessons Learned

1. You don’t need SSE for most use cases. Simple JSON-RPC request-response works fine for tool calls.
2. Vercel’s free tier is surprisingly capable for MCP servers. The 30-second function timeout is more than enough.
3. Keep your tools stateless. It makes deployment dramatically simpler.
4. The MCP ecosystem is moving fast. The Streamable HTTP transport was only standardized in March 2025, and platforms are already adopting it.

What’s Next

The MCP ecosystem needs better discovery. Right now, finding useful MCP servers means searching GitHub, checking npm, or browsing directories like Smithery and Glama. As the number of servers grows, we’ll need something more structured — think npm for AI tools.

If you’re building MCP servers and want to see how this works in practice, check out the SkillFlow MCP Server — it implements everything described here.

Have questions about MCP transports or serverless deployment? Drop a comment below.

Today I learned that creating a table is only the first step in SQL. Sometimes, after creating a table, we may realize that we need to change some rules. For example, maybe a column should not allow empty values, or maybe we want to add a new constraint later.
For this, SQL gives us an important command called ALTER TABLE.

ALTER TABLE is used when we want to change the structure of an existing table without deleting it and creating it again.

In this blog, I am going to explain different ALTER TABLE tasks in a simple way.

1. Making email compulsory in the customers table
   Suppose we already have a table called customers, and its email column currently allows NULL values. But now we want all future records to обязательно have an email value.

For that, we can modify the column using:

ALTER TABLE customers
ALTER COLUMN email SET NOT NULL;
What this does:
This command makes the email field compulsory from now on.
So, while inserting new records, we cannot leave the email empty.

1. Making username unique in the users table
   In many applications, usernames should be unique. Two users should not have the same username.
   If the table is already created, we can add this rule later using ALTER TABLE.

ALTER TABLE users
ADD CONSTRAINT unique_username UNIQUE (username);
What this does:
This adds a UNIQUE constraint on the username column.
That means duplicate usernames are not allowed.

1. Ensuring product price is always greater than 0
   In the products table, price should never be zero or negative.
   This can be enforced using a CHECK constraint.

ALTER TABLE products
ADD CONSTRAINT check_price_positive CHECK (price > 0);
What this does:
This makes sure the price value is always greater than 0.
So invalid prices cannot be inserted.

1. Setting default status in orders table
   Sometimes when we insert a new order, we may forget to mention the order status.
   In such cases, it is useful to automatically set a default value like ‘pending’.

ALTER TABLE orders
ALTER COLUMN status SET DEFAULT ‘pending’;
What this does:
If no status is given during insertion, SQL will automatically store ‘pending’.

1. Adding a salary column in employees table
   Now let us say we want to add a new column called salary in the employees table.
   The condition is:

• salary should not be NULL
• salary should always be greater than 10,000
  This can be done like this:

ALTER TABLE employees
ADD COLUMN salary DECIMAL(10,2) NOT NULL CHECK (salary > 10000);
What this does:

• This creates a new column called salary and applies two rules:
• it must have a value
• the value must be above 10,000
• Changing foreign key so deleting a department also deletes employees
  Suppose the employees table is connected to the departments table using a foreign key.
  Now we want this behavior:

If a department is deleted, all employees belonging to that department should also be deleted automatically.

Usually, first we remove the old foreign key constraint, then add a new one with ON DELETE CASCADE.

ALTER TABLE employees
DROP CONSTRAINT employees_department_id_fkey;

ALTER TABLE employees
ADD CONSTRAINT employees_department_id_fkey
FOREIGN KEY (department_id)
REFERENCES departments(id)
ON DELETE CASCADE;
What this does:
If a department row is deleted, all matching employee rows are also deleted automatically.

1. Removing an existing CHECK constraint from accounts table
   In the accounts table, assume there is already a CHECK constraint that ensures balance >= 0.
   If we want to remove that rule, we need to drop the constraint.

Example:

ALTER TABLE accounts
DROP CONSTRAINT accounts_balance_check;
What this does:
This removes the check condition from the balance column.

1. Making combination of user_id and transaction_id unique in payments table
   In the payments table, one user_id and transaction_id combination should not repeat.
   This means the pair together must be unique.

ALTER TABLE payments
ADD CONSTRAINT unique_user_transaction UNIQUE (user_id, transaction_id);

What this does:
This prevents duplicate entries with the same user_id and transaction_id combination.

I would like to paint a picture. If it’s familiar, keep reading. If it sounds outlandish and not relatable, this is not the article for you.

You have a small company.

You are winging it from day to day, adapting and iterating with no, or minimal, process.

Everyone talks out loud of process, of predictability, of structure they will eventually implement. But your small team pushes forward with late hours, big over-the-weekend features that come with incremental wins, and while everyone is exhausted, the sentimentality is “at least we don’t have big company culture”. The entire team is vastly intelligent, capable to find patterns and angles on problem spaces that many others can’t see.

Innovation is built in at every step. It’s a core value, as is similar mantras like “have fun” and “employees first” (even though not a single person in the team knows how to maintain “work-life” balance).

You become successful.

You either get a big client or you reach a tipping point on income that allows you to grow ambitious and plan further than one month ahead.

So you grow.

You adopt a framework, the structure you always dreamed of. The word “Agile” got used somewhere in the description, so you call the framework “Agile”. “We are doing Agile now.”

And you slow.

Some of the former powerhouses shift into leadership. Some of the powerhouses remain attached to fast-moving projects that “must happen”. And one or two others move on, attached to “small company culture”. The most vocal quit, either attached to “small company culture” or feeling generally not enabled to provide the value they used to. It’s a huge loss as they were specialists on technology or a specific vertical.

But that’s part of the cost of growth, right?

You keep growing.

You go through a V2 of your “Agile” process that really pins down your process to make sure “quality is baked in at every step”.

To some extent, the “Agile” framework helps. You are able to sustain multiple teams, and as you start measuring velocity, you get an understanding of effort-to-value ratios.

But most of the engineers and some of the management feel like they are focusing on metrics rather than deliverables.

Why are they so caught up with the numbers? They are meant to just be validation, not the product.

Everyone in leadership says that, but when it comes to getting things done, it’s always about the metrics.

Do the numbers themselves look right? You aren’t sure.

You most certainly don’t feel like you’re getting as much done as you had before.

What the Hell Happened?

You switched the motivational framework.

In an unstructured environment, especially in Engineering, motivations come from unsolved, complex problems, novelty, urgency, and personal interest. Responsibility is a byproduct or guiding factor, not a driver.

Throw those motivation factors into a Google search.

I’ll wait.

Additionally, in small companies, there is a lot of agency and freedom to tackle problems that require unrefined requirements to be reduced to logical, repeatable patterns that are represented in a vastly complex system.

Throw “individuals with advanced pattern recognition and rules extrapolation and a pathological need for agency” into that search.

Wait, my Team Isn’t ADHD or Autistic

It’s entirely possible.

But the line for the two diagnoses revolves around “disability”, which, by the social model, is scoped to the relationship between the individual and the environment, not the individual itself. In the right environment, this means symptoms of the disability can (depending on the severity or type of disability) become completely transparent or seem like “just part of the job”.

It’s basically accidental masking by being successful, and it is fairly common.

I have, personally, become fairly convinced that there exists an alarmingly high amount of undiagnosed ADHD and Autistic Leadership in Engineering that are unintentionally masking simply by having found the right environment to fit their motivational framework. This is partly informed by many tech giants speculating that they would likely have been diagnosed as Autistic when younger (see: Bill Gates).

On that point, it’s worth taking a moment to note that this article exists in the space of “Lived Experience” (community discussions/personal experience) and “Emerging Theory” (professional speculation). “Institutional Knowledge” (DSM-5) is far behind the active discussion space (by design).

To give an idea of just how far behind institutional knowledge is, it was just a bit more than a decade ago that the DSM recognized that Autism and ADHD could both be diagnosable in the same individual, and there’s now an estimated ~50% co-diagnosis rate.

The point being that discussions on neurodivergence are moving fast.

What I can confidently say is:
1) Most everyone already knew the Engineering world had a high ratio of neurodivergent representation. There exist studies on this already.
2) Society is going through an unprecedented wave of demasking and diagnosis. (If you’re successful in Engineering, I suggest taking this test https://raads-r.net/ if you have some time to kill)
3) Even for those not severe enough to be diagnosed, Autistic/ADHD traits are present across “neurotypical” society. Those traits are going to be very common in engineering, which requires non-linear and highly cognitive processing. (search: Autistic traits continuous in general population).

How Does this Relate to Agile?

Great guiding question, me!

I would like to call attention to the Agile Manifesto. Not an Agile framework. The core philosophy.

https://agilemanifesto.org/principles.html

In particular:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

This is, coincidentally, in line with the current directive for most neurodivergent therapy. Integration, not assimilation. In HR terms, we call it equity.

When you had low process and high agency, with constant stimulation driven by urgency, novelty, and personal passion, you had an environment that appealed to a neurotype that is very powerful when motivated.

This is a neurotype that will often put in 60 hours a week and like it (assuming they are actually motivated). This is a neurotype that will solve complex problems over a weekend that might take others months to even understand.

The misguided lessons society has taught itself about “work-life balance” have led us to adopt the 9-5 workweek, based on the assertion that it would work for everyone and that it’s the box you must fit into to be successful.

Many companies then built a bunch of fancy metrics around this philosophy in a misguided attempt to show just how productive this 9-5 workweek was at driving motivation.

And neurodivergents, in response, invented the mouse wiggler.

In some jobs, time worked is the measurable deliverable.

Engineering is not one of those jobs. You deliver software, not time.

You’re Suggesting 60-hour Weeks are GOOD?

Sustainably? Every week? Absolutely not.

I’ve personally had 60-hour weeks and 10-hour weeks.

I’ve solved months of value in 2 hours, and gone down the wrong rabbit hole for weeks.

AuDHD (Autism + ADHD, that’s me) in particular often comes with a drive to solve problems. I’m either solving a problem or looking for a new problem to solve. Responsibility is a guiding factor, not the engine. Burnout stems from either working on long-term projects out of obligation (and not motivation) or from too little going on (“boreout”).

There’s a bit of nature vs. nurture in the discussion of where that “eternal antsyness” originates. I’d highly recommend doing some research on that if the question “should AuDHD be that way” popped into your head. It’s a fascinating rabbit hole that will show you the bigger picture of just how much society shoots itself in the foot with misleading messaging and expectations.

You Just Implied Velocity Isn’t Constant

I’m not implying.

I’m stating.

The illusion of constant velocity is one of the most harmful lies society tells itself.

Across a team and over a sufficiently long timespan, velocity can approach consistency. But not at a granular, individual level.

There’s an important entry in the manifesto.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

And a second one.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Preference is for shorter time periods, but the extreme of “day to day velocity” becomes micromanaging (and risks encroaching on the neurodivergent need for agency, which has a high risk for causing burnout and turnover. Search: Pathological Demand Avoidance).

Two-week sprints are generally a good time frame for most teams to average out to a “constant pace”, so those tend to be what get used. I do believe it’s important for a team to have an established contract on their iteration team, especially since time-boxing is such an important concept for ADHD (which often comes with perfectionism).

But ultimately, at an individual level, the smaller the time frame you consider, the harder it is to say “spontaneous bursts of innovation and complex problem solving” and “predictable delivery speed” in the same breath.

There’s a balance.

As a side note, search for “ADHD time blindness”; it will likely explain why you struggle with overcommitting or undercommitting in almost every sprint. Many neurodivergent employees try to plan around their highest velocity rather than their expected velocity. Combine that with a bunch of biology around dopamine dysregulation that I’m not going to get into here, and you get powerhouses that are incapable of predicting just how powerful they will be.

Wouldn’t that Show up in the Metrics?

Enter Autism.

Pattern and rules extraction are our entire thing. (That’s a reductionist statement for the sake of making a point, we have a lot of things, don’t @ me)

Intuition is not intuitive for us. Big-picture thinking (holistic intuition) is often low, while expertise and wisdom (pattern-based intuition) are often higher, but take time to build.

This is by design in Engineering.

You want employees who are cognitive-forward; employees who are missing the caching layer of intuition. It means the problems get properly analyzed (cognition) with very few assumptions made (intuition), and a sustainable solution is implemented. Engineers don’t just write code; they pattern-match and extract rules from requirements.

Intuition would tell you, “Don’t re-invent the wheel.”
Cognition would tell you, “But the wheels we have aren’t built for this terrain. In a few weeks, we can invent the plane.”
(And Intuition might then question, “Why are we even talking about wheels? We build houses.”)

But when we haven’t had time to iterate on the same problem space for long periods (building expertise), we default to repeatable processes and numbers to reduce the problem space to bite-sized, actionable information.

More often than not, this leads to gamifying the numbers. Mouse wigglers, not pulling in extra work when work is done faster, over-pointing efforts, under-pointing efforts, skipping process completely for certain efforts, etc.

In the absence of more concrete directives on deliverables, making sure those numbers look good, min/maxing them, is inevitable. It’s not generally an active decision; it’s just a piece of the puzzle we incorporate into the planning process when everything else is open-ended and doesn’t match a pattern we are familiar with.

This is Still about Agile, Right?

Yes!

The core moment you went wrong, the single “what should we have done differently?” decision point, was picking a singular Agile Framework to prescribe to a full department.

These frameworks often prescribe, or are interpreted as prescribing:

• Low, or no, rollover
• No mid-sprint changes
• Predictable velocity at a granular scale
• All work to be completely scoped before committing
• Time commits on work to be predictable and exact
• Turning Engineers into code monkeys, rather than problem solvers, moving decision-making entirely into other teams (Architects, Product, UX, QA, etc.)

If you look at the core 12 principles of the Agile manifesto, every single one of those bullet points comes back to a misinterpretation of the Agile philosophy.

And most importantly, every single one of those bullet points is incompatible with the neurotypes you have built your team out of.

You have not created an environment for motivated individuals; you have created one for the “neurotypical” mentality, which so few people thrive in. (If you want another fun rabbit hole, search “does the ‘neurotypical’ person exist at the biological level”. Spoilers: It’s a sociopolitical term, not medical. Depending on how you draw a few lines in definitions in ‘normal’, it’s not even a majority.)

Assuming You’re Right, What Do We Do About it?

Be Agile, don’t do Agile.

Provide the right environment.

The manifesto is the important part, not the frameworks.

You need different processes for different types of teams, different types of projects, and different budgets.

I want to call attention to an important entry in the manifesto:

Simplicity–the art of maximizing the amount
of work not done–is essential.

And another one:

The best architectures, requirements, and designs
emerge from self-organizing teams.

One-size-fits-all process is the problem, not the existence of process. Process is important, process enables, process protects. But doing less, quite literally, translates to doing more.

I can personally tell you that when I am mid flow-state on a big project, even transitioning a Jira ticket that carries no perceived value can be enough to break momentum. It’s unbearable. I can physically feel the frustration from it in my veins.

Those without ADHD are likely thinking this is melodramatic. If you know someone with ADHD, ask them. This is a major reason why “context switching” is viewed as a cardinal sin among engineers. Got into the flow in the morning, but was forced into a meeting on a completely unrelated topic? It’s a literal crap shoot on whether I get into that flow again.

Reduce process to only the process that enables development or protects a system.

Highly critical services in maintenance mode require high process. Lesser critical systems require less.

“Must do”, non open-ended work (if you have buckets of work catered to specific important clients, for instance) is good in high process to self-regulate on commits.

If something is greenfield and doesn’t affect production, does it need a full regression test suite and a Jira step for Product approval in a lower environment? Can you just demo on your local machine?

For the other Software Architects out there: Design systems to enable greenfield development to occur out of band from those critical services. This is one of the subtle but most valuable benefits of microservices. It lets you right-size the process.

Another quote:

Working software is the primary measure of progress.

Reduce metrics to those that drive SMART goals. SMART goals are the most empowering weapon for neurodivergent employees, who often crave explicitly defined deliverables (just don’t overprescribe how they get TO those deliverables, see: Pathalogical Demand Avoidance again).

A Couple Other Principles Viewed through the Neurodivergent Lens

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Pattern-based and cognitive-forward decision-making takes time. Couple this with the low Implicit Social Cognition you get with Autism (difficulty to intuitively keep up with an ongoing discussion), you get employees who need longer than your 1-hour meeting to think or process.

Sure, you did sprint planning. That was important. You did due diligence on attempting to plan.

Plans are nothing; planning is everything.

An Engineer realizing a flaw in a plan a few days into a sprint is part of the process. Encourage text-based communication for asynchronous planning, which is very neurodivergent-friendly (giving time to right-size communication and process).

Business people and developers must work
together daily throughout the project.

I mentioned Pathalogical Demand Avoidance a few times.

This is the best way to avoid the problem. Make engineers feel involved in decisions. They are specialists on the system you are building, use that, don’t silo it. Studies exist to prove performance gain from engineer engagement, if you need proof. See: https://link.springer.com/article/10.1007/s10664-023-10293-z

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

This might sound counterintuitive, because many people think of “anti-social” when they hear Autism. If you tried to initiate a discussion about the weather, I might give an awkward smile and do my best to extract myself from the physical pain that is “small talk”.

But when it comes to an area of interest, you can’t shut us up.

The literalness of “face to face” leaves much open to interpretation, but at the end of the day, vocal communication, at the very least (even if just Zoom), is significantly more efficient and effective time-wise. Just define your deliverables going into the meeting and organize the conversations with live note-taking to avoid endless tangents and rabbit-holing.

And finally:

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

This is, coincidentally, how many people with AuDHD simply live their lives. Iterate -> Analyze -> Consult (ideally) -> Iterate. An endless series of “focus hard, then reflect”.

That, at its core, is what you’re aiming for with being Agile.

Well, I’m Neurodivergent, and I figured it out, they Can Learn to Push Through it Just like I did

I want to call this out since I’ve actually heard it said, specifically in the context of prescriptive Agile frameworks.

This is the equivalent of telling someone with severe depression, “just smile like the rest of us”. It’s a form of generational trauma, has ableist undertones, and risks violations of ADA directives on handling ADHD and Autism as a disability.

The world’s take on “undue hardship” and equity in ADHD/Autism is shifting. There are already successful lawsuits on underplaying the severity of mental disabilities in the workplace (including the usage of derogatory words like “lazy” or “disorganized”).

Do some searching. Educate yourself. Become powered by neurodiversity, not disabled by it.