DEV Community: Call Me Izzy

Are you attending The 2026 NYC Tech Week? If so, Model Context Protocol (MCP) is a concept you are going to come across constantly. If you’ve never heard of it or haven't worked with it yet, I’ve got you covered.

Call Me Izzy — Thu, 04 Jun 2026 10:53:39 +0000

Call Me Izzy

Jun 4

A Crash Course in MCP: A Beginners Guide Using TypeScript

#typescript #mcp #programming #ai

4 min read

A Crash Course in MCP: A Beginners Guide Using TypeScript

Call Me Izzy — Thu, 04 Jun 2026 10:38:47 +0000

This post is adapted from my presentation, "A Crash Course in MCP: A Beginners Guide Using TypeScript"

The tech industry frequently relies on heavy jargon to explain simple concepts. If you read the official documentation for the Model Context Protocol (MCP), it states: "An open-source standard for connecting AI applications... Think of it like a USB-C port for AI applications."

While accurate, this isn't the most intuitive mental model for software engineers.

For me, the way that it made sense was giving it a more practical definition:

MCP is a set of rules that defines how to feed context into a model.

It allows your AI agent to understand your application's underlying data and architecture. Instead of manually typing out JSON payloads or navigating UIs, you can use natural language commands to execute complex functions because the agent already has the context of your system.

The Three Pillars of MCP

The protocol operates on three core primitives:

Resources: Anything that holds data. This could be a static JSON file, an HTML document, or a connection to a PostgreSQL database.
Tools: Executable functions. These are the actions your MCP server exposes to the AI agent, allowing the agent to manipulate data or interact with external services.
Prompts: Pre-defined instructions attached to the agent that utilize the available resources and tools to accomplish specific tasks.

Building an MCP Server in TypeScript

If you have ever built a basic server using ExpressJS, the architecture of an MCP server will feel highly familiar. You define a server, establish its capabilities, and expose endpoints (resources or tools).

However, building for AI agents introduces a unique challenge regarding data integrity.

The TypeScript limitation: TypeScript is fantastic for developer experience, but its types are stripped away at compilation. At runtime, your server executes vanilla JavaScript.
The AI variable: When an LLM dictates the input based on natural language, you cannot rely on compile-time checks to ensure the data structure is correct.
The Solution: We must use runtime validation libraries like Zod.

If your tool expects an age parameter as a number, but the LLM inputs the string "twenty-five", Zod catches the schema violation at runtime, preventing the malformed data from corrupting your database or crashing your service.

Defining Tools and Metadata

When creating a tool—such as a function to create a new user—you must define strict metadata. This dictates how the LLM interacts with the function:

readOnlyHint: Set to false if the tool modifies data (e.g., creating a user) rather than just fetching it.
destructiveHint: Set to true only if the tool can delete or irrevocably alter data.
idempotentHint: Defines whether running the identical command multiple times yields the same state without unintended side effects.

By defining these parameters, you establish guardrails around what the AI can and cannot execute autonomously. During development, you configure the client to ask for manual authorization before the agent is allowed to execute write commands.

From Basic JSON to Real-World APIs: The Google Calendar Integration

While testing an MCP server against a local JSON file is good for learning, the true power of the protocol unlocks when interacting with authenticated external APIs.

I built a custom MCP server connected to the Google Calendar API. It handles the OAuth and JSON token authentication, granting my local AI agent direct access to my personal schedule.

Here’s a two-minute demo showcasing my Google Calendar MCP project.

Because the agent has the context of the calendar API via the MCP server, I can execute commands using strictly natural language:

Querying: I can ask the agent, "What do I have for September 21st?" The agent reads the MCP resource and returns: "Your calendar includes NYC Code & Coffee: A Crash Course in MCP."
Executing: Instead of manually filling out event forms or writing API requests, I can tell the agent, "Create an event: Going for dinner with my wife on October 22nd." The agent maps the natural language to the required parameters (Title, Start Time, End Time) and executes the tool. The event immediately populates in Google Calendar.

The Reality of AI Tooling

The integration of LLMs directly into local environments and backend systems is not a passing trend; it is a fundamental shift in software engineering. We are moving toward natural language as an execution layer.

As a developer, you face a distinct choice: learn how to build and control these agentic tools to automate your workflows, or compete against the engineers who do.

Let's Connect!

Website: callmeizzy.dev
YouTube: Call Me Izzy
GitHub: @MrItzreal
X / Twitter: @fullstackizzy
LinkedIn: Israel (Izzy) Santana

A basic to-do app won't get you hired in 2026. I wrote about my real struggles as a dev, pivoting from MERN to Java/Spring Boot, and why I prioritize System Design over LeetCode. Read my breakdown below...

Call Me Izzy — Tue, 26 May 2026 19:43:41 +0000

Call Me Izzy

May 26

My Struggles as a Software Engineer in 2026

#learning #softwareengineering #writing #networking

4 min read

My Struggles as a Software Engineer in 2026

Call Me Izzy — Tue, 26 May 2026 19:37:03 +0000

This post is adapted from my YouTube vlog, "My Struggles as a Software Engineer in 2026!"

I started my journey to become a software engineer two years ago, and the landscape has shifted dramatically since then. One of the most persistent struggles I have faced while trying to break into the industry is the constant feeling of never being good enough or knowing enough. Imposter syndrome is real, and it is a battle I have fought from day one.

When I first started, my goal was simple: learn React, JavaScript, MongoDB, and PostgreSQL, and build a project. I felt a massive sense of pride after building my first two projects. However, the reality of the New York City job market quickly set in.

I noticed a saturation of MERN stack developers.
I realized that knowing React alone would not be my gateway into a solid software engineering role.
I needed to make myself highly useful to an organization, which meant diving deep into backend development.

Choosing the Right Backend Language

I debated between Go and Java for a long time. After analyzing the market on platforms like ZipRecruiter and Indeed, and speaking with industry professionals, a clear pattern emerged. Entry-level opportunities for Golang developers were virtually non-existent, whereas the market showed more opportunity for Java developers.

Once I committed to Java, I was introduced to Spring Boot and Docker containers. This fundamentally shifted how I approached application development.

Development Approach	Methodology
Frontend-First (Past)	Build the UI first. Once the visuals are set, write the logic to support it.
Backend-First (Current)	Wireframe and break down the feature logic first. The UI is built on top of a fully realized architecture.

This backend-first approach makes significantly more sense to me now. By the time I get to the frontend, I already know exactly what the feature must do, making full-stack development much smoother.

Escaping Tool Fatigue with "The Izzy Stack"

The tech industry is relentless. Every day, there is a new tool, a new model, or a "game-changing" framework. Chasing every trend is the fastest way to guarantee you will never feel competent.

To combat this overwhelm, I decided to lock into a specific tech stack, become proficient in it, and only test new tools briefly before integrating them if they truly add value. I refer to my core setup as The Izzy Stack:

Frontend: React, TypeScript, and Tailwind CSS.
Backend: Java, Spring Boot, PostgreSQL, and Supabase.

Switching between frontend and backend development was initially quite challenging, but with time, I gradually became proficient in both areas.

React and TypeScript handle the visual UI (managing state and effects), while Java requires building services, DTOs, and controllers. The implementation details are vastly different, but mastering both domains is necessary for the next level of growth.

System Design vs. LeetCode

In the pursuit of improvement, I evaluated whether to focus on Data Structures and Algorithms (DSA) or System Design.

Honestly, in 2026, grinding LeetCode makes little sense to me when modern AI models can instantly solve those problems. While I understand that some companies still require DSA for interviews, you will rarely use those specific academic puzzles in daily backend work.

System design, however, immediately clicked. I recently picked up System Design Interview by Alex Xu.

Within the first twelve pages, I was learning vital concepts I had never encountered:

Database replication
Vertical and horizontal scaling
The critical role of load balancers in managing web traffic

If your target companies require DSA, you must study it. But for the type of backend systems I want to build, system design provides significantly more practical value.

The Reality of the 2026 Job Market

Let's be honest: the 2015–2020 hiring boom is over.

You can no longer build a simple tic-tac-toe or to-do list app and expect to land a job. The bar has been raised. Recently, I built an entire asynchronous video analysis pipeline using Java, Spring Boot, Supabase, React, TypeScript and various LLMs.

The system ingests video input.
It analyzes the presentation for filler words and body language.
It evaluates the content and overall delivery against professional speaking standards.

Despite the complexity of the project, I still feel the pressure to improve. I have secured multiple interviews thanks to an incredible network of mentors and peers, but converting those interviews into offers remains a challenge. I have received various reasons for why things haven't followed through, which can be frustrating.

However........

All we can do is focus, lock in, and keep building. Opportunity will come. An organization will take a chance on me, and I will maximize that opportunity just like I did during my internship at Archetype Dynamics. So, if you’re navigating this market with me, understand that every rejection is just one step closer to a "yes."

Let's keep grinding.

Let's Connect!

Website: callmeizzy.dev
YouTube: Call Me Izzy
GitHub: @MrItzreal
X / Twitter: @fullstackizzy
LinkedIn: Israel (Izzy) Santana

Zero to Full-Stack in 6 Months: The Izzy Way...

Call Me Izzy — Wed, 20 May 2026 14:20:30 +0000

TL;DR

This post is adapted from my 2024 YouTube video, "Learned To Code In 6 Months!". Since the original recording, I have evolved as a developer and expanded my technology stack beyond the initial scope discussed here.
Dedicated 6 months to studying full-stack development, Monday through Friday, 6:30 AM to 4:00 PM.
Managed distractions using the Pomodoro technique and physically removing my phone from the workspace.
Learned almost entirely via free YouTube tutorials, avoiding "tutorial hell" by actively building.
Built a complex first project ("Nissan Experience") to force hands-on learning.
Leveraged AI (Gemini) as a mentor for concept breakdown, alongside real-world guidance from Dorian (@doriandevelops).
Maintained mental health through strict weekend breaks, attending NYC Code & Coffee meetups, and heavy weightlifting.

Greetings from the future. This is Izzy, writing to you from the year 2026. The following article is a time capsule detailing exactly how I learned full-stack development in just six months back in 2024.
_

My name is Izzy, and over the past six months, I executed a dedicated roadmap to learn full-stack development. This is not a heavily edited, polished fairy tale. It is an objective breakdown of my schedule, the technologies I adopted, the struggles I faced, and the strategies that kept me disciplined.

1. The Study Schedule and Discipline

Creating a routine puts discipline on autopilot. My standard study schedule was Monday through Friday, 6:30 AM to 4:00 PM. On the three days a week I went to the gym focusing heavily on progressive overload for my chest, shoulders, triceps, and legs, I concluded my study sessions at 3:00 PM.

Rigid Study Schedules

Pros: Automates decision-making; guarantees a high volume of deep work; sets clear boundaries between "work" and "life."
Cons: Can induce severe guilt when life inevitably disrupts the routine; high risk of burnout if breaks are not strictly enforced.
Potential Pitfalls: Confusing "hours logged" with "actual learning." Staring at a screen for 9 hours is useless without active coding.
Conclusion: A rigid schedule is necessary, but it must be paired with mandatory time off. I absolutely do not study on weekends, forcing myself to step away and reset.

2. Environment Architecture: Beating Distractions

To combat context switching, I removed my phone entirely, placing it across the room and relying on an Apple Watch strictly for critical alerts. For desktop distractions, I implemented the Pomodoro method using an always on top window timer.

The Pomodoro Technique

Pros: Forces regular breaks to prevent cognitive fatigue; gamifies deep work; prevents endless scrolling.
Cons: Can arbitrarily interrupt a deep "flow state" right when a complex bug is being solved.
Potential Pitfalls: Becoming a slave to the timer.
Conclusion: The structure is invaluable for maintaining focus over an 8-hour day, provided you allow flexibility when deep in the zone. Listening to synth-wave Lo-Fi music (like Lo-Fi Girl) also served to anchor my focus without the distraction of lyrics.

3. Financial Reality

Transparency is critical. I am able to study full-time because of an agreement with my wife. For three years, I financially supported us while she completed an intense physician assistant program. Once she secured her role as a PA, we flipped the script, allowing me to quit my job and pursue software engineering full-time.

4. Resource Allocation and "The Izzy Stack"

I learned 99.9% of my foundation through free YouTube tutorials, starting with HTML, CSS, and a comprehensive "50 Projects in 50 Days" vanilla JavaScript course.

Fast forward to 2026, my learning path solidified into what I proudly call...

The Izzy Stack:

Frontend: React, TypeScript, Tailwind.
Backend: Java, Spring Boot, PSQL, Supabase.

Relying on Free Video Tutorials

Pros: Zero financial barrier to entry; diverse range of instructors and teaching styles.
Cons: Information is often fragmented, outdated, or lacks enterprise-level best practices.
Potential Pitfalls: Falling into "Tutorial Hell," where you passively consume content without writing your own code. If a 2-hour tutorial takes you exactly 2 hours to finish, you did not learn anything.
Conclusion: Tutorials are only valid if you constantly pause, break the code, and rebuild it yourself.

5. Mentorship and AI as a Learning Tool

Learning in a vacuum is dangerous. I reached out to Dorian (@DorianDevelops), who provided actionable, game-changing direction: stop doing tutorials, start building a full-stack project, and network immediately. I also utilized Gemini as a daily tutor to explain complex topics.

Using AI for Code Learning

Pros: On-demand, 24/7 explanations of granular concepts; excellent at breaking down documentation.
Cons: AI frequently hallucinates or suggests deprecated syntax; it can become a crutch.
Potential Pitfalls: Copying and pasting AI-generated code without understanding it, leading to a brittle codebase and failed technical interviews.
Conclusion: AI should be treated strictly as a mentor, not an employee. Never implement code you cannot personally explain from scratch.

6. Project-Driven Learning: The ("Nissan Experience")

Following Dorian's advice, I built a full-stack application as my first major project a tribute platform to Nissan vehicles featuring Stripe integration and a relational database.

Building a Full-Stack App as Project #1

Pros: Forces a holistic understanding of how APIs, databases, and client interfaces interact; generates a highly impressive resume asset.
Cons: The learning curve is brutal. Concepts like environment variables, Git workflows, and API security hit all at once.
Potential Pitfalls: Quitting out of sheer frustration when connecting the database or setting up authentication.
Conclusion: It took me three months and involved deep frustration, particularly with JavaScript logic, but the trial by fire approach accelerates true engineering comprehension better than building ten simple calculator apps.

7. Community and Next Steps

Coding in isolation breeds anxiety, especially given current market conditions. Finding a local community is non-negotiable. I consistently attend Code & Coffee in NYC, which has been instrumental in networking with data scientists, product managers, and fellow engineers.

Moving forward, I am limiting myself to three high-complexity projects this year, diving deeper into TypeScript, AWS, and eventually LeetCode. The market is tough for juniors, but the only controllable variable is the daily consistency of showing up.

🛠️ Let's Connect!

Website: callmeizzy.dev
YouTube: Call Me Izzy
GitHub: @MrItzreal
X / Twitter: @fullstackizzy
LinkedIn: Israel (Izzy) Santana