This time, let's look at a specific use case: building a customer-facing MCP server.

If your goal is to allow customers to interact with your product through AI clients such as Claude, ChatGPT, Cursor, or Claude Code, what do you actually need?

The good news is that if you already have APIs or services, you're often closer than you think.

The Essentials

If you're building a first version, I'd focus on these first.

1. Existing Functionality to Expose

Most MCP servers sit on top of functionality that already exists.

That functionality might come from:

• REST APIs

• GraphQL APIs

• Databases

• Internal services

The MCP server becomes a layer that exposes that functionality to AI agents.

One thing you'll quickly discover is that not every API endpoint necessarily deserves to become a tool.

The goal isn't to mirror your API one-to-one. Instead, think in terms of capabilities that would be useful to an AI assistant.

For example, instead of exposing:

GET /projects
GET /projects/{id}
POST /projects/{id}/tickets

You might expose higher-level tools such as:

search_projects
create_ticket

The MCP server can orchestrate one or multiple API calls behind the scenes. What matters is not how your API is structured internally, but what actions are useful for the AI assistant to expose to the user.

One thing that surprised me was how capable modern AI clients are once they have access to well-defined tools.

My initial instinct was to think through every possible workflow a user might need. In practice, I found that the AI client could often orchestrate much of that on its own.

For example, imagine an MCP server exposes:

• search_projects

• create_ticket

• get_ticket_status

A user might ask:

Create a ticket for the login issue in the Mobile App project and let me know when it's done.

The AI client can determine which tools to invoke, chain multiple calls together, provide the appropriate inputs, and even check back for updates if the workflow requires it.

This changed how I thought about tool design. Rather than exposing a tool for every workflow, I found it more useful to expose clear capabilities with good names and descriptions, allowing the AI client to orchestrate them as needed.

2. An MCP SDK

The easiest way to get started is with an MCP SDK.

SDKs are available for several languages, including:

• TypeScript

• Python

• Java

The SDK handles much of the underlying protocol and transport details, allowing you to focus on defining the tools, resources, and prompts you want to expose.

3. Choose a Transport

One of the first architectural decisions is how clients will communicate with your MCP server.

The two most common options are:

• stdio

• HTTP

For my first implementation, I started with stdio.

It was a great way to get a prototype working quickly and test the integration in my local development environment. Since the MCP client launches the server as a local process, getting started was relatively straightforward.

Within a short time, I had my existing APIs connected to Claude and was able to interact with them conversationally. Instead of manually calling endpoints or testing requests, I could simply ask Claude to perform actions using the tools exposed by my MCP server.

It didn't take long, however, to realize that our end goal wasn't a local integration—it was allowing multiple customers to connect to the same MCP server. At that point, an HTTP-based server became the more appropriate choice.

If your goal is simply to get a feel for MCP and validate an integration quickly, starting with stdio can be a good option. It lets you connect your APIs to an AI client with minimal setup and experiment locally.

However, if you already know you'll need a hosted, multi-user solution, you may prefer to go straight to an HTTP-based server.

4. Decide What to Expose

One of the most important design decisions is deciding what functionality should be available to AI agents.

A common mistake is trying to expose everything.

For a first version, focus on the handful of actions that provide the most value.

Ask yourself:

If a customer connected this MCP server today, what are the top five things they would want an AI assistant to do?

Start there.

You can always expose additional functionality later.

5. Decide How Users Will Authenticate

If your MCP server exposes customer data or performs actions on behalf of users, you'll need a way to authenticate them.

Authentication becomes especially important once multiple customers start connecting to the same MCP server.

The AI assistant isn't acting on its own behalf—it is acting on behalf of a specific user.

That means the MCP server needs a way to identify who the user is and what data they are allowed to access.

Common approaches include:

• API Keys

• OAuth

We'll explore authentication in more detail in a future article.

Start With the Smallest Useful Integration

One thing I found useful was focusing on getting a single end-to-end workflow working first.

For example:

1. Connect an MCP client to the server.

2. Authenticate a user.

3. Expose a small set of useful tools.

4. Successfully invoke those tools from the AI assistant.

Once that foundation is working, it's much easier to iterate.

You can always add more tools, resources, prompts, richer authentication flows, and additional transports later.

In my experience, the challenge isn't usually exposing another tool. It's making sure the entire flow works smoothly—from connecting the client, to authenticating the user, to successfully invoking functionality in your application.

Nice-to-Haves That Improve the Experience

Once you have a working integration, there are several things that can make your MCP server even more effective.

6. Provide Context

One thing I didn't fully appreciate at first is that exposing tools is only part of the solution.

The AI also needs context to understand how those tools should be used.

For example, in one implementation, the underlying application stored dates and times in a specific timezone, while users interacted with the AI in their own local timezone.

Providing that context allowed the AI to perform the appropriate conversions before invoking tools or presenting results.

I found this particularly powerful because it allowed the AI to adapt its behavior without requiring additional tools or changes to the underlying APIs to accommodate every possible use case.

In many cases, if the AI seems to be making poor decisions, the missing piece isn't another capability—it's additional context.

7. Consider Resources and Prompts

Many MCP servers start with tools, but the protocol also supports resources and prompts.

Resources can provide additional context, such as product documentation, while prompts can expose reusable instructions or workflows.

These aren't always necessary for a first version, but they can be valuable additions as your MCP server evolves.

8. Document How to Use It

Even with a standardized protocol, documentation still matters.

Users need to know:

• What your MCP server does

• How to install it

• How to authenticate

• Which AI tools support it

Good documentation often makes the difference between an MCP server that gets adopted and one that doesn't.

Conclusion

One thing I learned is that a lot of MCP server design decisions become clearer through testing and real usage.

As you try different scenarios, you'll quickly discover whether:

• The agent is missing important context.

• A tool is missing.

• Two tools should be combined.

• A description needs to be clearer.

• Additional resources would help.

I was also surprised by how capable modern AI clients are once they have access to well-defined tools. They can often chain multiple calls together, provide the appropriate inputs, and orchestrate workflows that I initially thought would require dedicated tools.

The best way to understand what your MCP server needs isn't to design every possible workflow upfront—it's to start with a small but useful integration and observe how the AI client uses it in practice.

Over time, those interactions will tell you where the gaps are and how the server should evolve.

But what actually happens when an AI assistant uses an MCP server?

You don't need to understand every detail of the protocol to understand MCP. A simple mental model is enough.

The Big Picture

MCP Client (Claude, Cursor, ChatGPT, etc.)
                    │
                    ▼
               MCP Server
                    │
                    ▼
              Your Application

The MCP client is usually an AI application such as Claude, Cursor, ChatGPT, or Claude Code.

The MCP server sits between the AI assistant and your application. Its job is to expose information and functionality that the AI can discover and use.

You can think of it as another layer of abstraction between the AI client and your application's underlying APIs or services.

Claude
   │
   ▼
MCP Server
   │
   ▼
Your APIs / Services

But where does the MCP server come from?

Someone has to build it.

In many cases, the company behind the product provides an official MCP server. For example, GitHub, Linear, and other companies now offer MCP servers that expose functionality from their platforms to AI assistants.

If your company wants AI agents to interact with its products, your team would typically build and host an MCP server that AI clients can connect to.

Much like a REST API allows developers to interact with your application, an MCP server allows AI agents to interact with it.

What Does an MCP Server Expose?

At a high level, an MCP server can expose three types of things:

MCP Server
│
├── Tools
├── Resources
└── Prompts

Tools

Tools are actions the AI can perform.

Examples:

create_ticket
search_issues
send_message

When you ask Claude to create a Linear ticket, it is typically invoking a tool exposed by the Linear MCP server.

Resources

Resources are information the AI can read and use as context.

For example, imagine your company exposes its product documentation as a resource. An AI assistant could retrieve that documentation to answer questions or better understand how to use your product before invoking any tools.

A simple way to think about it:

• Tools → the AI wants to do something

• Resources → the AI wants to know something

Prompts

Prompts are reusable instructions exposed by the MCP server.

For example, a company might provide prompts such as:

• Summarize a project

• Review code changes

• Explain an error message

Rather than requiring every client to define these instructions, they can be exposed directly by the MCP server.

A simple way to think about it:

• Tools → the AI wants to do something

• Resources → the AI wants to know something

• Prompts → the AI wants guidance on how to do it

How Does the AI Know What's Available?

Before an AI assistant can use a tool, it first needs to discover what the MCP server provides.

A simplified version of that conversation looks like this:

Client
  │
  ├── initialize
  │
  ├── tools/list
  │
  ├── resources/list
  │
  └── prompts/list

Think of it as the AI asking:

What can you do?

The server responds with the tools, resources, and prompts it makes available.

How Do Clients and Servers Communicate?

All interactions between an MCP client and an MCP server happen through messages.

MCP standardizes these interactions using JSON-RPC, a lightweight protocol for request and response communication.

Those messages travel through a transport layer. MCP supports transports such as stdio and HTTP, which determine how the client and server communicate with each other.

Most developers interact with MCP through SDKs, which handle much of the underlying protocol and transport details for you. This allows developers to focus on the functionality they want to expose rather than the mechanics of the protocol itself.

What Happens When a Tool Is Used?

Let's say you ask Claude:

Create a Linear ticket for a login bug.

The flow looks something like this:

User
 │
 ▼
"Create a Linear ticket"
 │
 ▼
Claude
 │
 ▼
tools/call(create_ticket)
 │
 ▼
Linear MCP Server
 │
 ▼
Linear

Claude invokes the appropriate tool, the MCP server performs the operation, and the result is returned back to Claude.

Bringing It All Together

           MCP Client
      (Claude, Cursor, etc.)
                   │
                   ▼
             MCP Server
        ┌──────┼──────┐
        ▼      ▼      ▼
      Tools Resources Prompts
                   │
                   ▼
      APIs / Databases / Services

The client discovers what the server exposes and uses tools, resources, or prompts as needed.

That's the core mental model behind MCP.

In the next article, we'll look at what you actually need to build your own MCP server.

After shipping the first version, I started noticing MCP everywhere. GitHub has one. Linear has one. Slack, Notion, databases, browser automation tools—the list keeps growing. It seems like every week another company is making their functionalities available through MCP.

So what exactly is MCP?

What Is MCP?

MCP (Model Context Protocol) is a lightweight standard that allows AI agents to discover and use the actions an application makes available, such as creating a ticket, searching for issues, retrieving customer data, or updating a record.

Many companies already expose this functionality —often referred to as capabilities— through REST or GraphQL APIs. The challenge is not that the functionality doesn't exist—it's that every API exposes it differently. MCP provides a standard way for AI agents to discover what's available, understand how to invoke it, and interact with it consistently.

REST APIs are typically designed for developers. MCP servers are designed for AI agents.

How Does It Work?

A typical setup looks something like this:

AI Assistant
      ↓
  MCP Server
      ↓
 REST / GraphQL API
      ↓
 Application

The MCP server exposes information and functionality that the AI assistant can discover and use.

When a user asks the assistant to perform an action or retrieve information, the assistant can interact with the underlying application through the MCP server.

MCP Usage in Practice

Many popular products now provide official MCP integrations, including:

• GitHub

• Linear

• Slack

• Notion

• Stripe

• Browser automation tools

Let's look at a concrete example using the Linear MCP with Claude Code.

Step 1: Install the Linear MCP

claude mcp add linear

Or simply ask Claude:

Install the Linear MCP for me.

Claude will guide you through the installation and authentication process.

Step 2: Use It

Once connected, you can ask things like:

View your open issues

What are my open Linear issues?

Create a ticket

Create a high-priority bug ticket for users being logged out unexpectedly.

Search sprint work

Show me all issues assigned to me this sprint.

From the user's perspective, it feels like a conversation.

For example, when you ask Claude to create a Linear ticket, Claude sends the request to the Linear MCP server. The MCP server exposes actions such as creating tickets or searching issues and knows how to translate those requests into operations in Linear.

##If AI agents can already use APIs, why do we need MCP?

AI agents can interact with REST and GraphQL APIs directly, so MCP isn't solving a technical limitation.

The value of MCP is that it gives AI agents a predictable way to discover what an application can do and how to use it.

For example, an AI assistant could be connected to GitHub, Linear, Slack, and dozens of other tools. Without a common standard, each integration would expose its functionality differently. MCP provides a consistent way for AI agents to discover available actions and interact with those systems.

Why Developers Should Care

MCP is quickly becoming one of the standard ways companies expose their products to AI agents. If your company provides APIs, there's a good chance you'll encounter MCP as organizations look for ways to make their products accessible to AI-powered tools and workflows.

Even if you're not building MCP servers yourself, you can benefit from the growing ecosystem of MCP integrations. By connecting AI assistants to tools you already use—such as GitHub, Linear, Slack, or Notion—you can automate repetitive tasks, retrieve information more easily, and streamline everyday workflows.

Whether you're building products or simply using them, MCP is becoming an increasingly important part of how AI systems interact with software.

I was working on a feature when we realized there was a bug fix that needed to happen first because it was a prerequisite.

And that’s when worktrees clicked for me.

So… what is a Git worktree?

A Git worktree lets you have multiple working directories of the same repository on your computer, each checked out to a different branch.

Instead of constantly switching branches in one folder, you can have something like this:

/my-app-main
/my-app-feature
/my-app-bugfix

All connected to the same Git repository — but each on a different branch.

Without worktrees

Imagine you’re halfway through building a feature:

git checkout feature/new-reporting

Then you realize a bug fix must happen first because it’s blocking the feature.

Normally, the flow might look something like this:

git stash
git checkout main
git pull
git checkout -b fix/auth-token

Fix the bug, push it, merge it… then come back:

git checkout feature/new-reporting
git stash pop

Totally workable.

But there’s friction.

You interrupt your flow, mentally bookmark where you were, and juggle branch switching, stashes, and working state.

With worktrees

Instead, you can keep your feature exactly where it is and create a separate working directory for the bug fix.

From your repo:

git worktree add ../my-app-bugfix -b fix/auth-token main

Now you have:

/my-app-feature   → feature/new-reporting
/my-app-bugfix    → fix/auth-token

You can literally open both folders side by side.

Your feature stays untouched while you work on the prerequisite bug fix. When the fix is merged, you can update your feature branch and continue.

You’re still context switching.

But it feels much more graceful.

Especially with coding assistants, I’ve found this surprisingly helpful.

It makes parallel threads of work feel much more natural.

For example, I might be actively building a feature in one worktree while a separate Claude session works on a prerequisite bug fix in another — all within the same repository, but isolated from each other.

Or I might spin up a temporary worktree for an experiment without disrupting the work already in progress.

You’re still coordinating and context switching, but the friction feels much lower.

A small practice that seems helpful

It could be helfpul s keep a default worktree always synced with main, something like:

/my-app-main      → always synced with main
/my-app-feature   → current feature
/my-app-hotfix    → urgent fix

That way, creating new branches or experiments feels lightweight and you always have a clean starting point.

It’s one of those Git features I wish I had tried earlier.

Sharing in case it’s useful for someone else too.

Claude Code has quickly become one of the go-to coding assistants for many developers and teams. I’ve been using it as part of my day-to-day workflow, and over time I’ve noticed that it hasn’t just changed how I code, but also how I approach building software.

This is not meant to be a set of best practices or anything definitive—just a collection of things that have genuinely helped me so far, in case they’re useful to someone else as well.

I’ve found my way of working with it gradually shifting:

• from using it for isolated tasks

• to being more intentional about planning and context

• to using it for refinement and quality improvements

• and finally toward thinking more automation-first in general

1. Getting comfortable with sessions and keeping context

One of the first things that made a difference for me was just getting comfortable with how sessions work, and how to recover or continue work without losing context.

/login helps you recover without losing context

If you ever need to switch accounts or your session expires, you can use:

/login

This lets you reauthenticate without losing your current context.

Useful when:

• switching subscriptions or accounts

• dealing with expired sessions

• recovering access without restarting your work

Small thing, but I’ve found it helps maintain flow.

claude --resume is a safety net (with one catch)

Another thing that has been really helpful is being able to resume sessions.

You can use:

claude --resume

to return to a previous session.

This has been especially useful when things go wrong:

• accidental terminal closes

• machine restarts

• terminal freezes (this has happened to me more than a handful of times)

It’s also useful when working on different things and wanting to keep contexts separated across sessions.

One thing I didn’t realize at first:

--resume is scoped per directory.

If you’re not in the same directory where you started the session, you won’t see it. I learned this empirically after thinking I had lost everything—when I was just in the wrong folder.

/btw helps you keep momentum

More recently, I’ve also found /btw useful.

It lets you ask questions or leave comments without interrupting the current work.

Instead of breaking the flow of a task, you can surface clarifications while the assistant continues working.

It’s a small thing, but it helps keep iteration smooth.

There are many other commands and I haven’t explored most of them yet, but I’m curious to keep discovering more over time.

2. Learning to guide the assistant better

Plan before implementing

I’ve found it works much better to align on a plan before jumping into implementation.

Before coding, I usually ask Claude to outline:

• the approach

• the scope

• the main steps

This tends to lead to more predictable outcomes and fewer surprises later.

Otherwise, you risk getting code that technically works but doesn’t match how you actually wanted things to be structured or behave.

Provide the right context, not more context

Coding assistants have gotten really good—but the outcome is still very tied to the input.

When it makes sense, I try to include things like:

• ticket context (title + description)

• PRDs or specs

• related PRs or discussions

• incident reports

• logs or traces

• specific files or references

The goal is to help build the right context around the problem.

That said, this is very dependent on what you’re building. For simpler tasks, you don’t need much input to get a correct implementation.

But as things get more complex, the difference becomes obvious.

It’s not about adding more input—it’s about adding the right input.

I like to think of it as getting an incident report with no repro steps or logs—you’d be lost. And the same applies to the agent.

Challenge limitations instead of accepting them

Sometimes the agent will say it can’t do something and suggest doing it manually in another terminal.

In those cases, I don’t always take that at face value.

There have been situations where:

• it actually can do it within the current context

• it has done similar things before

• or the limitation isn’t entirely clear

So instead, I try to push a bit:

• “Can you try doing this directly?”

• “What exactly is preventing you from doing it here?”

Not in a forceful way, but just to better understand what’s going on and avoid unnecessary manual work when possible.

Use Claude for refinement, not just implementation

Another part of how I use Claude is not just to build things, but to refine and improve them.

This can include:

• system architecture

• code structure and conventions

• testing strategy

• performance considerations

• maintainability and scalability

• security and documentation

These are all things I used to think through more manually, and now I find it helpful to involve the agent in that process as well.

It doesn’t replace thinking, but it helps get to a more polished result faster.

Preferences help, but don’t always persist

Another thing I do is ask the agent to keep certain preferences in mind.

This might include:

• coding style

• architectural choices

• naming conventions

• testing expectations

It can help reduce repetition and keep things more aligned with how I like to work.

That said, it’s not perfect. It doesn’t always remember or apply these consistently across sessions, so I do find myself repeating things.

I do think this is an area where things can improve, and I’m curious to explore better ways of handling this over time.

3. Shifting toward automation-first thinking

One of the bigger shifts for me has been moving away from doing things manually by default.

Now I tend to delegate a lot of repetitive or operational work to the assistant:

• creating feature branches

• opening pull requests

• drafting documents

• running repetitive git tasks

• setting up GitHub workflows

And more generally, it’s changed how I think about work.

Now when I see something manual, my first thought is:

can this be automated?

Sometimes that leads to:

• writing a small shell script

• creating aliases

• setting environment variables

• or adding a GitHub workflow to handle it

Individually these are small improvements, but over time they reduce a lot of friction.

4. Using different tools depending on the stage of work

Another thing I do sometimes is use non-coding agents, like ChatGPT, for earlier stages of thinking before switching to Claude for implementation.

This has been especially useful for:

• brainstorming ideas

• light planning

• product and UX thinking

• system architecture design

Not all work starts with code. Some of it benefits from a more open-ended space before getting into implementation details.

Once things feel clearer, I then move into Claude to actually build, refine, and execute.

It’s a simple separation, but I’ve found it helps me keep better structure between:

• thinking and shaping the problem

• and actually building the solution

Final thoughts

These are just some of the things that have helped me so far while working with Claude.

What stands out most to me is that this is still evolving. The more I use it, the more I notice small adjustments in how I think about building, structuring, and automating work.

Some of these things I’ve learned through trial and error, and others have come more naturally as I’ve kept incorporating AI into my day-to-day workflow.

I’m sure this will continue to evolve over time—and I’d be curious to hear how others are approaching it as well.

It’s just me, an idea, and the responsibility of turning it into something real.

At first, I assumed the challenge would be execution: writing code and building features quickly.

But I’ve realized something more subtle:

The hardest part is not building the feature — it’s deciding what to build, and how small that version needs to be to validate real user behavior.

This is just one of several challenges I’m starting to recognize, and I suspect there are more worth writing about as I keep building.

How I’ve Always Thought About Features

I’ve always approached features with a consistent mental model.

Whenever I work on something, I naturally think about:

• why it exists and what value it creates

• what problem it solves

• how it can be simplified

• what edge cases matter

• what I explicitly don’t want to build

• how it fits into the existing data model and UI

• how the user experience should feel end-to-end

• how to implement it with minimal user friction

• what signals would indicate this feature is actually working

This isn’t something I learned recently — it’s just how I reason about problems.

Even in my engineering role, I’ve always used a strong user-story mindset: understanding intent, questioning value, and sometimes even challenging whether something should be built at all.

Over time, I realized this is what more senior thinking actually looks like:

Not just implementing features, but deeply understanding intent and improving it when needed.

The Problem I Didn’t Have a Name For

In my side project, I started running into a subtle issue.

I would do most of the feature thinking upfront — naturally and consistently — before writing any code: planning how it would fit into the existing data model, how it would behave in the UI, and what the user experience would feel like end-to-end.

But once I started implementing, that thinking had nowhere to live.

If I stored it in a Linear ticket, it would get buried in execution details. More importantly, a Linear ticket — as a small unit of work — often didn’t represent the full end-to-end feature vision, only the initial increment being implemented.

If I stored it in Google Docs, it would quickly become something I forgot to revisit.

So I was left with a gap:

A lot of clarity before coding… and very little preservation of that clarity afterward.

Seeing PRDs Differently

I’ve seen PRDs before — usually as input documents in product discussions or strategic meetings. But I never had to write them myself.

For context, a PRD (Product Requirements Document) is a structured document used to define what a product or feature should do, why it exists, and how success is measured before development begins.

They felt formal, structured, and somewhat distant from how I naturally think when building.

That changed in this side project.

Because I am now both the product thinker and the implementer, I started noticing that I may need a simple framework to structure this type of thinking, and a persistent place to store it so it could eventually be referenced when implementing features in Linear.

Not as something I fully have — but as something that might be useful to formalize.

PRD-Lite: A Repeatable Thinking System (Emerging Idea)

Over time, I noticed I was already doing a fairly repeatable type of thinking — just informally.

To make it easier to reason about, I started sketching a simple structure I might use for future features. I’m considering storing it as a Markdown file in the repo so it stays close to the code and could eventually be referenced during implementation.

I haven’t adopted this yet, but it feels like a direction worth exploring.

🧾 PRD-lite format

1. Why it exists Why this should be built and what value it creates

2. MVP scope What the smallest useful version includes

3. User flow What the user does

4. Data model (light) What objects exist

5. Out of scope What I am explicitly not building

Right now, this is more of a thinking scaffold than a system — something I use to avoid losing structure while I’m reasoning about a feature.

The AI Layer: A Possible Extension of This Idea

Another thing I’ve been thinking about is how this kind of structured thinking might interact with AI coding assistants.

If I eventually write these PRD-like notes in the repo, they could serve as useful context when working with tools like Claude or similar assistants.

Instead of re-explaining intent in prompts, the assistant could potentially use:

• structured feature definitions

• scope boundaries

• user flows

• data model assumptions

This is not something I’m actively doing yet — but it’s one of the reasons this idea feels interesting.

It suggests a workflow where thinking becomes more portable between planning and implementation.

Why This Matters in a Side Project

When you’re building alone, there is no separation between:

• product thinking

• decision making

• implementation

Everything collapses into one continuous flow.

That makes it very easy to:

• lose intent while coding

• overbuild in the moment

• forget original assumptions

• drift away from the real problem you were solving

What I’m exploring here is not a process — it’s a way to preserve intent long enough to actually build from it.

Final Thought

I used to think PRDs were documents created for engineers to follow.

Now I see them differently.

They are not external instructions — they are a way to make your thinking persistent enough to actually build from it.

And for the first time building something on my own, I’ve realized I’ve naturally been doing product thinking all along — and I’m now starting to explore how to structure that thinking so it doesn’t get lost between idea and implementation.

Think clearly. Write it down. Build intentionally.

That’s the system I’m starting to discover

They help us explore faster, reduce friction, catch bugs in seconds, diagnose issues in minutes, refactor code precisely, and move through iterations at a pace that would have felt unrealistic not long ago.

All of that is objectively positive.

And yet, alongside those gains, something quieter has shifted — not in capability, but in how the work feels.

This article is an attempt to name that shift from the perspective of a senior developer working with AI-powered tools — not as a critique, but as a reflection on the feelings and navigation required in this new paradigm.

From building systems to shaping them

For much of my career, the relationship between effort and ownership was relatively clear.

You analyzed and built solutions.
You carried problems end to end.
You found and fixed issues opportunely.
You mastered your stack, sharpened your understanding of computer science, system design, and engineering — and used that as a guiding signal of how good you were becoming.

Today, that relationship is less predictable.

AI doesn’t just help write code — it can:

• propose the structure

• draft the solution

• fill in edge cases

• produce something that already works

When that happens, the output can be correct and high quality — yet still feel oddly distant.

We’ve shifted from knowing things at a very granular level to orchestrating tools and shaping systems into existence.

When contribution starts to feel ambiguous

I’ve noticed that how I feel about my contribution depends less on how much AI I use, and more on how I’m involved.

I feel more grounded when I:

• intentionally orchestrate the process

• participate actively in decision-making

• debug and investigate issues

• guide refactors toward something more mature

• go beyond the first iteration

• push for quality, correctness, tests, observability, and other core software engineering practices

In those moments, the work feels shaped, not just completed.

By contrast, when AI:

• proposes the structure

• drafts most of the solution

• resolves edge cases

• delivers something that already works

• resolves things quickly

…and my role is mainly to approve, lightly edit, and merge, a different feeling can emerge:

“I didn’t really contribute enough.”

The difference isn’t about typing versus not typing.
It’s about being necessary in the process.

How AI can aggravate impostor syndrome

This is where impostor syndrome can quietly enter — even for experienced developers.

Not because the work is poor.
Not because the system is fragile.
But because familiar signals of contribution are no longer reliable.

When AI takes a large portion of the work off my plate, it can provoke thoughts like:

• “I didn’t do this myself.”

• “I couldn’t have done this without help.”

• “How much of this was really me?”

The system may be better.
The outcome may be right.
But the internal sense of contribution can lag behind.

At times, this can feel like a lack of competence — but it’s really a paradigm shift.

Ways of recognizing value that worked for more than a decade — attention to detail, deeply caring about correctness and quality — don’t always map cleanly onto AI-assisted workflows or speedy shipment.

That mismatch can create doubt or unease, even when everything is working as intended.

A different shape of ownership

At senior levels, ownership no longer means:

• writing every line

• remembering every detail

• coming up with the architecture entirely on your own

It means:

• defining the right problem

• choosing the right constraints

• rejecting wrong or premature solutions

• integrating pieces into a coherent system

• being accountable when it breaks

When something fails, no one asks how much AI was involved.
They ask you — the engineer who shipped the solution — to stand behind it.

That responsibility hasn’t gone away, even if the path to it looks different now.

Closing

I don’t think I’m alone in experiencing this shift.

I suspect many senior developers are navigating something similar: working effectively with powerful tools, delivering solid systems, and still adjusting to how contribution and ownership feel in this new context.

This article itself was written with AI assistance — intentionally. Not to dilute the voice, but to reflect the reality it describes. The thoughts captured here represent feelings I’ve been sitting with as I navigate this new paradigm.

If this resonates, I’d be genuinely interested in hearing how others are experiencing this shift — what feels familiar, what feels different, and how you’re making sense of authorship and ownership in AI-assisted work.

Update – December 2024:
String Templates were available as a preview feature in Java 21 and Java 22.
However, the feature was withdrawn from Java 23 because the JDK team decided it required more design work before moving forward.
The concept is not canceled — it is expected to return in a future release with an improved design — but it is not available in Java 23.

Everything described in this article refers to the earlier preview versions (Java 21–22). I’m keeping the article online for educational purposes and will update it again when the new design becomes available.

String Templates are one of the most anticipated additions to modern Java. They were first introduced as a preview feature in Java 21, refined again in Java 22, and kept in preview in Java 23. They are expected to remain in preview until at least Java 24 or 25, when the design stabilizes enough to be finalized.

Even as a preview feature, String Templates are worth trying out. They significantly improve how developers construct strings in Java, and as a result, you will be better prepared when they are finalized.

What is this feature about?

String Templates allow embedding Java expressions directly inside string literals using the STR processor. This provides cleaner syntax for building structured strings and complements Text Blocks, making Java feel more expressive and modern.

Quick example:

String name = "Mirna";
String message = STR."Hello, \{name}! Today is \{LocalDate.now()}";
System.out.println(message);

Sample output:

Hello, Mirna! Today is 2025-01-01

How to run preview features:
If you are trying this with Java 21 or newer, you must enable preview mode, for a class for code that uses this feature like StringTemplatesDemo, we will need:

javac --enable-preview --release 21 StringTemplatesDemo.java
java  --enable-preview StringTemplatesDemo

Adjust the version number if you use a newer JDK (22, 23, etc.).

Common Use Cases

1. Build JSON cleanly

String user = "Mirna";
int score = 98;

String json = STR."""
{
  "user": "\{user}",
  "score": \{score},
  "active": true
}
""";

System.out.println(json);

2. Construct SQL dynamically

String table = "users";
String email = "mirna@example.com";

String query = STR."""
SELECT *
FROM \{table}
WHERE email = '\{email}'
""";

System.out.println(query);

3. Build HTML fragments

String name = "Mirna";

String html = STR."""
<p>Hello, <b>\{name}</b>!</p>
""";

System.out.println(html);

4. Use expressions directly

String math = STR."2 + 2 = \{2 + 2}";
String random = STR."Random value: \{Math.round(Math.random() * 10)}";

System.out.println(math);
System.out.println(random);

5. Use methods inside templates

String greet(String name) {
    return STR."Hello, \{name.toUpperCase()}!";
}

System.out.println(greet("Mirna"));

6. Combine Text Blocks + Templates

String language = "Java";
String feature = "String Templates";

String article = STR."""
## Feature Highlight

We're exploring \{feature} in \{language}.

Advantages:
- Readable
- Multiline
- Interpolated directly in code
""";

System.out.println(article);

Final Thoughts

String Templates make Java more modern and readable, especially when combined with Text Blocks. The feature is a meaningful improvement over string concatenation and String.format.

There are still two things that feel a bit unnatural to me.
First, the backslash before the curly braces (\{name}). Second, having to prefix a Text Block with STR.""" just to enable interpolation. Most modern languages do not require this extra step. I can live with both, though, since the improvement in readability is real.

I’m excited to see how this feature evolves as it moves toward finalization.

Quick note: I’m not affiliated with Cursor in any way. This is just my honest experience using it as part of my daily development flow.

Quick intro — what is Cursor?

Cursor is an AI-powered coding editor that acts like an extra (very eager) developer: it reads your repo, runs agent-style tasks, edits files, suggests fixes, and can even scaffold features. The real game changer for me is that Cursor has the whole codebase as context. You don’t need to paste files or explain the entire project — you just reference what you want, and it knows what you mean.

Pricing

Cursor has a free option and paid tiers. Honestly, the free tier didn’t help me much beyond getting a feel for the tool. The real value came once I switched to the paid plan, and I’m grateful my team enabled it for us. On paid plans you get a limited number of requests each month, and you can also set an extra buffer of requests if someone goes over — which is especially useful for teams.

My overall impression

I’m genuinely impressed. When you give Cursor a clear task with a simple scope and good instructions, it can really deliver. Some people compare it to having a junior dev working for you — eager to move fast and do as much as possible. I completely agree.

Where Cursor really helped me

• Bug fixing: Quick suggestions to try out, which makes debugging less painful.

• Asking questions about the codebase: Instead of searching forever, I just ask Cursor about specific parts of the repo.

• Implementing new features with clear scope: It’s great at well-defined, non-ambiguous tasks.

• Remembering syntax/commands: Especially across multiple languages and tools.

• Running commands directly: This feature has been surprisingly useful. Instead of switching back and forth, I can run commands right from Cursor and keep my flow.

But it’s not perfect

• It makes mistakes and sometimes gives “bandaid” fixes (like just adding a null check without solving the real root cause).

• It can get stuck repeating the same approach or stuck in general

• You still need to test, review, and ask hard questions. Think of it as a junior dev — you’re still the one driving.

• It might overengineer solutions at times

• AI hallucinates and gives you wrong answers or partially right ones

Things that helped me get more out of Cursor

• Split complex tasks into steps. Easier to validate each result.

• Use git intentionally. Feature branches, small commits, incremental progress, stashes, etc to record the steps that are in a good shape or acceptably good to go. That will save you when you need to reverse things safely

• Run QA and tests. Don’t trust the shiny “all fixed” message until you confirm.

• Ask for tests. Make Cursor write them, then review and improve.

• Provide detailed context. Logs, corner cases, knowns/unknowns, filenames, code fragment — the more thoughtful you are at providing guidance, the better the output.

• Track usage. Requests are limited, so I keep an eye on how many I’ve used.

• Pair it with ChatGPT. I use ChatGPT for general questions or planning, Cursor for codebase-aware tasks.

• Be specific when reverting changes. Otherwise, it might undo more than you expect.

• Batch steps into one request when possible. Saves credits.

• Keep learning prompt engineering. Makes a big difference in quality.

• Know when to pivot. If it’s stuck, switch strategies or take over manually.

• Still use docs/Stack Overflow/debugging. AI is great, but not everything.

And yes — don’t waste requests saying “thank you” 😅.

Final thoughts

I’d say Cursor is absolutely worth it. You just need to learn how to use it well: give it scope, guide it, question it, and keep testing. The better you are at driving, the more you’ll get out of it. For me, it’s taken a lot of the heavy lifting and repetitive tasks off my plate, while still leaving me in control of the important decisions.

What about you? Have you tried Cursor as your AI pair-programmer? How do you use it day-to-day? I would love to hear your experience as well!

🆕 What Is a Text Block?

A text block is a multi-line string literal introduced as a preview in Java 13 and officially added in Java 15. It allows you to write strings across multiple lines without having to escape every newline or quote.

Syntax

Text blocks are enclosed in three double quotes ("""), and must start on a new line:

String html = """
    <html>
        <body>
            <h1>Hello, World!</h1>
        </body>
    </html>
    """;

This is far more readable than:

String html = "<html>\n" +
              "    <body>\n" +
              "        <h1>Hello, World!</h1>\n" +
              "    </body>\n" +
              "</html>\n";

Where Can You Use a Text Block?

Anywhere you can use a regular string, you can use a text block. That includes:

• Assignments to variables

• Method arguments

• Return values

• Annotations

• Logs and templates

System.out.println("""
    This is a valid
    text block string
    used as an argument.
    """);

Text blocks shine when dealing with structured or long-form content:

• 🖥️ HTML/XML/JSON snippets

• 💾 SQL queries

• 🤖 Prompt engineering for AI

• 🧑‍🏫 Code samples for documentation

• 📜 Poetry, song lyrics, or long messages

String sql = """
    SELECT id, name
    FROM users
    WHERE active = 1
    ORDER BY name;
    """;

Smart Whitespace Handling: Incidental vs Essential

One of the most powerful features of text blocks is their ability to remove incidental white space—the indentation that's not part of the string itself but exists to align with your code.

Let’s visualize this with · characters to represent leading spaces.

👇 Example: Incidental White Space Removed

void writeHTML() {
    String html = """
········<html>
········    <body>
········        <p>Hello World.</p>
········    </body>
········</html>
········""";
    writeOutput(html);
}

✅ The output of html becomes:

<html>
    <body>
        <p>Hello World.</p>
    </body>
</html>

Java determines the minimum indentation level (based on the closing delimiter position) and removes it from all lines. This keeps your string readable and aligned with your code.

Preserving Essential White Space

To preserve indentation within the string, just move your content to the right:

void writeHTML() {
    String html = """
········    <html>
········        <body>
········            <p>Hello World.</p>
········        </body>
········    </html>
········""";
    writeOutput(html);
}

Result:

    <html>
        <body>
            <p>Hello World.</p>
        </body>
    </html>

Opting Out of Trimming Entirely

If you don’t want Java to trim anything, place the closing delimiter on the far left:

void writeHTML() {
    String html = """
                  <html>
                      <body>
                          <p>Hello World.</p>
                      </body>
                  </html>
""";
    writeOutput(html);
}

Java will treat every character as-is, preserving all leading spaces.

For all the nitty-gritty details, see JEP 355.

Normalize Line Terminators

Text blocks use \n (line feed) as the default line terminator on all platforms. If you need to convert them to your system-specific line separator (e.g. \r\n on Windows), you can do:

String adjusted = textBlock.replaceAll("\n", System.lineSeparator());

This ensures your strings behave consistently across environments.

New String Methods Introduced

Java 15 introduced several useful methods in the String class to complement and enhance the text block feature:

Example: 📄 formatted(...) with Text Blocks

You can use .formatted(...) directly on a text block to inject dynamic values:

String email = """
    Dear %s,

    Your order #%d has been shipped and is expected to arrive by %s.

    Thank you for shopping with us!
    """.formatted("Mirna", 12345, "Friday");

System.out.println(email);

Output:

Dear Mirna,

Your order #12345 has been shipped and is expected to arrive by Friday.

Thank you for shopping with us!

This makes text blocks a great fit for templated emails, prompts, or code generation — with clean syntax and no clutter.

📚 Official Documentation

Want to learn more or see additional examples? Check out the official guide:
👉 Text Blocks in Java 15

Conclusion

Text blocks are a small yet powerful improvement in Java that makes your code easier to read, write, and maintain—especially when working with structured or formatted content.

No more escaping newlines or cramming everything into one line. Just write clean, readable text!

🧭 Stay tuned for more in the Modern Java Features series!

What I experienced is known as semantic overload — when a single word is used in multiple ways across a field. And now I understand why: “model” is one of the most overloaded words in software and AI.

In the sections below, we’ll break down some of the most common meanings of “model” across different tech contexts, with examples to help make sense of each one.

1. OpenAPI / Swagger: Model = Data Structure

In OpenAPI (or Swagger), a model refers to a data structure — usually described in YAML or JSON — that defines the shape of the data your API sends or receives.

🧠 Think of it as a contract between the client and server.

📦 Example:

User:
  type: object
  properties:
    id:
      type: integer
    name:
      type: string
    email:
      type: string

This model describes what a User object should look like when exchanged through the API.

2. MVC: Model = Business Logic Layer

In Model-View-Controller (MVC) architecture, the model represents your business logic and domain data. It’s responsible for how the data behaves, not how it looks or how users interact with it.

🧠 Think of it as the “what” your app is about.

📦 Example (Java):

public class Post {
    private String title;
    private String body;
    private LocalDateTime publishedAt;

    public Post(String title, String body) {
        this.title = title;
        this.body = body;
        this.publishedAt = LocalDateTime.now();
    }

    public void publish() {
        this.publishedAt = LocalDateTime.now();
    }

    // Getters and setters omitted for brevity
}

This plain Java class represents a Post and contains some basic behavior (like publishing). It’s part of the “Model” in MVC — separate from how the post is displayed (View) or handled via user interaction (Controller).

3. Ruby on Rails: Model = ActiveRecord Class

In Rails, “model” often refers to an ActiveRecord class, which connects to a database table and includes both data and behavior.

🧠 Think of it as your data and rules in one place.

📦 Example:

class Post < ApplicationRecord
  validates :title, presence: true
end

This model connects to the posts table and adds validations or callbacks related to posts.

4. Artificial Intelligence: Model = Trained Algorithm

In AI or Machine Learning, a model is a trained system that makes predictions or generates content based on patterns it learned from data.

🧠 Think of it as a trained brain that knows how to do a specific task.

📦 Example:

prediction = spam_model.predict("You've won a prize!")

Here, spam_model is a trained object — not a class or schema — that returns a prediction.

5. Domain-Driven Design (DDD): Model = Domain Representation

In Domain-Driven Design, a domain model represents the core concepts and behaviors of your problem space. It’s focused on encapsulating business rules.

🧠 Think of it as a rich, real-world object with behaviors that matter.

📦 Example:

class Account {
  void deposit(Money amount) { ... }
  void withdraw(Money amount) { ... }
}

This model knows how to modify its own state through well-defined methods.

6. Frontend Frameworks: Model = View Data

In frontend frameworks like AngularJS, a model is simply the data behind the UI — especially in systems with two-way binding.

📦 Example:

<input ng-model="user.name">

Changes in the input automatically update user.name, and vice versa.

Final Thoughts

If you’ve ever felt confused about what “model” means, you’re not alone. It’s not you — it’s the context.

The key takeaway is this:
✅ Don’t assume a word means the same thing everywhere.

A beginner’s mindset — being open, curious, and unafraid to ask — helps you adapt faster and avoid misunderstandings.

So the next time someone says “this model does X”, don’t hesitate to ask:
“Wait, which kind of model are we talking about?”
What does ‘model’ mean in this context?

How about you? Have you ever experienced context overload?
I’d love to hear about it — let me know in the comments. 🙂

Clone the repo

git clone <repository-url>

🔍 See What's Going On

git status

Shows what's changed, what's staged, and what's untracked.

git log --oneline

View commit history (detailed or summarized).

➕ Stage & Commit Changes

git add <file>     # Stage a single file
git add .          # Stage everything

git commit -m "Your message here" Creates a commit with your staged changes.

💡 Git Tip: Think of Git as a three-step process:
1️⃣ Working Directory – where you make edits
2️⃣ Staging Area – where you select what to commit
3️⃣ Repository – where your project history lives

Staging gives you control over what gets committed, so you can group related changes together before saving them permanently.

🔄 Stash Changes

git stash -m "WIP: login bug"   # Save changes with a label
git stash list                  # View stashes
git stash apply [stash@{id}]    # Reapply a specific stash

💡 Git Tip: Need to switch tasks but don’t want to commit your work yet?
Use git stash to save your changes temporarily and return to a clean working state.
Later, use git stash apply to get your work back.

🛠️ Pro Tip: Use git stash list to see all stashes, and git stash drop to delete one you no longer need

🌿 Branching

git branch                    # List branches
git branch feature-xyz        # Create a new branch
git checkout feature-xyz      # Switch to it
git checkout -b feature-xyz   # Create and switch to a new branch in one line
git switch feature-xyz        # Newer switch syntax

⬇️⬆️ Sync with Remote

git pull          # Pull latest changes
git push          # Push local commits

# Sets the upstream tracking branch when pushing for the first time
git push -u origin [branch-name]

# Force-push your local branch — use with caution! Ideal after a rebase:
git push --force

🔧 Undoing Mistakes

git restore <file>            # Discard local changes
git restore --staged <file>   # Unstage a file

🧨 Life-Saving Commands

Pull the latest from main and rebase your current branch in one single step:

git fetch && git rebase origin/main

💡 Git Tip: Keep your branch up-to-date and avoid merge commits by rebasing onto the latest main. Perfect for clean history before a PR.

Remove commits but keep the changes:

💡 Need to rewrite history? --soft lets you uncommit changes but keeps them staged so you can tweak and recommit.

git reset [commit-hash] --soft

Pull a file from another branch to modify it locally:

💡 Want just one file from another branch? This command pulls it into your current branch without switching context.

git checkout other-branch -- path/to/file

If you’ve ever heard phrases like that and wondered if you know English — you’re not alone.

Tech jargon is part of the culture. It’s not something you usually learn in school, but something you pick up over time as you work, adapt to your company’s way of speaking, and grow more comfortable in the environment.

I put together this glossary to walk you through some of the most common terms — the kind you’ll hear in meetings, Slack threads, and docs. Whether you’re starting your first job in tech, joining a remote team, or working in English as a second language, I hope this gives you helpful context.

💬 Communication & Workflows

Circling Back
A polite way to revisit a topic — used to follow up, remind, or bring it up again.

• “Just circling back on that spec we discussed.” → “Just following up.”

• “Circling back now that we have more data.” → “Revisiting now that we know more.”

• “Let me finish this, and I’ll circle back later today.” → “I’ll return to this later.”

Touch Base
A casual way to say "connect briefly."

“Can we touch base tomorrow?” → “Have a quick chat?”

Bandwidth
Refers to someone’s time or capacity to take on work.

“I don’t have bandwidth right now.” → “I’m too busy.”

Low-Hanging Fruit
Simple tasks that bring quick wins.

“Let’s tackle the low-hanging fruit first.” → “Let’s start with the easiest wins.”

Doubling Down
Committing more strongly to an idea or effort.

“We’re doubling down on performance.” → “We’re putting more effort into this area.”

Pushing Back
Means delaying or rescheduling something for later — not earlier.

• “We’re pushing back the deadline to next Friday.” → “Delaying the deadline.”

• “Can we push the meeting back an hour?” → “Start the meeting later.”

• “They pushed back the release to Q3.” → “Postponed to Q3.”

Why it’s confusing: For many ESL speakers, the word “back” suggests moving something earlier — like going back in time. But in this context, it actually means shifting something further into the future. It’s a counterintuitive phrase until you get used to how it’s used at work.

🧪 Product & QA

Dogfooding
Using your own product internally before releasing it to users.

“We dogfooded the new dashboard and found key issues.”
Why it matters: It helps catch problems early and shows confidence in your product.

Bug Bash
A planned team session where everyone tries to find bugs.

“The bug bash helped uncover edge cases before launch.”
Why it matters: It’s a fast, team-wide way to catch problems with more eyes on the product.

Bug Dash
A focused effort to fix as many bugs as possible in a short time.

“We’re doing a bug dash to clean up the backlog.”

📈 Growth, Strategy & Metrics

Churn
When users stop using your product or cancel a subscription.

• “Our churn rate is 7%.” → 7 out of 100 users left this month.

• “We saw churn increase after the pricing change.” → “More users left.”

Why it matters: It’s a sign that users didn’t find enough value to stay. You’ll hear it often in conversations about retention, onboarding, or pricing.

RRM (Rolling Retention Metric)
Tracks what percent of users return after a set number of days (e.g. 7-day RRM).

“Our 7-day RRM dropped — let’s look into why users disengage.”

North Star Metric
The single most important number that reflects product success.

“Weekly active users is our north star metric.”

Customer Journey
The complete experience a user has — from signup to loyal customer (or churn).

“We’re mapping the customer journey to improve onboarding.”

Common Workplace Shorthand

These abbreviations are everywhere — in Slack threads, PR reviews (oops, just used one myself — PR = Pull Request 😅), email subjects, and Jira comments. Here’s what they mean:

Hard Stop

A firm end time for a meeting or task.
💬 “I have a hard stop at 3PM.” → “I need to leave at 3, no matter what.”

ASAP / EOD / COB

Used to signal urgency or deadlines.
• ASAP = As Soon As Possible
• EOD = End of Day
• COB = Close of Business (same as EOD, just a bit more formal)
💬 “Please review the PR ASAP.”
💬 “Can you finish this by EOD?”

OOO
Out of Office — often used in auto-replies or status updates.
💬 “OOO next week, back on Monday!”
💬 “Just a heads-up, I’ll be OOO this afternoon.”

TL;DR

Too long; didn’t read — a summary, usually at the top (or bottom!) of a long message.
💬 “TL;DR: We’re moving forward with option B.”

FYI

For your information — no action needed, just awareness.
💬 “FYI: The deploy is scheduled for tomorrow morning.”

ETA

Estimated time of arrival — when something is expected to be done or delivered.
💬 “What’s the ETA on the bug fix?”

NIT

Short for “nitpick.”
Used in code reviews to point out something small — not a blocker.
💬 “NIT: Consider renaming this variable for clarity.”
Translation: You don’t have to change it… but I noticed it.

🙏 Final Thoughts

Jargon is something you grow into. Don’t feel pressured to memorize everything — this list is just a head start. Save it, refer back to it, and most of all, don’t be afraid to ask when something doesn’t make sense.

Beyond these common terms, acronyms are everywhere. English speakers love to shorten things, and the corporate world takes it to the next level. At my current job, for example, CPT stands for Client, Project, and Tasks. You’ll encounter acronyms for tools, teams, roles — almost everything.

If it ever feels like people are speaking a foreign language, you’re not alone. Especially when landing your first job in tech or working remotely in English, it can feel a bit overwhelming at first. But with a little patience and curiosity, you’ll be fluent in “corporate” in no time!

What about you?
Is there a term you keep hearing that isn’t listed here? Drop it in the comments — I’d love to keep learning, too.

And yet... I do it because when I didn’t, it blew up in my face later.

This post breaks down what DTOs and domain models are, why separating them is important, and provides a few real-world examples of how skipping that step can backfire.

Let’s Talk About the Basics

DTO (Data Transfer Object)

A DTO is a data container used to exchange information across boundaries — usually between a remote API and your app.

Think: Backend response → DTO → App

It represents exactly what the backend gives you. No assumptions, no transformations, just raw data.

struct UserDTO: Codable {
    let id: Int
    let first_name: String
    let last_name: String
    let email_address: String
    let created_at: String
}

Domain Model

The domain model reflects the structure and language of your app’s business logic. It’s what the UI, business rules, and features should operate on.

struct User {
    let id: Int
    let fullName: String
    let email: String
    let joinDate: Date
}

Notice how this version:

• Combines first_name + last_name

• Converts created_at (a string) into a Date

• Renames fields for clarity and Swift naming conventions

Why the Separation Matters

Reason #1: Domain Logic Shouldn’t Care About Backend Garbage

Sometimes APIs give you fields that don’t belong in your app logic at all:

• Debug-only fields

• Internal backend IDs

• Raw numeric codes instead of enums

• Deeply nested structures you don’t actually need

Let’s say you receive a JSON like this:

{
  "meta": {
    "request_id": "abc123",
    "timestamp": "2024-01-01T00:00:00Z"
  },
  "data": {
    "user": {
      "id": 42,
      "profile": {
        "first_name": "John",
        "last_name": "Appleseed",
        "email": "john@example.com"
      },
      "roles": [
        {
          "id": 1,
          "label": "admin",
          "permissions": ["READ", "WRITE", "DELETE"]
        }
      ],
      "audit": {
        "created_by": "system",
        "created_at": "2023-05-01T10:00:00Z",
        "updated_at": "2023-06-01T15:30:00Z"
      }
    }
  }
}

What should you do?

First, define a clean domain model:

struct User {
    let id: Int
    let fullName: String
    let email: String
    let role: String
}

Then, write a DTO and map what you need:

struct UserResponseDTO: Codable {
    let data: DataNode
    struct DataNode: Codable {
        let user: UserNode
    }
    ...
}

extension UserResponseDTO {
    func toDomain() -> User {
        let user = data.user
        return User(
            id: user.id,
            fullName: "\(user.profile.first_name) \(user.profile.last_name)",
            email: user.profile.email,
            role: user.roles.first?.label ?? "unknown"
        )
    }
}

Now your domain model is clean, shallow, and safe — and your app no longer lives at the mercy of backend nesting changes.

Reason #2: Backend Contracts Change

Ever had a backend team rename a field because they “standardized the naming convention”? One day it’s email_address. Next day? email. No warning. No version bump. Just… surprise!

If you were piping that directly into your SwiftUI view, you’ve just earned yourself a lovely nil crash and a bunch of angry users.

But if that chaos hit a DTO, you’d be fine (only one file change).

enum CodingKeys: String, CodingKey {
    case emailAddress = "email"
}

The UI wouldn’t even notice the explosion behind the scenes. That’s the point. DTOs act like airbags — ugly, but essential when things go wrong.

Reason #3: Different Sources, One Model

Suppose your app gets User data from:

• An API

• A local cache

• A CoreData store

All of them return different formats, and some even lack fields.

Solution: Use DTOs per source and map them into a consistent domain model.

extension UserDTOFromAPI {
    func toDomain() -> User {
        User(
            id: id, 
            fullName: "\(first_name) \(last_name)", 
            email: email_address,
            joinDate: created_at.toDate()
        )
    }
}

extension UserDTOFromLocalCache {
    func toDomain() -> User {
        User(
            id: userId, 
            fullName: name, 
            email: email, 
            joinDate: Date(timeIntervalSince1970: timestamp)
        )
    }
}

Final Thoughts

Yes, writing both DTOs and domain models feels like extra work most of the time, but the truth is: if you skipped them, you’ll pay for it later — in broken UIs, fragile tests, and spaghetti logic tied directly to whatever the backend felt like returning that week. So now I treat them like seatbelts. You don’t put them on because you’re expecting a crash; you put them on because you know what happens when you don’t.

If you want your Swift app to scale, survive backend changes, and stay testable and sane, separate your DTOs and your domain logic.
Future you will thank you.

I’m writing this for anyone who’s ever considered trying a new tech stack and felt intimidated by not knowing enough. If that’s you, you’re not alone. It’s okay to be new. It’s okay not to know yet.

In this post, I’m sharing a few things that surprised me during my first week, and a reflection on what it feels like to start over in unfamiliar territory.

Adjusting to interpreted code

Coming from Java, I'm used to having the compiler catch my mistakes immediately. If something is wrong, it just doesn’t compile — simple. But with Ruby being an interpreted language, that safety net is gone. When I refactor code now, I can’t just assume it’s fine — it might not even be syntactically correct, and I won’t know until I run it.

That felt strange at first. I caught myself thinking, “Did I break something? Did I miss a typo?” It pushed me to rely more on writing test cases just to make sure the code even runs — not just that it works correctly, but that it runs. Still, I like that now I have one more reason to write those tests.

No type definitions

One thing I’m still adjusting to is the lack of type declarations — not even def for variables. I’ll just see a variable name and a value assigned to it, and that’s it.

total = 5
name = "Mirna"

Coming from Java, where you’d write something like:

int total = 5;
String name = "Mirna";

…it feels odd not to declare intent up front. I’m not sure yet what issues this might bring long-term, but so far I really appreciate how concise the code is. It’s fast to write and easy to follow — once you get used to it.

Running code with no main

Another thing that surprised me: you can just open a console (IRB or Rails console) and run Ruby code — no main, no class, no setup. Just type and go.

2 + 2
# => 4

"hello".upcase
# => "HELLO"

Coming from Java, where even the simplest program needs at least a public static void main(String[] args)This felt super lightweight.

You can call any method from the console

Along the same lines, something I really liked is that you can call any method from the Rails console and immediately see the result. No need to wire up a controller, run the app, or hit an endpoint.

If the method is loaded, you just call it:

TimeEntry.describe("Worked on bug fixes")

It just runs and returns the result.

I didn’t use it much yet, but I can already tell this is going to be useful when I’m testing things out on the spot — especially when I don’t want to break flow or set up a full test just to try something small.

Final Reflection – Being a Beginner

The biggest adjustment hasn’t been the syntax or the framework — it’s been the feeling of being new. Starting with a tech stack you don’t know means becoming a beginner again in areas where you once felt confident.

Not knowing how things are supposed to be done — whether it’s the language itself, Rails conventions, GraphQL, or even the testing setup — can feel disorienting. Here’s what has helped so far:

• Being incremental

• Alternating between breadth and depth depending on what I’m trying to implement

• Embracing a beginner’s mindset

• Asking questions

• Googling

• Leaning on AI when it helps

• Reaching out to teammates when I need clarity

• Focusing on one task at a time and approaching it in a structured way — learning just enough to get it done, instead of trying to master everything at once

• Being Patient

With this approach, I learn something every day. And little by little, things begin to make more sense. The code doesn’t feel as alien as it did on day one.

And even though everything feels new, not everything is new. Many things come with you: your intuition, your debugging skills, your understanding of software fundamentals — they don’t disappear. They guide you through the process and help more than you might expect.

It’s only been a week — there’s still a long way to go — but I’m glad I took the chance. And I’m even more excited to keep learning.

I want to reiterate what I said in the intro, for you, today:

It’s okay to be new.
It’s okay not to know yet.

And if you’ve gone through a similar transition — from one stack to another, or from confidence to beginner mode — I’d love to hear how it went for you. Feel free to share your experience!

In earlier versions, it was verbose, error-prone, and limited in what you could do with it. But starting in Java 14 and finalized in Java 21, switch has evolved into a far more powerful and expressive tool.

In this article, we’ll walk through the key enhancements introduced across Java versions — with examples and explanations — so you can start using the upgrades right away.

➤ Arrow Syntax (->) (introduced in Java 14)

In traditional switch, forgetting a break could lead to bugs due to fall-through behavior. Modern switch introduces arrow syntax to make things safer and more concise.

💡 Fall-through means that if a case doesn't explicitly end (usually with break), execution continues into the next case — often unintentionally. Modern switch introduces arrow syntax to make things safer and more concise.

Before:

switch (status) {
  case "NEW":
    result = "Pending";
    break;
  case "DONE":
    result = "Complete";
    break;
  default:
    result = "Unknown";
}

After:

result = switch (status) {
  case "NEW" -> "Pending";
  case "DONE" -> "Complete";
  default -> "Unknown";
};

✅ No need for break
✅ No risk of accidental fall-through
✅ Cleaner and more readable

➤ Multi-label Case (introduced in Java 14)

You can now group multiple labels in a single case using commas.

result = switch (status) {
  case "NEW", "PENDING" -> "In Progress";
  case "DONE" -> "Completed";
  default -> "Unknown";
};

✅ Reduces duplication
✅ Easier to maintain grouped logic

➤ Switch as an Expression (introduced in Java 14)

Switch can now return a value, just like an expression. You can directly assign its result to a variable.

String label = switch (code) {
  case 1 -> "Low";
  case 2 -> "Medium";
  case 3 -> "High";
  default -> "Unknown";
};

✅ No temp variables needed
✅ Functional, compact code style

📝 Note: This example uses integers to illustrate the feature, but in real-world code, enums are often more appropriate for modeling discrete, known states like severity or status. If all you need is to associate static values (like labels) to enums, it's often cleaner to define those inside the enum itself. switch expressions shine when you need dynamic branching or more complex logic that's not easily handled by an enum field.

➤ yield for Multi-line Blocks (introduced in Java 13)

When you need more logic before returning a value from a case, use a block with yield.

String message = switch (status) {
  case "NEW" -> {
    log("Creating message...");
    yield "Pending";
  }
  case "DONE" -> "Complete";
  default -> "Unknown";
};

✅ yield lets you return from a block
⚠️ return is not allowed inside a switch expression block

➤ Pattern Matching (finalized in Java 21)

Java 21 introduced pattern matching for switch as a stable feature. It allows switching based on the type of an object and binds variables inline.

Object obj = "Hello";

String result = switch (obj) {
  case String s -> "String of length " + s.length();
  case Integer i -> "Integer doubled: " + (i * 2);
  case null -> "Was null";
  default -> "Something else";
};

✅ Match and bind values in one line
✅ Works with null
✅ Cleaner than instanceof + cast

➤ when Guards (finalized in Java 21)

You can add conditions to a type match using when:

String result = switch (obj) {
  case String s when s.length() > 10 -> "Long string";
  case String s -> "Short string";
  default -> "Other";
};

✅ Adds control to pattern matches

➤ Exhaustiveness with Sealed Types (introduced in Java 17)

If you switch over a sealed class or interface, Java checks that all subtypes are handled — and you don’t need a default case.

sealed interface Shape permits Circle, Square {}
record Circle(double r) implements Shape {}
record Square(double s) implements Shape {}

String label = switch (shape) {
  case Circle c -> "Circle with radius " + c.r();
  case Square s -> "Square with side " + s.s();
};

✅ Compiler ensures all subtypes are covered
✅ Safe refactoring: if a new subtype is added, you’ll get a compile error

✅ Conclusion

The modern switch is one of the most developer-friendly upgrades to Java in years.
It eliminates boilerplate, reduces common errors, and introduces a clean, expression-style syntax that aligns well with modern programming principles.

If you haven’t already, try using these enhancements in your next refactor — they make your code more readable, expressive, and maintainable.

Happy refactoring!

The Observer pattern is a behavioral design pattern that defines a one-to-many relationship between objects. When the state of one object (the subject) changes, all its dependents (the observers) are automatically notified and updated. This pattern promotes loose coupling between the subject and its observers and is widely used in event-driven systems.

What do you need to implement it on a high level?

• Define two interfaces: Observer and Subject

• Define a concrete implementation of the Subject

• Define as many concrete implementations of the Observer interface as you need

• Wired everything together externally

✨ Key Characteristics of the Observer Pattern

• One-to-many dependency: One subject notifies multiple observers.

• Loose coupling: Subjects don't need to know the concrete details of their observers.

• Dynamic subscription: Observers can be added or removed at runtime.

• Push or pull model: The subject may either send specific data or let the observer pull the data it needs.

🧠 When Should You Use It?

Use the Observer pattern when:

• You have a data source or subject whose state changes over time.

• Multiple parts of your system need to respond to that change.

• You want to decouple the logic of the source from its listeners.

It is common in:

• UI frameworks (e.g., event listeners in Java Swing or JavaScript)

• MVC architectures

• Logging systems

• Notification and alerting systems

📚 A Concrete Example: Book Club Announcement System

Let’s implement the Observer pattern using a simple domain: a Book Club. The book club announces new books on different schedules (monthly, biweekly, yearly), and its members are notified via different channels (email, push notification).

We’ll begin by defining the core interfaces for the pattern. This will help establish the contract for communication between the subject and its observers.

🔌 Step 1: Define Observer and Subject Interfaces

The Observer interface represents any component that wants to receive updates. The Subject interface is implemented by the class that owns the state and sends updates.

public interface Observer {
  void update(ScheduleType scheduleType, String bookTitle);
}

public interface Subject {
  void addObserver(Observer observer);
  void removeObserver(Observer observer);
  void notifyObservers(ScheduleType scheduleType, String bookTitle);
}

📦 Step 2: Create the Concrete Subject - BookClub

The BookClub class implements the Subject interface. It stores a list of observers and notifies them whenever a new book is announced. The announcement can happen on different schedules — monthly, biweekly, or yearly — using clearly named methods like announceMonthlyBook. This improves clarity and reusability, as each method encapsulates a specific context in which observers are notified.

This implementation also demonstrates a push model: the subject actively pushes data (schedule type and book title) to all observers when a change occurs.

🧠 In contrast, a pull model would mean the subject simply notifies observers that something changed, and the observers then call back to the subject to fetch the updated data. For that, the update() method in the Observer interface might receive no arguments, and observers would query the BookClub to retrieve the latest book title themselves.

public class BookClub implements Subject {
  public enum ScheduleType {
    BIWEEKLY, MONTHLY, YEARLY
  }

  private final List<Observer> observers = new ArrayList<>();

  @Override
  public void addObserver(Observer observer) {
    observers.add(observer);
  }

  @Override
  public void removeObserver(Observer observer) {
    observers.remove(observer);
  }

  @Override
  public void notifyObservers(ScheduleType scheduleType, String bookTitle) {
    System.out.printf("Announcing new book, scheduleType: %s, bookTitle: %s%n", scheduleType, bookTitle);
    observers.forEach(o -> o.update(scheduleType, bookTitle));
    System.out.println("------------");
  }

  public void announceMonthlyBook(String bookTitle) {
    notifyObservers(ScheduleType.MONTHLY, bookTitle);
  }

  public void announceBiweeklyBook(String bookTitle) {
    notifyObservers(ScheduleType.BIWEEKLY, bookTitle);
  }

  public void announceYearlyBook(String bookTitle) {
    notifyObservers(ScheduleType.YEARLY, bookTitle);
  }
}

📬 Step 3: Create the Concrete Observers

Observers react to announcements in different ways. Below are two examples: one sends an email and another sends a push notification.

public class EmailNotificationMember implements Observer {
  @Override
  public void update(ScheduleType scheduleType, String bookTitle) {
    System.out.printf("[Email] New %s book: '%s'%n", scheduleType, bookTitle);
  }
}

public class PushNotificationMember implements Observer {
  @Override
  public void update(ScheduleType scheduleType, String bookTitle) {
    System.out.printf("[PushNotification] New %s book: '%s'%n", scheduleType, bookTitle);
  }
}

Each observer implements the update method, which is called by the BookClub subject.

🚀 Step 4: Wiring it Together in the Main App

The main application is where we create the BookClub, register observers, and simulate announcements.

public class BookClubApp {
  public static void main(String[] args) {
    BookClub nonFictionClub = new BookClub();
    nonFictionClub.addObserver(new EmailNotificationMember());
    nonFictionClub.addObserver(new PushNotificationMember());

    nonFictionClub.announceMonthlyBook("Atomic Habits");
    nonFictionClub.announceBiweeklyBook("Hellen Keller Summarized Bio");
    nonFictionClub.announceYearlyBook("A History of Ancient Rome");
  }
}

When run, this will output messages showing which observers received which book announcements.

🔍 Beyond the Basics: Real-World Design Considerations

📤 Push vs Pull Model

Our BookClub example uses a push model: the subject passes all necessary data directly to the observers. This works well for small examples but may lead to long parameter lists and tight coupling as the data grows.

💡 In such cases, it's better to encapsulate the data being sent in a dedicated class (e.g., BookAnnouncement) to keep the observer interface clean and extendable.

public class BookAnnouncement {
  private ScheduleType scheduleType;
  private String bookTitle;
  // getters, constructors, etc.
}

Then the observer interface could change to:

void update(BookAnnouncement announcement);

🧠 In contrast, a pull model would mean the subject simply notifies observers that something changed, and the observers then call back to the subject to fetch the updated data. For that, the update() method in the Observer interface might receive no arguments, and observers would query the BookClub to retrieve the latest book title themselves.

🧩 Modeling Real Members vs Notification Channels

Our example keeps things simple by treating notification channels (email, push) as observers. But in a real system, you'd model things differently.

🧍 Option 1: Member as the Observer

public class Member implements Observer {
  private String name;
  private String email;
  private boolean wantsMonthlyOnly;

  @Override
  public void update(ScheduleType scheduleType, String bookTitle) {
    if (wantsMonthlyOnly && scheduleType != ScheduleType.MONTHLY) return;
    System.out.printf("Email to %s: New %s book: '%s'%n", name, scheduleType, bookTitle);
  }
}

📡 Option 2: Notification Observers Acting on Member

public class EmailNotifier implements Observer {
  private List<Member> members;

  @Override
  public void update(ScheduleType scheduleType, String bookTitle) {
    for (Member m : members) {
      if (!m.prefersEmail()) continue;
      System.out.printf("[Email] To %s: '%s' (%s)%n", m.getEmail(), bookTitle, scheduleType);
    }
  }
}

This second approach decouples domain from infrastructure, scales better, and aligns more closely with real-world design needs.

🧩 Observer Pattern in Frameworks and Real Systems

In real-world software systems, the Observer pattern appears frequently — even if you don’t always implement it directly. Recognizing it helps you understand the underlying architecture of many tools and frameworks.

Some common real-world manifestations include:

• Pub/Sub architectures: Systems like Apache Kafka, RabbitMQ, or Google Pub/Sub implement the Observer pattern at scale. Publishers emit events to a channel or topic, and subscribers react to those events.

• UI frameworks: In Java Swing, React, or Android, you often attach listeners or observers to UI components to handle events.

• JavaScript: Methods like addEventListener in the DOM model exemplify the pattern.

• Spring Framework: The @EventListener annotation enables event-driven programming by observing and reacting to domain events.

• Reactive Programming: Libraries like RxJava, Project Reactor, or RxJS are built entirely around observables and subscribers.

Understanding the pattern beneath these tools gives you an edge when debugging, designing for extensibility, or choosing the right communication strategy in your system.

✅ Conclusion

The Observer pattern is powerful when you need dynamic, loosely-coupled communication between components. While you may not implement it often by hand, understanding it helps you better navigate modern event-driven and reactive systems.

The BookClub example demonstrates the essentials, and the design reflection helps bridge the gap between learning and applying the pattern effectively in real-world systems.

Have you ever implemented the Observer pattern yourself, or mostly seen it abstracted in frameworks? I’d genuinely love to hear your experience. Whether you’re revisiting the pattern or discovering it for the first time, I hope this article gave you a clearer picture of how it works — and why it matters. Thanks for reading, and happy coding!

Understanding the Class Diagram

• Context: Has a Strategy object and uses it to delegate the work, without knowing the implementation details.

• Strategy: An interface defining a method (here called execute()), which each concrete strategy implements with its own behavior.

• ConcreteStrategyA / B: Specific implementations of the strategy, interchangeable at runtime.

How it works: The Context relies on the Strategy to perform the task. This allows swapping behaviors easily, promoting flexibility and following the Open/Closed Principle.

Simple Example

Let’s say we’re implementing a payment system, and we have multiple payment methods:

class PaymentService {
    void pay(String method, int amount) {
        if ("credit".equals(method)) {
            // logic for credit card
        } else if ("paypal".equals(method)) {
            // logic for PayPal
        }
        // more conditions to come...
    }
}

Having a long payment method with the needed logic to process multiple payment methods is rigid, grows unwieldy, and violates Open/Closed Principle (OCP). Each new method increases cyclomatic complexity and requires modifying the existing code.

Applying the Strategy Pattern

interface PaymentStrategy {
    void pay(int amount);
}

class CreditCardPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " with credit card");
    }
}

class PayPalPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " with PayPal");
    }
}

class PaymentService {
    private PaymentStrategy strategy;

    public PaymentService(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void process(int amount) {
        strategy.pay(amount);
    }
}

✅ This avoids conditionals, respects OCP, and makes each strategy testable and reusable — aligning with Single Responsibility Principle (SRP) too.

Example Usage

PaymentService service = new PaymentService(new CreditCardPayment());
service.processPayment(100);  // Outputs: Paid $100 with Credit Card.

service.setStrategy(new PayPalPayment());
service.processPayment(75);   // Outputs: Paid $75 with PayPal.

A Quick Note on Cyclomatic Complexity

Cyclomatic complexity increases as your code has more if-else branches, making it harder to test, understand, and change safely.

❌ Without Strategy Pattern (Multiple Paths)

javaCopyEditclass PaymentService {
    void pay(String method, int amount) {
        if (method.equals("credit")) {
            System.out.println("Paid with Credit Card");
        } else if (method.equals("paypal")) {
            System.out.println("Paid with PayPal");
        } else if (method.equals("applepay")) {
            System.out.println("Paid with Apple Pay");
        }
    }
}

Every new method adds a new branch — more paths, more chances to break something.

✅ With Strategy Pattern (Single Path)

javaCopyEditclass PaymentService {
    private PaymentStrategy strategy;

    public PaymentService(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void process(int amount) {
        strategy.pay(amount); // Always a single, clean path
    }
}

No matter how many strategies you add, process() always follows one path.
This makes your code easier to test, reason about, and extend — which helps maintain quality as the system grows.

Functional Programming: A Modern Alternative?

In languages that support first-class functions, you can simplify the strategy pattern using lambdas:

Consumer<Integer> creditCard = amount -> System.out.println("Paid " + amount + " with credit card");
Consumer<Integer> paypal = amount -> System.out.println("Paid " + amount + " with PayPal");

void processPayment(Consumer<Integer> strategy, int amount) {
    strategy.accept(amount);
}

For short, stateless behaviors, lambdas are concise and flexible. But if the strategy:

• Has internal state

• Needs validation logic

• Requires encapsulation

…then creating a full class (like CreditCardPayment) may be more appropriate to uphold SRP and encapsulation.

When Should You Use the Strategy Pattern?

Look for these clues:

1. You have multiple if-else or switch statements selecting behavior

2. You expect the behavior to change at runtime

Strategy lets you swap logic dynamically — for example, letting a user choose a payment method at runtime.

3. You want to follow the Open/Closed Principle

New behaviors can be added via new strategy classes, without touching existing logic.

4. You want to reuse or test behaviors independently

Each strategy is a standalone unit that’s easier to test and reuse in other parts of the system.

💡 Tip: Let the Strategy Pattern Emerge

Start with the simplest solution. If you notice repeated conditionals or growing complexity, that’s your cue to refactor using the Strategy pattern.

With experience, you’ll start recognizing these patterns earlier and apply them upfront when it makes sense.

🧩 Conclusion

The Strategy pattern is one of the simplest and most practical ways to apply the SOLID principles. In fact, if you study SOLID first, you’ll see that Strategy is a natural implementation of those ideas in action.
👉 You can refresh those principles in my article: SOLID Principles Refresher

By applying this pattern, you get code that is:

• Easier to maintain

• Less prone to errors

• Simpler to test and extend

I think there’s no real downside to using Strategy, as long as you apply it where flexibility is needed and don’t over-engineer parts of your code that are meant to stay simple or static.

👉 Enjoyed this article?
Check out the rest of my Design Patterns series here:
🔗 code-like-a-woman.hashnode.dev/series/design-patterns

A prototype is a pre-existing object that you use as a template to create new objects. Instead of creating an object from scratch, with newYou clone an existing one that already has the desired state.

The Prototype Pattern is a creational design pattern that lets you:

• Create new objects by copying (not instantiating) a prototype

• Avoid repeating complex setup logic

• Keep code flexible by not tying it to specific class constructors

For example, here’s how you would copy an object without this pattern:

Book book1 = new Book("Effective Java", "Joshua Bloch", List.of("Item 1", "Item 2"));

Book book2 = new Book(
    book1.getTitle(),
    book1.getAuthor(),
    new ArrayList<>(book1.getChapters())
);

You have to manually copy each field — error-prone and repetitive.

🧬 With Prototype Pattern (via copy method)

Book book1 = new Book("Effective Java", "Joshua Bloch", List.of("Item 1", "Item 2"));
Book book2 = book1.copy();

Much cleaner and encapsulated — the copy() method inside Book handles the duplication safely.

In Java, you have two alternatives to implement the pattern: implementing the Cloneable interface or defining a custom copy() method.

Ways to Implement the Prototype Pattern in Java

Option 1: Using Cloneable + super.clone()

🧩 Before We Start: What Is Cloneable and What Does It Do?

To use super.clone() in Java, your class must implement the Cloneable interface:

public interface Cloneable { }

It’s a marker interface — it has no methods. Its purpose is to signal the JVM that your object supports cloning. If your class does not implement Cloneable, calling super.clone() will throw a CloneNotSupportedException.

What You Must Do:

1. Implement Cloneable

2. Override clone() and make it public

3. Handle CloneNotSupportedException or throw it

4. Return the correct type by downcasting

Here’s the implementation of the Prototype pattern following this recipe:

public class Document implements Cloneable {
    private String title;
    private List<String> paragraphs;

    public Document(String title, List<String> paragraphs) {
        this.title = title;
        this.paragraphs = paragraphs;
    }

    @Override
    public Document clone() {
        try {
            return (Document) super.clone(); // Shallow copy
        } catch (CloneNotSupportedException e) {
            throw new AssertionError(); // This should never happen
        }
    }
}

✅ Pros: fast, native shallow copy, you can skip the manual work of copying each field

❌ Cons: This is shallow copying, which might violate the principle of least surprise (more on that later)

Option 2: Custom Copy (No Cloneable)

You implement your copy method manually and have full control of what you copy and follow the copying approach (deep or shallow) that best follows your needs:

public class Document {
    private String title;
    private List<String> paragraphs;

    public Document(String title, List<String> paragraphs) {
        this.title = title;
        this.paragraphs = paragraphs;
    }

    public Document copy() {
        return new Document(title, new ArrayList<>(paragraphs));
    }
}

✅ Pros: clearer, performs deep copy, no weird CloneNotSupportedException

❌ Cons: more manual work

📃 Shallow vs Deep Copy: Key Differences

Whether you're using Cloneable or a manual copy method, you can implement a deep or shallow copy of your objects. Understanding shallow vs deep copy is necessary:

Shallow Copy Example

Document original = new Document("My Title", new ArrayList<>(List.of("Intro", "Content")));
Document copy = original.clone();

copy.getParagraphs().set(0, "Modified");
System.out.println(original.getParagraphs()); // Prints: ["Modified", "Content"]

This happens because both Document instances share the same paragraphs list.

Deep Copy Example (with Cloneable)

@Override
public Document clone() {
    try {
        Document copy = (Document) super.clone();
        copy.paragraphs = new ArrayList<>(this.paragraphs); // Deep copy the list
        return copy;
    } catch (CloneNotSupportedException e) {
        throw new AssertionError();
    }
}

Now, modifying copy.paragraphs won't affect the original object.

This deep copy can also be achieved without Cloneable by writing a custom copy() method. The key is duplicating mutable fields to avoid shared references.

⚖️ Performance vs. Clarity: Should You Use super.clone()?

"The Principle of Least Surprise" says that code should behave in a way that minimizes confusion for those reading or using it. Users should not be surprised by how something works.

Cloneable in Java violates this principle because:

• It defines no methods, yet calling super.clone() depends on it.

• Forgetting to implement it leads to unexpected CloneNotSupportedException.

• Even when it works, it does a shallow copy by default, which can lead to shared internal state.

In short:

• super.clone() is fast but potentially confusing.

• Manual copy() methods are clearer and allow full control.

Use what fits your case:

• Go with clone() for speed and simplicity if you're confident about the structure.

• Prefer manual copies for clarity, immutability, and safe separation of state.

🔻 Disadvantages of the Prototype Pattern

1. Complex Cloning Logic: Deep copying can be error-prone and requires careful handling of nested objects, references, and circular dependencies.

2. Cloning Limitations in Java

   • Using clone() (especially in Java) may confuse developers unfamiliar with how shallow vs deep copies work.

   • Java’s Cloneable interface is considered flawed:

     • It lacks a clone() method in the interface.

     • Object.clone() is protected, requiring workarounds.

     • Doesn't support deep cloning out of the box.

3. Hard to Maintain

   • If objects evolve (e.g., new fields), developers must update the cloning logic, increasing maintenance effort and risk of bugs.

Conclusion

The Prototype Pattern lets you create new objects by copying existing ones. It can improve performance, simplify object creation, and reduce coupling to concrete classes.

You can implement it using Java's Cloneable interface and super.clone() or define your own copy methods:

• Use super.clone() when speed matters and your object is simple

• Use manual copying when clarity, immutability, or safety is more important

Choose the approach that best matches the complexity and goals of your project.

In this post, we’ll explore the Builder pattern through a fun and relatable example: building a custom sandwich.

1. What Is the Builder Pattern and When to Use It?

The Builder Pattern lets you separate object construction from its representation. It’s helpful when:

• You have a class with many parameters

• Some parameters are optional

• You want to make object creation readable and safe

• You want to avoid telescoping constructors (constructors with many overloads)

🍞 The Basic Recipe for the Builder Pattern

Before jumping into the full example, here’s a quick overview of how the Builder pattern is typically implemented:

Prerequisite: You have a class with many fields or complex configuration logic.

🔧 Steps:

1. In the enclosing class (the one with many fields), define a static nested Builder class.

2. In the Builder class, declare the same fields as in the enclosing class.

3. In the Builder constructor, set any required fields.

4. In the Builder, provide setter methods (e.g., setX(value)) for optional fields.

5. Ensure each setter returns this (the builder instance) so you can chain calls fluently.

6. In the Builder, implement a build() method that returns the final object.

7. In the enclosing class, create a private constructor that initializes its fields using the builder’s fields.

2. A Sandwich Builder Example

Let’s say you want to create a customizable sandwich with required and optional ingredients.

package design_patterns;

import java.util.List;

public class Sandwich {
    //required fields
    private final String breadType;
    private final String mainFilling;

    //optional fields
    private final String cheese;
    private final List<String> veggies;
    private final List<String> sauces;
    private final boolean toasted;

    private Sandwich(Builder builder) {
       this.breadType = builder.breadType;
       this.mainFilling = builder.mainFilling;
       this.cheese = builder.cheese;
       this.veggies = builder.veggies;
       this.sauces = builder.sauces;
       this.toasted = builder.toasted;
    }

    public static Builder builder(String breadType, String mainFilling) {
        return new Builder(breadType, mainFilling);
    }

    @Override
    public String toString() {
        return String.format(
            "Sandwich: \n- Bread: %s\n- Main Filling: %s\n- Cheese: %s\n- Veggies: %s\n- Sauces: %s\n- Toasted: %s",
            breadType,
            mainFilling,
            cheese != null ? cheese : "None",
            veggies != null ? veggies : "None",
            sauces != null ? sauces : "None",
            toasted ? "Yes" : "No"
        );
    }

    public static class Builder {
        private final String breadType;
        private final String mainFilling;
        private String cheese;
        private List<String> veggies;
        private List<String> sauces;
        private boolean toasted;

        public Builder(String breadType, String mainFilling) {
            this.breadType = breadType;
            this.mainFilling = mainFilling;
            this.veggies = List.of();
            this.sauces = List.of();
        }

        public Builder setCheese(String cheese) {
            this.cheese = cheese;
            return this;
        }

        public Builder setVeggies(List<String> veggies) {
            this.veggies = veggies.stream().toList();
            return this;
        }

        public Builder setSauces(List<String> sauces) {
            this.sauces = sauces.stream().toList();
            return this;
        }

        public Builder setToasted(boolean toasted) {
            this.toasted = toasted;
            return this;
        }

        public Sandwich build() {
            return new Sandwich(this);
        }
    }
}

And here’s how you would use it:

package design_patterns;

import java.util.List;

public class BuilderPatternExample {
    public static void main(String[] args) {
        Sandwich mySandwich = Sandwich.builder("Whole Wheat", "Chicken")
            .setCheese("Cheddar")
            .setToasted(true)
            .setSauces(List.of("Honey Mustard"))
            .setVeggies(List.of("Green Pepper", "Red Pepper", "Lettuce"))
            .build();
        System.out.println(mySandwich);
    }
}

3. Essentials That Make the Builder Pattern Work

• Private constructor: The Sandwich constructor is private so clients are forced to use the builder.

• Immutable fields: All fields in Sandwich are final, making the object immutable after construction.

• Required vs Optional Fields: Required fields are set in the builder constructor, while optional fields have setters.

• Static Builder class: Declaring Builder as a static nested class avoids needing a reference to the outer Sandwich.

• Fluent API: Each setter returns this to support method chaining.

• Extensibility: Easy to add more optional ingredients without changing the constructor signatures.

4. Pro-Level Improvements for a Great Builder API

• Static builder() method: Makes usage cleaner than new Sandwich.Builder(...).

• Defensive copying: Lists are copied using stream().toList() to prevent external mutation.

• Default values: Optional fields like veggies and sauces default to empty lists.

• Readable toString(): Custom toString() improves debuggability and demo value.

5. Real-World Examples of the Builder Pattern in Frameworks

The Builder pattern is not just a design exercise — it’s widely used in real frameworks and libraries to improve code readability and reduce constructor complexity.

🔧 Lombok (@Builder)

In Java, Project Lombok offers a @Builder annotation that auto-generates builder code for you. It’s great for data classes where you want clean, fluent APIs without boilerplate.

@Builder
public class User {
    private String name;
    private int age;
}

Usage:

User user = User.builder()
    .name("Alice")
    .age(30)
    .build();

🌱 Spring Framework

While Spring is best known for dependency injection, many Spring projects (like Spring Security, Spring Boot, and Spring Data) use builder-style APIs to configure components:

HttpSecurity http = ...;

http
  .authorizeRequests()
    .antMatchers("/admin/**").hasRole("ADMIN")
    .anyRequest().authenticated()
  .and()
  .formLogin()
    .loginPage("/login")
    .permitAll();

This fluent configuration style is inspired by the Builder pattern, providing clarity and flexibility when building complex object graphs.

☁️ AWS SDK (Java)

The AWS SDK uses the Builder pattern extensively to construct requests:

PutObjectRequest request = PutObjectRequest.builder()
    .bucket("my-bucket")
    .key("my-file.txt")
    .contentType("text/plain")
    .build();

This avoids long constructors and makes API usage expressive and maintainable.

6. Trade-Offs of the Builder Pattern

While the Builder pattern improves clarity and flexibility, it comes with a few trade-offs:

• Extra boilerplate: Writing a builder adds more code compared to using constructors or setters directly.

• Adds minor indirection: The object creation is split between the builder and the target class

• Not ideal for simple objects: For classes with only a few fields, the pattern may feel unnecessary.

Despite these, the Builder pattern remains a clean and scalable solution for constructing complex or immutable objects.

Conclusion

The Builder pattern brings fluency, clarity, and structure to object creation. It’s widely adopted in frameworks and libraries to improve the readability and flexibility of configuration.

This is one of those patterns that feels sweet and mellow — the trade-offs are minor compared to the flexibility you gain, especially when working with complex objects.

I hope that the next time you enjoy a good sandwich, you’ll think of the Builder pattern. Enjoy! 🥪!