DEV Community: Fabio Hiroki

Chat With Your Database for Free: Build a Private AI Agent in Python

Fabio Hiroki — Sat, 27 Dec 2025 13:54:16 +0000

You know the scenario. You are deep in flow state, solving a complex backend problem, when a Slack notification pops up from a Product Manager:

“Hey, can you quickly pull a list of all users who signed up in Germany last week? I need it for a meeting in 10 minutes.”

You know SQL. You could write that query in your sleep. But you shouldn’t have to.

Every minute you spend writing ad-hoc reporting queries is a minute stolen from building actual product features.

The solution is not to build another complex Admin Dashboard. The solution is to give your team a tool that speaks their language.

In this tutorial, we will build a “Chat with your Database” application. It allows non-technical users to ask questions in plain English, while an AI writes and executes the safe, read-only SQL under the hood.

Best of all? It can run 100% locally.

No API Keys: It costs $0.00.
No Data Privacy Risks: Your production schema never goes to OpenAI.
No “Glue Code” Nightmares: We will use the new Model Context Protocol (MCP) to keep the architecture clean.

By the end of this guide, you will have a deployable Docker container that turns “Hey, can you pull this data?” into “Sure, just ask the bot.”

Let’s reclaim your time.

The Blueprint

To keep this tutorial digestible, I will focus on the core logic of the AI integration. I won’t bore you with 50 lines of Python import statements.

You can grab the complete code (including the Docker setup and Seed Data generator) here:
👉 github.com/fabiothiroki/mcp-local-analyst

Clone it, run docker-compose up, and follow along.

The Architecture: “The USB-C for AI”

Before we write a single line of code, we need to understand why we are using the Model Context Protocol (MCP).

In the early days of LLMs, connecting a model to a database meant writing messy “glue code.” You had to manually inject table definitions into prompts, parse messy regex to find SQL, and handle every error edge-case yourself. It was brittle and hard to maintain.

MCP solves this by standardizing the connection. Think of it like a USB-C port for AI:

Resources (Context): The AI asks, “What data do I have?” Your server replies with the database schema.
Tools (Action): The AI decides, “I need to run a query.” Your server executes the function safely.

We are decoupling the Brain (the LLM) from the Hands (the Database execution).

Here is the stack we will build:

The Brain: Mistral 7B running on Ollama. (We chose Mistral because it follows strict JSON instructions better than many larger models).
The Interface: A Streamlit app where the user chats.
The Server: A Python script using FastMCP that holds the SQLite connection.

Step 1: The Environment (Docker is Your Friend)

We will use Docker to avoid “it works on my machine” syndrome. We need a container that holds our UI and our Database, but can still talk to the Ollama instance running on your host machine.
Become a member

Create a docker-compose.yml file. This is your “one-click” setup:

services:
  mcp-reporter:
    build: .
    container_name: pocket_analyst
    ports:
      - "8501:8501"
    volumes:
      - ./data:/app/data
    environment:
      # Crucial: This lets the container talk to Ollama on your laptop
      - OLLAMA_HOST=http://host.docker.internal:11434
    extra_hosts:
      - "host.docker.internal:host-gateway"

Step 2: The Server (Giving the AI “Hands”)

We use the FastMCP library to create a server. This script does two things: exposes the database schema (Context) and provides a function to query it (Tool).

Note: I’ve omitted code for brevity. Check src/server.py in the repo for the full context.

# ... standard imports and DB setup (see repo) ...

@mcp.resource("sqlite://schema")
def get_schema() -> str:
    """Reads the database schema and returns it as context."""
    # In a real app, you would query sqlite_master dynamically
    return "CREATE TABLE transactions..."

@mcp.tool()
def query_database(sql: str) -> str:
    """
    Executes a read-only SQL query against the database.
    Args:
        sql: The SELECT statement to execute.
    """

    # Connect to the database and execute the query (see repo)

    # Return results as clean JSON dictionaries
    return json.dumps([dict(row) for row in cursor.fetchall()])

Step 3: The Brain (Why Mistral Wins)

Now we need the “Host” — the Streamlit app that manages the conversation.

We are using Ollama to run the model. But here is a critical insight from my testing: Use Mistral 7B, not Llama 3.

While Llama 3 is powerful, smaller models often struggle with strict JSON formatting. You ask for { “sql”: “…” } and Llama might reply with “Sure! Here is your JSON: { … }”. That extra conversational text breaks your parser.

Mistral 7B is remarkably disciplined. It shuts up and outputs the JSON we need to trigger our tool.

Here is the logic for src/app.py:

# ... imports and Streamlit page config omitted ...

# The System Prompt is where we "program" the behavior
# We explicitly tell the model about the schema and the output format
SYSTEM_PROMPT = """
You are a Data Analyst. 
1. Output ONLY a JSON object with the tool call.
2. The format must be: { "tool": "query_database", "sql": "SELECT..." }
3. Always convert cents to main currency units in the final answer.
"""

# ... inside the main chat loop ...

if prompt := st.chat_input("Ask a question..."):
    # 1. Send the user's request to Ollama
    # Note: We use format='json' to force structured output
    response = client.chat(
        model="mistral",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": prompt}
        ],
        format="json" 
    )

    # 2. Parse the tool call
    # (Full error handling and JSON parsing logic is in the repo)
    tool_call = json.loads(response['message']['content'])

    if tool_call['tool'] == 'query_database':
        # 3. Execute the SQL via our MCP Server
        result = call_mcp_tool(tool_call['sql'])

        # 4. Feed the data back to Mistral to summarize
        final_answer = client.chat(
            model="mistral",
            messages=[..., {"role": "user", "content": f"Data: {result}"}]
        )
        st.write(final_answer['message']['content'])

Step 4: Talking to Your Data

Once you run docker-compose up, your container spins up. It automatically runs a seed_data.py script (included in the repo) that fills your SQLite database with 2,000 realistic “Mock Stripe” transactions.

Now, let’s see why this is better than a static dashboard.

Test 1: The “Complex Filter”

In a traditional dashboard, if you wanted to see “Failed payments from Germany,” you’d need a filter for Status and a filter for Country.

The Prompt:

How many failed credit card payments did we receive from Germany yesterday?

The Logic:
Mistral analyzes the schema. It sees country_code, status, payment_method, and created_at. It generates:

SELECT count(*) FROM transactions 
WHERE country_code = 'DE' 
AND status = 'failed' 
AND payment_method = 'card'
AND created_at > date('now', '-1 day');

Test 2: The “Ad-Hoc Transformation”

This is the killer feature. Product Managers often want data formatted in a specific way for their own reports.

The Prompt:

Calculate the total EUR payments per country in the last month, format in CSV

The Result:
The MCP tool returns raw JSON. The LLM then takes that JSON and re-writes it as:

"Country Code","Total EUR Payments"
"US",2873932
"DE",1093878
"GB",533471
"BR",492770
"FR",454523
"JP",348649

The fatal flaw of traditional dashboards is that they only answer the questions you predicted users would ask; this architecture solves the problems you never saw coming, replacing a finite set of hard-coded buttons with the infinite flexibility of language.

Let’s keep growing.

Subscribe to level up your engineering career with confidence.

The “Traffic Jam” That Kills Your Database (And How to Fix It)

Fabio Hiroki — Mon, 22 Dec 2025 07:54:47 +0000

You write a perfect banking API. The logic is sound. The math is flawless. The unit tests pass with green checkmarks every time.

Then, you launch.

Traffic spikes. Two users try to send money to each other simultaneously. Suddenly, your logs explode with red text.

Deadlock detected.

The database didn’t crash because of a bug in your math. It crashed because of a bug in your timing.

Here is how deadlocks happen, how to simulate them with Python, and the one-line logic change that fixes them forever.

TL;DR: You can reproduce this deadlock locally using Docker. Get the full code, including the API and the attack.py script, here: [Link to GitHub Repository]

The “Mexican Standoff”

A database deadlock is exactly like a standoff in a western movie.

Imagine two friends, Alice and Bob. They decide to send $10 to each other at the exact same millisecond.

Here is what happens in the database:

Transaction A (Alice paying Bob): Locks Alice’s row. It now needs to lock Bob’s row to deposit the money.
Transaction B (Bob paying Alice): Locks Bob’s row. It now needs to lock Alice’s row to deposit the money.

Transaction A waits for Bob. Transaction B waits for Alice.

Neither can move. Neither will quit. They will wait for eternity.

Fortunately, modern database engines are smart. They see this circle, realize it will never end, and play the role of the referee. The database brutally kills one of the transactions to let the other survive.

But for your user, that looks like a generic 500 Internal Server Error.

The Crime Scene (The Unsafe Code)

Let’s look at the Python code that causes this disaster.

We are using FastAPI and psycopg to talk to our database. In our “unsafe” transfer endpoint, we lock the sender first, then the receiver.

This feels logical. If I am sending money, I should check my balance first.

@app.post("/transfer/unsafe")
def transfer_unsafe(req: TransferRequest):
    with pool.connection() as conn:
        with conn.cursor() as cur:
            # 1. Lock the sender's account
            # We MUST lock here to safely check if they have funds.
            cur.execute(
                "SELECT balance FROM accounts WHERE id = %s FOR UPDATE", 
                (req.from_account,)
            )
            current_balance = cur.fetchone()[0]

            if current_balance < req.amount:
                raise HTTPException(status_code=400, detail="Insufficient funds")

            # ARTIFICIAL DELAY (Simulating latency)
            time.sleep(0.1) 

            # 2. Perform the Transfer
            cur.execute("UPDATE accounts SET balance = balance - %s WHERE id = %s", (req.amount, req.from_account))

            # --- THE TRAP IS HERE ---
            # This UPDATE statement implicitly tries to lock the receiver's row.
            # If Bob is the receiver, and Bob is running a transaction... deadlock.
            cur.execute("UPDATE accounts SET balance = balance + %s WHERE id = %s", (req.amount, req.to_account))

            conn.commit()

The critical command here is FOR UPDATE.

This tells the database: “I am reading this row, but don’t let anyone else touch it until I’m done.”

If Alice runs this (Locking 1, wanting 2) and Bob runs this (Locking 2, wanting 1) at the same time, the application breaks.

The Attack (Proving It)

You should never trust theory until you break it in practice.
Become a member

I wrote a script, attack.py, that uses ThreadPoolExecutor to launch concurrent requests. It forces Alice to pay Bob and Bob to pay Alice simultaneously.

Here is the result of the attack on the unsafe endpoint:

--- Starting Attack ---
Mode: UNSAFE (Deadlock prone)
Users: 8

[1] ✅ Success: Alice -> Bob
[3] ❌ DEADLOCK: Bob -> Alice
[2] ✅ Success: Alice -> Bob
[5] ❌ DEADLOCK: Bob -> Alice
[4] ✅ Success: Alice -> Bob
...
Success:   6
Deadlocks: 14

The database throws a DeadlockDetected error. The transaction is rolled back. The money doesn’t move. The user is angry.

You cannot fix this with faster hardware.

You cannot fix this by optimizing your SQL queries.

You fix this with Geometry.

The Solution: Lock Ordering

To prevent a cycle, you must ensure that everyone acquires locks in the exact same order.

It doesn’t matter who is paying whom.

You must always lock the account with the smaller ID before the account with the larger ID.

Scenario A (Alice pays Bob): Lock ID 1 (Alice), then Lock ID 2 (Bob).
Scenario B (Bob pays Alice): Lock ID 1 (Alice), then Lock ID 2 (Bob).

Notice the difference? In Scenario B, Bob wants to send money. But our code forces him to lock Alice’s account (ID 1) before he locks his own account (ID 2).

If Alice and Bob click “Send” at the same time, they both race to lock ID 1.

One wins. The other waits.

The winner finishes, releases the lock, and the loser proceeds. No circle. No deadlock.

The Safe Code

Here is the fix. It is surprisingly simple. We sort the IDs before we touch the database.

@app.post("/transfer/safe")
def transfer_safe(req: TransferRequest):
    # Determine lock order: Low ID first, High ID second
    first_lock_id = min(req.from_account, req.to_account)
    second_lock_id = max(req.from_account, req.to_account)

    with pool.connection() as conn:
        with conn.cursor() as cur:
            # 1. Lock accounts in a fixed, consistent order
            cur.execute("SELECT balance FROM accounts WHERE id = %s FOR UPDATE", (first_lock_id,))

            # Even with a delay, the second transaction is just WAITING for the first lock.
            # It hasn't locked anything yet, so no deadlock is possible.
            time.sleep(0.1) 

            cur.execute("SELECT balance FROM accounts WHERE id = %s FOR UPDATE", (second_lock_id,))

            # 2. Now that we have both locks, we check balances and transfer...
            # (Logic proceeds as normal)

By enforcing a global standard for locking (Lowest -> Highest), we physically prevent the circular dependency that causes the crash.

The Aftermath

I ran the exact same attack.py script against the /transfer/safe endpoint.

The latency was slightly higher (because processes had to wait in line), but look at the reliability:

--- Starting Attack ---
Mode: SAFE (Fixed)
Users: 8

[0] ✅ Success: Bob -> Alice
[1] ✅ Success: Alice -> Bob
[2] ✅ Success: Bob -> Alice
[3] ✅ Success: Alice -> Bob
...
Success:   20
Deadlocks: 0

Zero crashes. Perfect consistency.

Summary

Deadlocks aren’t random bad luck. They are predictable consequences of inconsistent locking.

If you touch multiple rows in a single transaction, always touch them in the same order.

Sort your IDs. Save your database.

Build a Free, Private “Chat with PDF” App in 70 Lines of Python

Fabio Hiroki — Tue, 09 Dec 2025 07:12:25 +0000

You have a private PDF you need to talk to.

But you can’t just upload it to ChatGPT. It might contain sensitive client data, internal business plans, or personal financial information.

So you search for a local solution, but every tutorial drags you through a maze of broken dependencies and cryptic error messages. It’s frustrating. It feels like it should be simple.

This guide is different. It gives you a complete, working setup using free, open-source tools that respect your privacy.

We’ll use Ollama for the brain, LanceDB for the memory, and a specific set of libraries that are guaranteed to play nicely together.

Why This Stack? Privacy, Power, and Zero Cost.

The goal is total control and zero cost.

This architecture is built on two core components that run entirely on your machine.

Ollama lets you run powerful large language models (like Llama 3 or Mistral) locally. It’s your offline brain. You download it once, and it’s yours to use forever, no internet connection or API key required.

LanceDB is an open-source vector database designed for simplicity and speed. It’s your AI’s long-term memory, storing the knowledge from your documents in a way the model can instantly search. It’s serverless and embeds directly into your Python application.

The result?

Everything happens on your laptop. Your documents are never sent to a third-party server. Your conversations are yours alone.

Step 1: Get Your Core Tools Running

Before we dive into the code, we need to set up the foundation. This part is surprisingly simple.

First, download and install Ollama for your operating system (macOS, Windows, or Linux).

Open a new, separate terminal window and run this command. Leave this terminal running in the background.

ollama serve

Note: If you get an error that the server is already running, that’s fine: it means the app started automatically.

Once installed, open your terminal and pull the models we’ll need. We’ll use Llama 3 for generation and a specialized model for embeddings.

ollama pull llama3
ollama pull nomic-embed-text

That’s it. You now have a world-class LLM running on your machine.

The Secret Sauce: A Dependency List That Just Works

This is where most tutorials fail you.

They give you code but neglect the most important part: the environment. You end up in “dependency hell,” trying to figure out why libraries refuse to cooperate.

I’ve done the tedious work for you. For managing Python versions like a pro, I recommend pyenv:

pyenv install 3.14.0
pyenv local 3.14.0

Python 3.14.X is the current stable version I built and tested this tutorial.

Key Libraries:

pip install lancedb==0.25.3 ollama==0.6.1 pypdf==6.2.0

This specific combination is your shortcut past hours of troubleshooting. It ensures the code runs on the first try.

For a quick start, the full repository — including the Python script and requirements.txt — is available on GitHub.

Now, let’s walk through the code.

Step 2: The Code: Your Private RAG Engine in Under 70 Lines

The environment is ready.

Here is the complete Python script. Make sure to place a PDF file named file.pdf in the same directory.

import ollama
import lancedb
from pypdf import PdfReader
import os

# --- CONFIGURATION ---
DOC_PATH = "file.pdf"  # Ensure this file exists
DB_PATH = "./lancedb_data"
MODEL_EMBED = "nomic-embed-text"
MODEL_GEN = "llama3"

print("--- 🧠 Building Knowledge Base with LanceDB ---")

# 1. INGESTION: Read PDF
try:
    reader = PdfReader(DOC_PATH)
    text = ""
    for page in reader.pages:
        text += page.extract_text() or ""
except FileNotFoundError:
    print(f"❌ Error: Could not find {DOC_PATH}. Please add a PDF file.")
    exit()

# 2. CHUNKING
chunk_size = 1000
text_chunks = [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)]
print(f"📄 Processed {len(text_chunks)} text chunks.")

# 3. EMBEDDING & STORAGE
# LanceDB expects a list of dictionaries (like JSON rows)
data = []
print("⏳ Generating embeddings (this may take a moment)...")

for i, chunk in enumerate(text_chunks):
    # Generate vector using Ollama
    response = ollama.embeddings(model=MODEL_EMBED, prompt=chunk)
    vector = response["embedding"]

    # Prepare row for database
    data.append({
        "id": i,
        "text": chunk,
        "vector": vector
    })

# Connect to LanceDB (creates the folder automatically)
db = lancedb.connect(DB_PATH)

# Create (or overwrite) the table
# vector_len depends on the model (nomic-embed-text is usually 768)
try:
    table = db.create_table("resume", data=data, mode="overwrite")
    print("💾 Knowledge stored in LanceDB (Local Disk).")
except Exception as e:
    print(f"⚠️ Database error: {e}")
    exit()

# 4. RETRIEVAL LOOP
while True:
    query = input("\n❓ Ask about the file (or 'quit'): ")
    if query.lower() == 'quit': break

    # Embed the question
    query_vec = ollama.embeddings(model=MODEL_EMBED, prompt=query)["embedding"]

    # Search LanceDB (Find nearest neighbors)
    # .limit(1) = Get the top 1 most relevant chunk
    results = table.search(query_vec).limit(1).to_list()

    if results:
        best_chunk = results[0]["text"]
        print(f"\n🔍 Context Found:\n'...{best_chunk[:100]}...'")

        # 5. GENERATION
        prompt = f"""
        Use the context below to answer the question.

        Context: {best_chunk}
        Question: {query}
        """

        response = ollama.generate(model=MODEL_GEN, prompt=prompt)
        print(f"\n🤖 Answer: {response['response']}")
    else:
        print("❌ No relevant info found.")

How the Code Works: A Quick Breakdown

This script implements a classic Retrieval-Augmented Generation (RAG) workflow. It looks complex, but it’s just five logical steps.

Ingestion & Chunking
First, the script loads your PDF and splits its text into manageable 1,000-character pieces (“chunks”). A model can’t process a 100-page document all at once, so this step makes the information digestible.
Embedding & Storage
Next, it loops through each chunk and asks Ollama’s nomic-embed-text model to convert it into a vector (a list of numbers representing its meaning). These vectors, along with the original text, are saved into a LanceDB table right on your disk. Your knowledge base is now built.
The Query Loop
The script then enters a loop, waiting for you to ask a question.
Retrieval
When you enter a query, it’s also converted into a vector. LanceDB then performs a lightning-fast search to find the text chunk with the most similar vector. This is the “retrieval” step: finding the single most relevant piece of context from the entire document to answer your specific question.
Generation
Finally, the script bundles that relevant chunk with your original question into a new prompt. It sends this to Llama 3, which uses the provided context to generate a precise, accurate answer.

This flywheel from your question to retrieval to a generated answer is what makes the magic happen.

Step 3: Put Your Assistant to Work (Real-World Examples)

Running the script is just the start. The real power is in the quality of your questions.

I tested this with a dense, jargon-filled financial document: “Meta Reports Third Quarter 2025 Results.”

Here’s how a simple script transforms into a powerful analytical partner.

Example 1: Instantly Summarize Complex Financial Reports

The document is full of SEC boilerplate and investor-speak. My goal was to cut through the noise and get the most critical information, fast.

My Prompt:

Summarize the key financial highlights from this report in three bullet points. Focus on revenue, net income, and daily active users.

AI’s Response:

🤖 Answer: Here are the key financial highlights summarized in three bullet points:

Revenue: Revenue was $51.24 billion, an increase of 26% year-over-year (25% on a constant currency basis).

Net Income: No net income figure is mentioned in this report, only revenue and other financial metrics.

Daily Active Users (DAU): Family daily active people (DAP) was 3.54 billion on average for September 2025, an increase of 8% year-over-year.

In seconds, you get the core metrics without reading 20 pages. This is perfect for grasping the essentials before a meeting or making a quick decision.

Example 2: Prepare for a High-Stakes Stakeholder Meeting

Now, let’s move beyond simple data extraction.

Imagine you have to present these findings to skeptical stakeholders. You can use the AI to pressure-test your arguments and anticipate difficult questions.

My Prompt:

Assume the role of a skeptical board member. Based on this report, what are the three most challenging questions you would ask me about the company’s performance and future outlook?

AI’s Response:

🤖 Answer: As a skeptical board member, I’d want to drill down into the details and potential risks associated with the company’s performance and future outlook. Here are three challenging questions I’d ask:

What specific factors are driving the uncertainty around dividend payments? You mentioned “market conditions or other factors” as potential risks affecting dividend payments. Can you provide more granularity on what exactly these factors are, and how they might impact our investors? Are we talking about changes in interest rates, economic downturns, or something else entirely?

What is the company doing to mitigate these risks and ensure a stable financial future? Given the uncertainty around dividend payments, I’d want to know if the company has implemented any strategies to reduce its exposure to market fluctuations or other external factors. Are we investing in diversification initiatives, hedging instruments, or other risk-reduction measures?

How confident are you that our quarterly reports will continue to accurately reflect the company’s performance and future outlook? You mention that forward-looking statements are based on assumptions that seem reasonable as of October 29, 2025, but I’d want more assurance that these assumptions won’t change dramatically in the coming quarters. Can we get a sense of what specific factors might lead us to revisit or revise our quarterly reports going forward?

This is a game-changer. Your private AI just became your personal sparring partner, helping you walk into a critical presentation prepared and confident.

This isn’t just a fun project. It’s a foundational step towards building truly sovereign AI applications. The tools are free, the data is yours, and the power is back on your machine.

Now go build something.

Run LangChain Locally in 15 Minutes (Without a Single API Key)

Fabio Hiroki — Tue, 04 Nov 2025 21:55:47 +0000

You don’t need an API key.

That’s the secret everyone seems to forget.

I wanted to dive into LangChain, the powerful framework for building with Large Language Models. But every guide, even the official docs, felt like a trap. They were outdated, incomplete, or pushed me toward a paid Anthropic key.

I wrestled with Python version errors. I hunted for missing dependencies. It was a frustrating maze designed to make me quit.

So I carved my own path.

This is the guide I wish I had. It’s your shortcut to running a powerful LLM on your own machine, completely for free, in the next 15 minutes.

P.S.: If you want to skip the article, you can check the code directly on Github.

1. First, understand why this is a game-changer.

Running an LLM locally is about one thing: speed.

Not processing speed, but the speed of learning.

When you're just trying to get a feel for a new framework, the last thing you want is a roadblock. You don't need to sign up for an API, enter a credit card, or wait for an approval email just to run a "hello, world" prompt.

This local-first approach removes all that friction.

And as a bonus, it comes with three other superpowers:

Zero Cost: It’s completely free, no matter how many prompts you run.
Total Privacy: Your data never leaves your machine.
Full Control: You choose the model, you own the process.

This isn't just about saving money. It's about creating the fastest path to actually building and learning.

2. Next, get your environment right (this is critical).

Set Up Your Python Version.

This is where 99% of tutorials fail. They give vague instructions, but the AI world moves so fast that packages break between minor versions. We will avoid that entirely.

This tutorial was built and verified using Python 3.13.0. Sticking to this exact version removes any guesswork. For managing Python versions like a pro, I recommend pyenv:

pyenv install 3.13.0
pyenv local 3.13.0

Install Ollama.

Ollama is the magic that runs the LLM on your machine. Go to https://ollama.com/download/ and download it for your system. Install it like any other application. It will run quietly in the background, ready when you need it.

3. Now, start Ollama and download your AI model.

With Ollama installed, you need to make sure its server is running before you can download or use a model.

Open a new, separate terminal window and run this command. Leave this terminal running in the background.

ollama serve

Note: If you get an error that the server is already running, that's fine—it means the app started automatically.

Now, in your original terminal, pull the llama3.2 model.

ollama pull llama3.2

This might take a few minutes. You only have to pull once.

4. Then, install the exact package versions.

To guarantee this works, we will install the exact library versions used in this tutorial.

First, create a project folder and set up a virtual environment (a critical best practice):

python -m venv venv
source venv/bin/activate

Now, install the pinned dependencies:

pip install langchain==1.0.3 langchain-ollama==1.0.0

This ensures you have the precise code that we know works. No surprises, no cryptic error messages.

5. Finally, write less than 20 lines of Python code.

You have the environment, the model, and the libraries. All that's left is to connect them.

Create a new Python file named main.py and paste in the following code.

from langchain.agents import create_agent
from langchain_ollama import ChatOllama

def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"Return the weather in {city} in a joke."

agent = create_agent(
    model=ChatOllama(model="llama3.2"),
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

if __name__ == "__main__":
    # Run the agent
    result = agent.invoke(
        {"messages": [{"role": "user", "content": "what is the weather in sf"}]}
    )
    print(result["messages"][-1].content)

The code creates the model, defines a simple instruction, chains them together, and asks a question. That’s the core of LangChain in action.

In your terminal, run the script:

python main.py

You should see something like:

Fog-get about it, it's always raining in San Francisco!

That's it.

You just ran a state-of-the-art LLM on your local machine using LangChain. You've bypassed the confusing docs, avoided all API keys, and built something that is 100% free and private.

Now, what will you build next?

Como eu uso IA de graça para transformar podcasts em lições práticas

Fabio Hiroki — Thu, 18 Sep 2025 15:43:45 +0000

Vamos ser honestos: o quanto do último podcast que você ouviu você realmente lembra?

Se você é como a maioria das pessoas, a resposta provavelmente é "não muito". Passamos horas toda semana consumindo conselhos incríveis e transformadores das pessoas mais inteligentes do mundo, apenas para que tudo desapareça de nossas mentes em 48 horas. A lacuna entre ouvir e fazer é gigantesca.

Aqui está o truque de IA gratuito que eu uso para consertar isso.

O Truque: De Podcast a Plano de Ação em 60 Segundos

Aqui está o único passo que você precisa:

Pegue a URL do YouTube do podcast que você quer analisar.
Abra o NotebookLM do Google e clique em “Create New“ (Criar Novo).
Clique em “Youtube” e cole a URL como uma nova fonte.
Use este prompt no chat:

Você é um analista de tecnologia especialista em traduzir conceitos amplos em conselhos acionáveis para engenheiros de software. Meu objetivo é extrair as ideias mais relevantes e aplicáveis desta fonte para o meu trabalho.

Instruções:
Analise a fonte fornecida da perspectiva de um engenheiro de software. Identifique os 3 principais conceitos, modelos mentais ou estratégias que são mais aplicáveis ao campo da engenharia de software.

Para cada conceito que você identificar, apresente-o usando a seguinte estrutura clara e concisa. Não me faça perguntas; forneça a informação diretamente.

🚀 Conceito 1: [Nome do Conceito]

Explicação Simples: Em 1-2 frases, o que é este conceito em termos simples, de acordo com o podcast? Forneça uma citação direta do palestrante que melhor encapsula a ideia.

Relevância para Engenheiros: Por que este conceito é particularmente relevante para o desenvolvimento de software, dinâmica de equipe, resolução de problemas ou arquitetura de sistemas?

Aplicação Prática: Forneça um exemplo concreto de como posso aplicar este conceito no meu trabalho esta semana. (ex: uma pergunta a ser feita em uma revisão de código, um princípio para projetar uma nova funcionalidade, uma maneira de me comunicar com minha equipe).

A verdadeira mágica aqui está na primeira linha: "Você é um especialista..." Isso é chamado de "prompt com persona", e é a chave para obter resultados hiper-relevantes.

Você pode, e deve, alterar isso para se adequar à sua própria vida e trabalho. Dica Pro: Você pode usar uma LLM para editar o prompt para você.

Colocando à Prova: Um Exemplo do Mundo Real

Eu executei exatamente esse fluxo de trabalho em um podcast recente de Lenny Rachitsky sobre o Mercado Livre:

Aqui está o resultado do NotebookLM:

Como um analista de tecnologia especialista, analisei a fonte fornecida para identificar os conceitos mais relevantes e aplicáveis para engenheiros de software. Aqui estão os três principais, apresentados com conselhos práticos para o seu trabalho:

🚀 Conceito 1: Propriedade Integrada de Produto e Engenharia

Explicação Simples: No Mercado Livre, há uma indefinição deliberada das linhas entre as funções de engenharia e produto, com uma forte ênfase nos engenheiros assumindo uma propriedade significativa das decisões de produto. O objetivo não é determinar a propriedade pelo cargo, mas por quem é mais adequado para a função, muitas vezes os próprios líderes de engenharia. Como afirma Sebastian Barrios, “é difícil separar onde a engenharia para e o produto começa, e não sentimos que apenas ter um título deveria determinar quem é o dono”.
Relevância para Engenheiros: Este conceito é profundamente relevante para o desenvolvimento de software porque impulsiona os engenheiros para além da mera implementação técnica, para uma compreensão holística do produto, dos usuários e das necessidades do negócio. Ele fomenta um senso mais profundo de responsabilidade pelo sucesso do produto, garantindo que a viabilidade técnica se alinhe perfeitamente com o valor para o usuário e os objetivos de negócio. Espera-se que os engenheiros combinem a compreensão do “que é tecnicamente possível” com “quais são as necessidades do negócio, quais são as necessidades dos usuários, o que os usuários estão fazendo, como vou medir isso”.
Aplicação Prática: Ao projetar ou implementar uma nova funcionalidade esta semana, envolva-se ativamente com seu contexto de negócio e de usuário. Antes de escrever o código, pergunte a si mesmo: “Como o usuário experimentará esse fluxo, e ele o está entendendo?”. Considere o impacto pretendido da funcionalidade no usuário e como seu sucesso seria medido, em vez de focar apenas nos requisitos técnicos.

🚀 Conceito 2: Viés por Expertise Técnica Profunda

Explicação Simples: O Mercado Livre valoriza muito os engenheiros que possuem conhecimento técnico profundo e estão intimamente familiarizados com os detalhes da tecnologia que usam. Há um “forte viés para a engenharia, para ser técnico, para estar a fundo nos detalhes”. Isso significa uma baixa tolerância para compreensão superficial ou para depender de outros para especificidades técnicas.
Relevância para Engenheiros: Para engenheiros de software, este modelo mental enfatiza a importância crítica do domínio técnico. Ele promove a construção de sistemas robustos e escaláveis e permite que os engenheiros liderem discussões de forma eficaz, sem precisar consultar outros para obter informações técnicas fundamentais. Essa compreensão técnica profunda é crucial para a resolução eficiente de problemas, decisões de arquitetura e manutenção de uma alta qualidade nas implantações.
Aplicação Prática: Em sua próxima discussão técnica ou revisão de código, esteja preparado para articular os detalhes técnicos subjacentes da sua solução ou de um componente que você está revisando. Em vez de dizer “preciso verificar com fulano para entender os detalhes,” esforce-se para fornecer você mesmo uma explicação abrangente da tecnologia, suas escolhas e suas implicações.

🚀 Conceito 3: Incentivo à Tomada de Risco e Aprendizado com Falhas de 'Mercado'

Explicação Simples: A empresa fomenta uma cultura onde as equipes são encorajadas a correr riscos e não são penalizadas por lançar funcionalidades que possam falhar devido à recepção do mercado ou a ideias falhas. Sebastian Barrios afirma, “nós realmente empoderamos nossas equipes para cometer erros, tipo, ninguém vai ser demitido por lançar algo que não funcionou no sentido de que talvez o mercado não estivesse pronto ou tivéssemos a ideia errada sobre onde implementar”. Isso contrasta com uma baixa tolerância a falhas relacionadas à má qualidade ou a interrupções do sistema.
Relevância para Engenheiros: Essa estratégia é vital para a inovação no desenvolvimento de software. Ela permite que os engenheiros experimentem novas ideias e funcionalidades, fomentando a criatividade e um ciclo de aprendizado rápido, sem o medo paralisante de repercussões negativas por resultados fora da qualidade técnica. Ela apoia diretamente uma “alta velocidade de execução” em um mercado dinâmico, priorizando o aprendizado e a adaptação.
Aplicação Prática: Esta semana, ao propor uma nova funcionalidade ou uma mudança significativa, enquadre-a como um experimento com hipóteses claras sobre a recepção do usuário ou do mercado. Seja explícito sobre as suposições que estão sendo testadas e como o sucesso ou o fracasso (em termos de adequação ao mercado, não de qualidade técnica) fornecerá um aprendizado valioso para iterações futuras. Essa abordagem encoraja visões ousadas e pivôs rápidos se as suposições iniciais se mostrarem incorretas.

Apenas a Ponta do Iceberg

E esse é o cerne do truque. É um sistema simples e repetível para transformar o consumo passivo em crescimento ativo.

O NotebookLM é uma ferramenta poderosa que pode fazer muito mais, mas eu queria manter este artigo curto e focado no único fluxo de trabalho que mais me deu resultados.

Se você achou isso útil e está interessado em mais conteúdo como este, por favor, me avise! A melhor maneira de fazer isso é deixar um comentário ou clicar no botão 👏 abaixo.

Ficarei feliz em compartilhar mais dicas e truques sobre como uso IA para aprendizado e produtividade. Me diga o que você gostaria de ver a seguir.

My free AI trick to turn podcasts into actionable life lessons

Fabio Hiroki — Tue, 09 Sep 2025 10:00:00 +0000

Let's be honest: how much of the last podcast you listened to do you actually remember?

If you’re like most people, the answer is probably "not much." We spend hours every week consuming incredible, life-changing advice from the world's smartest people, only for it to vanish from our minds within 48 hours. The gap between listening and doing is massive.

Here’s the free AI trick I use to fix it.

The Trick: From Podcast to Action Plan in 60 Seconds

Here’s the only step you need:

Grab the YouTube URL of the podcast you want to analyze.
Open Google's NotebookLM and click “Create New“.
Click “Youtube” and paste the URL as a new source.
Use this prompt in the chat:

You are an expert tech analyst specializing in translating broad concepts into actionable advice for software engineers. My goal is to extract the most relevant and applicable ideas from this source for my work.

Instructions:
Analyze the provided source from the perspective of a software engineer. Identify the top 3 concepts, mental models, or strategies that are most applicable to the field of software engineering.

For each concept you identify, present it using the following clear and concise structure. Do not ask me questions; provide the information directly.

### 🚀 Concept 1: [Name of the Concept]
* **Simple Explanation:** In 1-2 sentences, what is this concept in simple terms, according to the podcast? provide a direct quote from the speaker that best encapsulates the idea.
* **Relevance for Engineers:** Why is this concept particularly relevant to software development, team dynamics, problem-solving, or system architecture?
* **Actionable Application:** Provide one concrete example of how I can apply this concept in my work this week. (e.g., a question to ask in a code review, a principle for designing a new feature, a way to communicate with my team).

The real magic here is the first line: "You are an expert..." This is called "prompting with a persona," and it's the key to getting hyper-relevant results.

You can, and should, change this to suit your own life and work. Pro-Tip: You can use an LLM to edit the prompt for you.

Putting It to the Test: A Real-World Example

I ran this exact workflow on a recent podcast from Lenny Rachitsky
about Mercado Libre:

Here’s the output from NotebookLM:

As an expert tech analyst, I’ve analyzed the provided source to identify the most relevant and applicable concepts for software engineers. Here are the top three, presented with actionable advice for your work:

🚀 Concept 1: Integrated Product-Engineering Ownership
• Simple Explanation: At Mercado Libre, there’s a deliberate blurring of lines between engineering and product roles, with a strong emphasis on engineers taking significant ownership of product decisions. The aim is not to determine ownership by title, but by who is best suited for the role, often the engineering leaders themselves. As Sebastian Barrios states, “it’s hard to separate where engineering stops and product begins and we don’t feel like just having a title should determine who is the owner”

• Relevance for Engineers: This concept is profoundly relevant to software development because it pushes engineers beyond mere technical implementation into a holistic understanding of the product, users, and business needs. It fosters a deeper sense of responsibility and accountability for the product’s success, ensuring that technical feasibility aligns seamlessly with user value and business objectives. Engineers are expected to combine understanding of “what’s technically possible” with “what are the business needs what are the user needs what are the users doing how am I going to measure that”.

• Actionable Application: When designing or implementing a new feature this week, actively engage with its business and user context. Before writing code, ask yourself: “How will the user experience this flow, and are they understanding it?”. Consider the feature’s intended user impact and how its success would be measured, rather than just focusing on the technical requirements alone.

🚀 Concept 2: Bias for Deep Technical Expertise

• Simple Explanation: Mercado Libre places a high value on engineers who possess deep technical knowledge and are intimately familiar with the details of the technology they use. There is a “strong bias for engineering for for for being technical for being deep into the details”. This means a low tolerance for superficial understanding or deferring to others for technical specifics.

• Relevance for Engineers: For software engineers, this mental model emphasizes the critical importance of technical mastery. It promotes building robust, scalable systems and allows engineers to lead discussions effectively without needing to consult others for fundamental technical information. This deep technical understanding is crucial for efficient problem-solving, architectural decisions, and maintaining a high quality of deployments.

• Actionable Application: In your next technical discussion or code review, be prepared to articulate the underlying technical details of your solution or a component you’re reviewing. Instead of saying “I need to check with this person to understand the details,” strive to provide a comprehensive explanation of the technology, its choices, and its implications yourself.

🚀 Concept 3: Empowering Risk-Taking and Learning from ‘Market’ Failures

• Simple Explanation: The company fosters a culture where teams are encouraged to take risks and are not penalized for releasing features that might fail due to market reception or flawed ideas. Sebastian Barrios states, “we actually empower our teams to to to make mistakes like no one’s going to get fired for releasing something that didn’t work in the sense that maybe the market was not ready or we had the wrong idea on on on where had to implement”. This contrasts with a low tolerance for failures related to bad quality or system outages.

• Relevance for Engineers: This strategy is vital for innovation in software development. It enables engineers to experiment with new ideas and features, fostering creativity and a rapid learning cycle without the paralyzing fear of negative repercussions for outcomes outside of technical quality. It directly supports a “high speed of execution” in a dynamic market by prioritizing learning and adaptation.

• Actionable Application: This week, when proposing a new feature or a significant change, frame it as an experiment with clear hypotheses about user or market reception. Be explicit about the assumptions being tested and how success or failure (in terms of market fit, not technical quality) will provide valuable learning for future iterations. This approach encourages bold visions and swift pivots if initial assumptions prove incorrect.

Just the Tip of the Iceberg

And that’s the core of the trick. It’s a simple, repeatable system for turning passive consumption into active growth.

NotebookLM is a powerful tool that can do much more, but I wanted to keep this article short and focused on the one workflow that has given me the most leverage.

If you found this useful and are interested in more content like this, please let me know! The best way to do that is to leave a comment or hit the 👏 button below.

I’ll be happy to share more tips and tricks on how I use AI for learning and productivity. Let me know what you’d like to see next.

[Boost]

Fabio Hiroki — Fri, 22 Aug 2025 06:42:08 +0000

Pradumna Saraf

Aug 19 '25

Running AI Models with Docker Compose

#docker #ai #devops #programming

Comments 23

5 min read

Perseguindo uma Vida Melhor: Como Consegui um Emprego em Tecnologia no Exterior

Fabio Hiroki — Tue, 17 Jun 2025 15:43:54 +0000

Você já sonhou em se mudar para outro país — começar do zero em um lugar novo, com novas oportunidades e uma melhor qualidade de vida? Para muitos engenheiros de software, a ideia de trabalhar no exterior é ao mesmo tempo empolgante e intimidadora. Eu sei, porque já passei por isso.

Nasci e cresci no Brasil, um país em desenvolvimento onde, mesmo como engenheiro de software, a vida traz seus próprios desafios. Embora a profissão possa oferecer um salário confortável, o dia a dia era frequentemente ofuscado por preocupações com segurança — coisas simples como usar o celular em público ou caminhar para casa à noite se tornavam fontes de ansiedade. Quando comecei a pensar em formar uma família, essas preocupações cresceram ainda mais. Eu sabia que não queria que meu filho crescesse em um lugar onde a segurança estivesse sempre na minha mente.

Então veio a pandemia, que só aumentou minha frustração e sensação de inquietação. Foi então que tomei uma decisão: buscar oportunidades no exterior, em países que oferecessem não apenas um emprego, mas uma vida mais segura e equilibrada.

Neste artigo, compartilharei minha jornada, desde o planejamento e a preparação até a busca por emprego — até o momento em que recebi minha primeira oferta. Se você já considerou fazer uma mudança semelhante, ou se está apenas curioso sobre o que é necessário para se mudar como engenheiro de software, espero que minha história inspire e oriente você.

Planejamento e Pesquisa: Mantendo Simples

Olhando para trás, admito que minha fase de planejamento não foi tão meticulosa quanto alguns recomendariam. Não passei meses comparando todos os países ou construindo planilhas detalhadas. Em vez disso, adotei uma abordagem mais direta — alguns diriam até imprudente.

Meus principais critérios eram simples:

Empresas em países desenvolvidos
Patrocínio de visto disponível
Bom equilíbrio entre trabalho e vida pessoal

Com esses filtros em mente, concentrei minha busca de emprego na Europa. Pulei as análises profundas de comparações de custo de vida e caminhos complexos de imigração — pelo menos no início. Minha prioridade era encontrar empresas dispostas a patrocinar meu visto, já que esse era o maior obstáculo para a mudança.

Claro, à medida que comecei a receber respostas de empregadores e aprendi mais sobre o processo, comecei a pesquisar os detalhes — como salários locais, sistema de saúde e como seria a vida em cada cidade. Mas, no começo, deixei meu desejo por uma vida mais segura e equilibrada me guiar, mantendo o planejamento intencionalmente simples para evitar me sentir sobrecarregado.

Olhando para trás, percebo que, embora um plano mais detalhado pudesse ter ajudado, às vezes tomar ação é o passo mais importante. Para quem está pensando em fazer uma mudança semelhante, não deixe o perfeccionismo te impedir de começar. Você sempre pode refinar seu plano ao longo do caminho.

Preparação e Busca de Emprego: Preparando-se e Agindo

Com a Europa como meu alvo e o patrocínio de visto como uma exigência, meu próximo passo foi preparar meus materiais de candidatura e começar a buscar oportunidades.

Atualizando Meu Currículo e Presença Online

Eu sabia que um currículo forte e um perfil no LinkedIn eram cruciais para chamar a atenção dos recrutadores. Atualizei ambos para incluir métricas específicas que demonstravam o impacto do meu trabalho. Em vez de apenas listar responsabilidades, adicionei números e resultados — como melhorias no desempenho de aplicativos, redução de tempo de inatividade ou aumento no engajamento de usuários. Isso ajudou a mostrar aos recrutadores não apenas o que fiz, mas como meu trabalho fez a diferença.

Focando em Empresas que Patrocinam Vistos

Concentrei minha busca de emprego em empresas na Europa que ofereciam patrocínio de visto. Usei quadros de empregos e filtros para identificar essas oportunidades e prestei atenção às avaliações de empresas e ao equilíbrio entre trabalho e vida pessoal.

Começando Antes de Me Sentir Totalmente Preparado

Embora eu não me sentisse 100% preparado para as entrevistas, decidi começar a me candidatar mesmo assim. Sabia que esperar o “momento perfeito” poderia significar perder oportunidades reais. Todas as minhas entrevistas foram em inglês, que não é minha língua materna, então essas primeiras entrevistas se tornaram sessões de prática extremamente valiosas. Elas me ajudaram a ficar confortável falando sobre minha experiência e habilidades em um ambiente profissional — algo que eu não fazia muito antes. Essa experiência aumentou minha confiança e habilidades de comunicação, mesmo enquanto continuava a estudar e melhorar. Reconheço que essa abordagem não funciona para todas as empresas, especialmente aquelas com processos de recrutamento longos ou altamente competitivos. Mas, para mim, agir cedo foi uma forma de aprender fazendo, em vez de esperar até me sentir completamente pronto.

Lidando com Candidaturas e Entrevistas: Aprendendo na Prática

Uma vez que comecei a me candidatar, o processo real começou. Cada candidatura exigia atenção cuidadosa, mas as entrevistas foram onde as coisas ficaram interessantes — e, às vezes, desafiadoras.

O Processo de Candidatura

Sempre que havia a opção de enviar uma carta de apresentação, eu aproveitava para personalizá-la de acordo com os produtos, missão e objetivos da empresa. Aprendi que uma carta de apresentação bem elaborada e personalizada pode fazer uma grande diferença — ela ajuda você a se destacar entre outros candidatos e mostra aos recrutadores que você fez sua lição de casa e está genuinamente interessado em contribuir para o sucesso da empresa.

Experiências em Entrevistas

Todas as minhas entrevistas foram em inglês, o que adicionou uma camada extra de complexidade. Meu inglês estava longe de ser “perfeito”, e às vezes eu não entendia completamente o que o entrevistador dizia. Mesmo assim, consegui me comunicar bem o suficiente para transmitir minhas ideias. Na maioria das vezes, os entrevistadores foram pacientes e compreensivos.

Essa experiência me ensinou que você não precisa esperar até que seu inglês esteja perfeito para começar a fazer entrevistas. O que importa é ser capaz de se expressar com clareza e confiança, mesmo que cometa erros ao longo do caminho.

Enquanto me candidatava, também estudava todos os dias — praticar algoritmos, estruturas de dados, design de sistemas e perguntas comportamentais se tornou parte da minha rotina. Durante as entrevistas, prestei muita atenção à linguagem corporal e às reações dos entrevistadores. Se uma resposta minha não gerava uma reação positiva ou parecia errada, eu considerava isso um feedback indireto. Isso me ajudou a identificar áreas onde precisava melhorar e a focar meus estudos para entrevistas futuras.

Aprendendo com Rejeições

Nem toda entrevista resultou em uma oferta. Houve rejeições, e às vezes o feedback era difícil de ouvir. Mas tentei ver cada uma como uma oportunidade de aprendizado. Prestei atenção às perguntas com as quais tive dificuldade e as usei para guiar minhas sessões de estudo. Com o tempo, fiquei melhor em antecipar o que os entrevistadores queriam e como me apresentar como um candidato forte.

Recebendo uma Oferta e Reflexões

Após semanas de candidaturas, entrevistas e muito estudo, finalmente recebi uma oferta de uma empresa na Europa. Esse momento marcou um marco importante na minha jornada — não apenas porque significava que eu poderia me mudar, mas porque validou todo o esforço e persistência que investi.

A Oferta e o Que Ela Significou

Quando a oferta chegou, senti uma mistura de empolgação e alívio. Depois de tanta incerteza — especialmente como alguém que nunca havia vivido ou trabalhado no exterior antes —, foi reconfortante saber que minhas habilidades e experiência foram reconhecidas. A empresa estava disposta a patrocinar meu visto, o que significava que eu poderia finalmente começar a planejar minha mudança e um novo capítulo para minha família.

Olhando para Trás no Processo

Olhando para trás, percebi o quanto aprendi — não apenas sobre tópicos técnicos, mas sobre mim mesmo e do que sou capaz. Superei barreiras linguísticas, me adaptei a diferentes estilos de entrevista e lidei com rejeições com resiliência. Cada passo, mesmo os mais difíceis, me tornou mais forte e mais preparado para os desafios à frente.

Principais Lições

Aqui estão as lições mais importantes que aprendi ao longo do caminho:

Comece Antes de Estar Pronto: Não espere o “momento perfeito”. Comece a se candidatar e fazer entrevistas o quanto antes — você aprenderá e melhorará com cada experiência.
Personalize Sua Candidatura: Sempre envie uma carta de apresentação personalizada quando possível. Mostre aos recrutadores que você entende a empresa e como pode contribuir.
Use Entrevistas como Prática: Mesmo que esteja nervoso ou seu inglês não seja perfeito, use cada entrevista como uma chance de aprender e crescer.
Preste Atenção ao Feedback: Observe as reações dos entrevistadores e use-as como feedback indireto para guiar seus estudos e preparação.
Permaneça Persistente: Rejeições fazem parte do processo. Aprenda com elas, ajuste sua abordagem e continue.

Este artigo é uma visão geral da minha experiência em conseguir um emprego no exterior. Se você quiser que eu mergulhe mais fundo em alguma parte específica — como estudei, como organizei minhas candidaturas, como gerenciei meu tempo enquanto trabalhava em tempo integral, ou qualquer outro tópico —, por favor, deixe um comentário! Seu feedback me ajudará a decidir no que focar em artigos futuros.

Vamos aprender e crescer juntos!

Chasing a Better Life: How I Landed a Tech Job Abroad

Fabio Hiroki — Tue, 17 Jun 2025 06:28:07 +0000

Have you ever dreamed of relocating to another country-of starting fresh in a new place, with new opportunities and a better quality of life? For software engineers, the prospect of working abroad is both thrilling and intimidating. I know this firsthand.

As a software engineer born and raised in Brazil, I faced challenges that went beyond code. Despite a comfortable salary, daily life was overshadowed by safety concerns-simple acts like using my phone in public or walking home at night felt risky. When I started thinking about raising a family, those worries grew. Then the pandemic hit, amplifying my frustration and pushing me to seek a safer, more stable future abroad.

In this article, I’ll share my journey from planning and preparation to landing my first job offer overseas. From navigating visas to acing interviews, I hope my story inspires and equips you to take your own leap as a software engineer.

Planning and Research: Keeping It Simple

I’ll be honest: my planning phase wasn’t a masterclass in organization. I didn’t spend months comparing countries or building intricate spreadsheets. Instead, I took a straightforward-some might call it reckless-approach to kickstart my relocation journey.

My criteria were clear and simple:

Companies in developed countries
Visa sponsorship available
Good work-life balance

With these filters, I zeroed in on Europe, drawn to its tech hubs like Berlin and Amsterdam, which offered both opportunity and a lifestyle that felt safer and more balanced than Brazil. I skipped deep dives into cost-of-living calculators or immigration policies at first. My focus was finding companies willing to sponsor my visa-a non-negotiable hurdle for relocating.

As I started applying and getting responses from employers, I naturally dug deeper. I researched salaries on platforms like Glassdoor, checked healthcare systems, and even browsed posts from expats to get a feel for life in cities like Munich or Lisbon. But in the beginning, I let my desire for a better life guide me, keeping my planning lean to avoid paralysis by analysis.

Looking back, a more detailed plan might have saved me some surprises-like underestimating rent in European cities. But taking action, even imperfectly, was the key to moving forward. If you’re considering a similar move, don’t let the quest for a perfect plan stop you. Start with a few clear priorities, and refine as you go. Try jotting down your own three must-haves today-what’s driving your relocation dream?

Preparation and Job Search: Getting Ready and Taking Action

With Europe as my target and visa sponsorship as a non-negotiable, I rolled up my sleeves to prepare my application materials and dive into the job search.

Updating My CV and Online Presence

I knew a polished CV and LinkedIn profile were my first steps to catching recruiters’ eyes. I revamped both to focus on impact, not just duties. For example, I highlighted the number of requests that the system I worked had to support. These metrics showed employers what I could deliver.

Targeting Companies That Sponsor Visas

Next, I zeroed in on European companies offering visa sponsorship. I used LinkedIn’s job filters to find roles explicitly mentioning sponsorship and browsed boards like Relocate.me for tech jobs in Europe. I also checked Glassdoor for company reviews to gauge culture and work hours, ensuring I’d land somewhere that aligned with my goal of a balanced life. This targeted approach saved me from wasting time on roles that wouldn’t work.

Starting Before Feeling Fully Prepared

I’ll admit, I didn’t feel 100% ready for interviews, but I started applying anyway. Waiting for the “perfect moment” risked missing real opportunities. Since English isn’t my first language, those early interviews were nerve-wracking but invaluable. Each one helped me get comfortable explaining my experience and skills, like practicing a new codebase in real time. This learn-by-doing approach boosted my confidence, even if it meant a few rejections along the way. I know this strategy won’t suit every company-some have grueling, multi-stage hiring processes-but for me, jumping in early was the key to progress.

What’s one step you could take today to kickstart your own job search?

Handling Applications and Interviews: Learning as I Went

Once I started applying, the relocation process felt real. Crafting applications demanded care, but interviews-especially in a second language-brought both challenges and growth.

The Application Process

For every job with a cover letter option, I seized the chance to stand out. I tailored each letter to the company’s mission or products, like when I connected my work on scalable APIs to a Berlin startup’s focus on seamless user experiences. This showed recruiters I’d done my homework and was eager to contribute. A personalized cover letter isn’t just a formality-it’s your chance to shine.

Interview Experiences

All my interviews were in English, which wasn’t my first language. I sometimes stumbled over technical terms or missed nuances in questions, but most interviewers were patient, giving me space to clarify. Those early calls were like live coding sessions for communication: imperfect but invaluable. I learned you don’t need flawless English to succeed-just clarity and confidence.

To prepare, I made daily study a habit, using LeetCode for algorithms and system design tutorials on YouTube. During interviews, I watched for cues like an interviewer’s nod or hesitation. If an answer fell flat, I noted it and adjusted my prep, focusing on weak spots like system design or explaining past projects concisely.

Learning from Rejections

Not every interview led to an offer. Rejections stung-especially one where I missed one simple JavaScript concept-but I treated them as feedback. I reviewed tough questions, like those on distributed systems, and practiced until I could answer confidently. Each rejection sharpened my skills and taught me to anticipate what employers valued, bringing me closer to my goal of a safer, balanced life in Europe.

What’s one interview question you’re nervous about? Try practicing it today!

Receiving an Offer and Reflections

After weeks of applications, interviews, and relentless studying, I received an offer from a fintech startup in Amsterdam. That moment was electric-a mix of excitement, relief, and pride. It wasn’t just a job; it was the key to a safer, more balanced life for my family.

The Offer and What It Meant

The email confirming the offer felt surreal. As someone who’d never worked abroad, knowing a European company valued my skills and would sponsor my visa was a game-changer. It meant I could finally plan my move, envisioning a future where my family could thrive without the daily safety concerns I faced in Brazil.

Looking Back on the Process

As I celebrated, I reflected on how far I’d come. Beyond mastering algorithms and system design, I’d grown as a person-pushing through language barriers, adapting to tough interview questions, and bouncing back from rejections. Each step, even the painful ones, built my confidence and prepared me for the challenges of relocating.

Key Takeaways

Here’s what I’d tell anyone chasing a job abroad:

Start Before You’re Ready - Apply early, even if you’re nervous. My first shaky interview taught me to clarify questions upfront.
Tailor Your Application - Craft cover letters that tie your skills to the company’s mission, like linking my API work to a startup’s goals.
Use Interviews as Practice - Don’t let imperfect English stop you. Each call hones your communication, as I learned after stumbling through technical terms.
Learn from Feedback - If an interviewer seems unimpressed, adjust. One rejection showed me I needed to brush up on distributed systems.
Stay Persistent - Rejections hurt, but they’re progress. Each “no” refined my approach until I landed the offer.

This article is an overview of my experience getting a job abroad. If you’d like me to dive deeper into any specific part-such as how I studied, how I tracked my applications, how I organized my time while working full-time, or any other topic-please leave a comment! Your feedback will help me decide what to focus on in future articles.

Your dream job abroad is within reach-start today!

You Are Not Your Job: Reclaiming Your Identity as a Software Engineer

Fabio Hiroki — Thu, 29 May 2025 15:26:33 +0000

Who are you? If your first instinct is to say, “I’m a software engineer” or “I’m a developer,” I invite you to pause for a moment and dig a little deeper.

That’s exactly where I found myself after graduating from university and landing my first job. For years, my goal was clear: get a degree, start a career. It felt like the default path — everyone around me was on it, and society cheered it on. But when I stepped into the working world as a software engineer, I felt unexpectedly lost. Without the structure of school or passions outside of work, I poured everything into my job. The long hours debugging code, learning new frameworks, and chasing deadlines became my identity. Climbing the career ladder seemed like the natural next step — after all, it’s what my parents did, and it’s what the tech world demanded. What could possibly go wrong?

As it turned out, letting my job define me left me unfulfilled, disconnected from who I was outside of code, and questioning my purpose. This article is about my journey to reclaim my identity beyond my job title — and how you, too, can rediscover who you are outside the world of software engineering.

The Hidden Danger of Defining Yourself by Your Job

It’s shockingly easy to let your job title become your identity, especially in software engineering. The tech industry thrives on celebrating promotions, shipped features, and GitHub commits as if they measure your worth as a person. Society piles on, too — say you work for a big-name tech company at a party or on X, and suddenly you’re “impressive.” I internalized that prestige, believing my value was tied to the company name on my LinkedIn profile.

Early in my career, every bug I couldn’t crack or deadline I missed felt like a personal failure. I wasn’t just a software engineer who messed up — I was a failure. The pressure to prove myself, to keep up with new frameworks and maintain a “rockstar coder” image, was relentless. It took a toll on my mental health, leaving me exhausted and questioning my worth.

Since my job was my only sense of purpose, I lost myself in it. I worked late nights, not out of passion but obligation, and spent weekends studying system design or tweaking side projects. Why not? My job gave my life meaning, so every moment had to serve it. I also craved validation from my manager and colleagues. Positive feedback was proof I was enough, but without it, I felt invisible. Negative feedback? That was worse — it felt like an attack on my very self, sparking shame and self-doubt.

For a while, this mindset seemed to work. I was productive, earning promotions and delivering projects that won praise. But a few years in, despite climbing the career ladder, the cracks appeared. I grew demotivated, procrastinating on tasks I once loved. My energy tanked, and a quiet depression crept in. If my job was my reason for living, and it no longer sparked joy, what was left? That question was my wake-up call, pushing me to search for meaning beyond my role as a software engineer.

Have you ever felt like a mistake at work was a reflection of your value as a person?

Recognizing the Need for Change

The Moment of Realization

After a grueling week of chasing deadlines and obsessing over a bug I couldn’t fix, I stumbled across stoic philosophy through Marcus Aurelius’ Meditations. Its core idea hit hard: life is short, and no one will remember my commits or pull requests centuries from now. This truth was humbling yet liberating. Why was I pouring so much energy into feeding my ego through work, chasing likes on my LinkedIn profile or praise from my manager?

Stoicism taught me I didn’t need to “make a dent in the universe,” as tech culture often demands. I couldn’t control if people accepted me or not, but I could control how I defined my worth. Letting go of the pressure to leave a grand legacy through my job freed me to focus on what truly mattered — my health, my relationships, and finding joy outside my role as a software engineer. This shift in mindset was just the beginning, pushing me to explore ways to live for myself, not my job title.

Initial Struggles

Shifting away from a work-centric identity was tougher than I expected. Most of my friends, fellow software engineers, lived for their jobs — side projects and open-source commits were their badges of honor. For them, work was life, and conversations rarely strayed from tech trends or career wins. When I started prioritizing balance, they noticed. A friend even asked why I’d stopped grinding on side projects, hinting I was “slacking.” Stoicism helped me shrug off their nudges to conform — I couldn’t control their opinions, only my choices.

Redefining myself outside my job was scarier. If I wasn’t the coder chasing promotions, who was I? Evenings felt empty without Jira tickets or system design books. I felt lost, like I was rebuilding my identity from scratch. It was uncomfortable, but each small step — saying no to after-hours Slack or trying a new hobby — brought me closer to a life aligned with my true values.

What is your number one priority in life right now? Have you intentionally defined it?

First Steps Toward Change

To break free from my work-obsessed routine, I started practicing sports — a simple way to escape the sedentary tech life and move my body. Stoicism taught me to focus on effort, not outcomes, so I didn’t pressure myself to be “good.” It was just a hobby to fill the hours I’d once spent debugging code past midnight.

Weeks in, I found myself loving it. Each small improvement — running a bit farther, feeling stronger — brought a satisfaction unrelated to commits or promotions. This sense of progress, built through my own effort, was deeply rewarding. Running became a passion, waking me up with excitement for the next trail, not just the next sprint. Work remained important, but it no longer defined my days. Ironically, this new energy made coding feel less like a burden, letting me approach my job with a clearer, healthier mindset. Sports was just the start — other steps soon helped me build a fuller life beyond my job.

If you couldn’t use your job title to describe yourself, what would you say?

A New Identity

Stepping back from defining myself by my job opened the door to rediscovering who I am. I’m no longer just a software engineer or a title on my LinkedIn profile. Guided by stoic principles to focus on what I can control, I prioritize health, relationships, and personal growth.

I still find joy in programming — getting “in the zone,” squashing a tricky bug, or streamlining a workflow reminds me why I entered tech. But balance lets me tackle work with calm focus, not anxiety, making work more fulfilling. Sharing my story, as you’ve noticed, fuels my passion for helping others grow as humans, not just coders. I’ve learned personal growth drives professional success.

Sports remains my stress reset, clearing my mind and sparking joy. Work is now just one part of a richer life, supporting my passions rather than defining me. I hope my journey inspires you to explore who you are beyond your job title.

Key Takeaways and Action Points

Reflecting on my journey, I’ve learned that your job is just one part of who you are-not the whole story. When you tie your identity too closely to work, it’s easy to lose balance, feel burnt out, and question your self-worth. But it’s possible to redefine your relationship with work and reclaim your sense of self.

Here are some key takeaways and practical steps you can start with today:

Key Takeaways

You are more than your job title. Your worth isn’t measured by your role, your productivity, or your achievements at work.
External validation is natural but limited. While positive feedback feels good, don’t let it define your self-esteem.
Burnout often stems from blurred boundaries. When work becomes your identity, setbacks hit harder and recovery takes longer.
Meaningful fulfillment comes from balance. Investing in hobbies, relationships, and self-care fuels motivation and joy beyond the office.

Action Points

Set boundaries. Create clear limits between work and personal time to protect your mental space. Turn off Slack notifications after work hours to protect your evenings.
Explore new interests. Try a hobby, sport, or creative activity that excites you without the pressure to “perform.”
Seek intrinsic motivation. Focus on activities that bring joy and growth, not just external rewards or recognition.
Build a support system. Surround yourself with people who value you for who you are, not just what you do.
Practice self-compassion. Be kind to yourself when things don’t go perfectly-your value isn’t tied to flawless performance. Forgive yourself for bugs or missed deadlines — your worth is deeper.

Reclaiming your identity takes courage and time, but it leads to a healthier, happier life.

If you enjoyed this article, please click the ❤️. Your feedback helps me understand what topics resonate with you and guides me on what to write next. Thank you for being part of this journey!

Subscribe to my newsletter for more actionable advice to help you grow as a senior engineer — don’t miss out!

Facing my performance anxiety

Fabio Hiroki — Wed, 23 Oct 2024 20:03:55 +0000

Have you ever felt your heart race and your voice falter just when you needed to speak up?

As a software developer, I always thought my biggest challenges would be technical. Little did I know that my greatest obstacle would be the simple act of communication. I was gripped by an intense fear of judgment in meetings, one-on-ones, and workplace interactions. “Everyone struggles a bit, so I should be okay,” I’d tell myself, trying to normalize the anxiety that was slowly consuming my professional and personal life.

The First Signs

My body betrayed me at every turn. My heart would race, breathing became difficult, and an overwhelming sense of stress and anxiety would wash over me. The most frustrating symptom was the feeling that my voice was stuck in my throat, making it nearly impossible to speak up.

The anxiety didn't end when meetings did. I'd lie awake at night, replaying every conversation in my head. "Why did I say that during the meeting? They must think I'm so incompetent now," I'd berate myself, tossing and turning.

Facing the Facts

I took multiple performance reviews and candid feedback to grasp the true cost of my silence fully. Each critique served as a mirror, reflecting how my communication struggles were hindering my progress. I began to see that my inability to articulate ideas was not just a personal hurdle; it was a barrier to career advancement and promotions.

One particular feedback session with my manager stands out vividly in my memory. "Your technical skills are meeting our expectations," he said, "but given your expertise, you should be contributing more." He went on to explain that I needed to actively participate in the team's architectural discussions and confidently challenge technical decisions when I disagreed.

This moment of realization was pivotal. It was as if a light had been switched on, illuminating the path I needed to take. I understood that if I wanted to grow in my career and personal life, I had to confront these challenges head-on. This revelation became the catalyst for change, pushing me to take action and seek solutions to improve my communication skills.

Taking the First Step

Acknowledging that I needed to improve was still challenging. As someone with performance anxiety, any hint of a skill that wasn't perfect felt like admitting complete failure. The mere thought of addressing my communication issues sent painful signals through my brain, urging me to retreat.

Despite these internal alarms, I made a crucial decision: to ignore the discomfort and move forward. I knew that progress would come one step at a time, and I had to start somewhere

Initially, I misdiagnosed my problem as a simple communication issue. I dove into books on public speaking and attended in-person courses, learning how to structure engaging presentations. While these skills were valuable, they didn't address the root of my anxiety

Exposure Therapy: A Turning Point

I decided to challenge myself by giving technical presentations at work, starting with my team. Those first presentations were nerve-wracking, with anxiety building weeks in advance. But I had an unexpected ally: my colleagues. Their support during dry runs and their constructive feedback became my lifeline.

The Big Test

Emboldened by my progress, I set my sights on a larger goal: presenting to the engineers of the entire department. I spent over a week preparing, refining my slides, and conducting mental dry runs. The preparation was intense, but it paid off.

The positive feedback I received from engineers across different teams was validating. This experience marked a turning point in my journey. Now, I even feel excited when I have to do public presentations. What once felt like a daunting task has transformed into something more enjoyable, albeit still challenging. The thrill of sharing my ideas and engaging with my audience adds a new dimension to the experience.

While I still feel nervous during presentations, it's at a manageable level—I no longer feel like I'm "dying" on stage. Instead, I embrace the challenge as an opportunity for growth and connection. Now, I approach presentation opportunities with confidence, looking forward to each chance to share my knowledge and ideas.

However, this victory was just the beginning. While I had conquered formal presentations, I realized that the root cause of my performance anxiety remained unaddressed. I still struggled in spontaneous situations, like team discussions about system design architecture, where there was no time to prepare.

Key Takeaways

Looking back on my journey, I've learned some valuable lessons that I'd like to share with you:

The Power of Preparation: Thorough preparation for formal presentations is crucial. It not only helps engage your audience but also significantly boosts your confidence. Don't underestimate the impact of being well-prepared – it can be a game-changer in managing your anxiety.
Beyond Formal Presentations: While mastering prepared speeches is an important step, it's not the entire solution to conquering performance anxiety. The real challenge often lies in impromptu situations where you can't script your responses.
Continuous Growth: Overcoming anxiety is an ongoing process. Each presentation, each meeting, is an opportunity to learn and improve. Embrace these chances for growth, even when they feel uncomfortable.
The Deeper Work: Addressing the root cause of performance anxiety often requires more than just improving presentation skills. It may involve working on self-confidence, challenging negative thought patterns, or seeking professional help.

Remember, while preparation is key for formal presentations, it's just one piece of the puzzle in overcoming performance anxiety. The journey to true confidence in all professional interactions is a longer, more nuanced path – one that we'll explore further in upcoming articles.

If you're interested in learning more about overcoming anxiety in the tech workplace and fostering mindfulness in your career, I invite you to subscribe to the newsletter.

Photo by Wan San Yip on Unsplash
Photo by the blowup on Unsplash

Are You Feeling Overwhelmed? Recognizing Signs of Strain in Tech

Fabio Hiroki — Tue, 08 Oct 2024 07:00:03 +0000

In our fast-paced lives, distinguishing between typical stress and deeper mental struggles can be challenging. Often, we dismiss our feelings as mere reactions to everyday pressures, failing to recognize the underlying issues that can silently affect our well-being. These struggles may not always present themselves in obvious ways; instead, they can manifest subtly, leading us to believe that we are simply experiencing normal circumstances.

To illustrate this complexity, we will explore the fictional story of Alex, a new software engineer. Through his journey, we will uncover how seemingly ordinary stress can evolve into significant mental health challenges that impact both personal and professional life.

Meet Alex: The New Software Engineer

Alex had just landed his first job as a software engineer at an innovative tech startup. While he felt a rush of excitement, that thrill was quickly overshadowed by an overwhelming sense of anxiety.

Drowning in a Sea of New Information

From day one, Alex found himself inundated with an enormous amount of new information. The codebase was vastly more complex than anything he had encountered in his studies or internships. Team meetings were filled with unfamiliar jargon and technical discussions that seemed to flow effortlessly among his colleagues.

As the days passed, Alex's initial excitement gave way to a growing sense of self-doubt. He struggled to keep up with the rapid pace of learning required for his role. "How can I possibly learn all of this?" he wondered, feeling the weight of expectation on his shoulders.

Alex couldn't shake the nagging feeling that he was falling behind. He began to question whether he was truly cut out for the job. "What if they realize I don't know as much as they thought I did when they hired me?" This thought plagued him, leading to sleepless nights and increased anxiety. Even when Alex completed tasks, he attributed his accomplishments to luck rather than skill.

The Silent Struggle

As Alex's self-doubt grew, he began to take drastic measures to prove his worth. He started working overtime. Weekends, once a time for relaxation and recharging, became extensions of his workweek. Alex convinced himself that if he put in more hours, he could catch up to his colleagues and prove his value to the company.

This self-imposed overtime became Alex's coping mechanism. He reasoned that he could compensate for what he perceived as a lack of skill or knowledge by working longer hours. "If I just put in more time," he thought, "I'll eventually get to where I need to be."

Emotional Exhaustion

As weeks turned into months, Alex's coping strategy began to backfire. The constant overtime and pressure he put on himself led to exhaustion. He found it increasingly difficult to engage with his work and colleagues.

During a project meeting, the team celebrated a successful milestone, and while everyone around him was excited, Alex felt detached. Instead of sharing in the joy, he thought, “They’re celebrating, but I’m just trying to keep my head above water.” This feeling of isolation intensified his stress.

In addition to emotional strain, Alex began experiencing physical symptoms. Fatigue became a constant companion, leaving him drained even after long work hours. He would find himself struggling to stay awake during meetings and needing an excessive amount of coffee just to get through the day. “If I just drink one more cup,” he thought, “I’ll be able to power through.”

Conclusion: Reflecting on Our Journeys

As we conclude Alex's journey, it's crucial to recognize that his experience isn't unique. Many of us navigate similar challenges in our careers, often in silence. The software engineering field, with its rapid pace and constant innovation, can be particularly demanding on mental health

How often do we find ourselves overwhelmed by expectations, questioning our abilities, or feeling isolated despite being surrounded by colleagues?

Recognizing these struggles is the first step toward addressing them. Remember, you’re not alone—many share these experiences.

In future articles, we'll explore practical solutions and strategies to help support mental health and foster resilience in the workplace. We'll delve into topics such as managing impostor syndrome, preventing burnout, and creating a supportive work culture prioritizing mental well-being.

If you want to learn more about navigating these challenges and fostering a healthier work environment, I invite you to subscribe to my newsletter. Together, we can work towards understanding, growth, and a more supportive tech industry.

Let's break the silence around mental health in tech. Your story matters, and your well-being is crucial. Join me on this journey towards a more open, supportive, and mentally healthy workplace.

Photo by Vitaly Gariev on Unsplash