DEV Community: Igor Fraga

Choosing Technologies: The Beauty and the Beast Trap

Igor Fraga — Fri, 12 Sep 2025 20:38:25 +0000

Software Architecture Unveiled: A Series by Igor Fraga

Hi everyone, Igor Fraga here. This is the fourth article of these series to unveil the challenges and the role of what we do as a Software Architect.

As an architect, one of my most important jobs is to choose technology. It is also one of the most dangerous jobs.

We always see new, exciting tools that promise to be fast and wonderful. I call these tools the Beauty.

But we also have old, reliable tools that we know will work. They may not be exciting, but they are strong. I call these the Beast.

It is a big mistake to choose the Beauty and forget the Beast. I know this because I've seen this mistake happened multiple times, also on a project with a very good team. Here is what happened.

The Story: The Dream of a Super-Fast System

Some years ago, a company called X (I'll not reveal the name here, of course) needed a new system to handle many events from thousands of users worldwide, integrating their platforms that until then, were separated.

The goal was to process these events very quickly, with very little delay. Our team was smart and experienced, but the architect thought a reactive Java system was the best way to do this.

The Beauty he wanted us to use was a technology called Project Reactor and Spring WebFlux. It promised amazing things:

It was non-blocking. This means it could handle many tasks at the same time without waiting. It would be much faster than old systems.
It used fewer resources. It could manage thousands of connections with only a few threads. The old way needed one thread for each connection.
The code was clean. It was a modern and simple way to write complex code.

The other choice was the Beast we knew very well: the classic Spring MVC. We used it for many of our other systems. It was strong and our whole team understood it.

The team was kind of skeptical about using reactive but the architect insisted on saying it was the only way to be fast enough.

I was worried it would be hard to learn and maintain but over all, if this paradigm were really necessary within a virtually all legacy arrangement.

But we had no choice, and he didn't listened to anyone, he just came out with a skeleton of the service so we should work above that.

So, let's build the modern, super-fast system.

The Problems Begin: When the Dream Becomes Hard

We built a small test system, and it was very fast. We were happy and thought we made the right choice.

Despite the learning curve and the complete coding paradigm shift, we've managed to make it out somehow.

But then, we started building the real system for production. That is when the problems started.

Debugging was a nightmare. The code was made of VERY long chains of operators. When there was an error, the error message was very hard to understand. It was difficult to see where the problem happened.
Other tools did not work well with it. We used many other tools for things like security and data. We found that these tools were not reactive. They were blocking. When we used them, they broke our new system’s non-blocking design.
There were new kinds of bugs. We had problems that were very hard to find. For example, the system would slowly use more and more memory, and then crash. We did not know why.

Our team stopped building new features. Instead, they spent all their time trying to fix these new, hard problems.

The beautiful, super-fast non-blocking code we wanted was now full of complex fixes and we were losing our hairs on it.

I'm not saying that the reactive programming is bad and should be avoided or that it doesn't works. What I'm saying that, for this case, it never made sense at all. It was a real nightmare without any real business benefit for this particular project.

The Solution: A Checklist to Help Us Choose Better

This bad experience taught me an important lesson.

Now, when I'm choosing tech stack, I use a simple framework to help me choose new technology.

It is not to stop new ideas.

It is to make sure we choose new ideas in a smart way that makes sense to each purpose.

Technology Checklist

1. Is it Ready and Stable?

Version: Is it a stable version (like 1.0 or higher)? Early versions can change suddenly. Take for instance, the disruptive changes from Spring AI M5 (milestone release) to final 1.0.0 GA public release.
Team Skills: Does our team already know how to use this? Or is it completely new for everyone? Consider specially the schedule and available time when looking at this.
Community: Is there a big community of users? A good community helps fix bugs and answer questions.

2. Does it Work with Our Other Tools?

Compatibility: Do our other important tools work well with this new technology?
Integration: Is it easy to connect with our systems for monitoring, security, and deployment?

3. Is it Easy to Learn?

Good Documentation: Is there clear documentation with good examples? Does it explain common problems?
Learning Time: How long will it take for our team to learn it well?

4. Is it the Right Choice for Our Project?

Good Fit: Is this technology a good solution for our specific problem? Or do we just think it is cool?
Small Test: Can we build a small test project first? This test should check the riskiest parts.
Backup Plan: If it does not work, is it easy to change to a different technology?

How you can decide

Today, when thinking about a new technology, follow three simple steps:

Use the Checklist: The team fills out the checklist together.
Build a Small Test: Building a small test project to check the most dangerous parts.
Write Down the Decision: Write down why the team chose it (both architect and developers, TOGETHER), what the risks are, and how they will be managed.

Final Thought

Choosing technology is about managing risk.

The Beauty of new tools is exciting, but they can be immature and risky.

The Beast of old tools is predictable and safe.

A good architect understands both.

They know the most important thing is that a system works well and the team can maintain it.

In the next article, we will talk about how to design systems that can change easily, like building with Lego blocks.

See you then!

The Architect Communication Challenge: Speaking Multiple Languages

Igor Fraga — Mon, 25 Aug 2025 14:53:02 +0000

Software Architecture Unveiled: A Series by Igor Fraga

Hi everyone, Igor Fraga here. This is the third article of these series to unveil the challenges and the role of what we do as a Software Architect. As a software architect, a big part of the job is translation. Not between human languages, but between roles: product managers speak in outcomes, developers in constraints, designers in flows, security in risk, and executives in priorities. When these “languages” don’t align, projects slow down—or fail.

Here’s a true-to-life story from a health-tech launch that shows how ambiguity around a single word—security—nearly derailed the timeline, and how we turned it around with simple tools and habits.

The Setup: One Word, Many Meanings

We were building a new feature for a health-tech platform: secure patient messaging between clinics and patients. Everyone agreed security was “critical.” But “security” meant different things to each group:

Product meant “users trust us; no scary headlines.”
Security team meant “no PHI leaks, strong controls, audits.”
Developers meant “auth is solid, data is encrypted, requests are safe.”
Legal meant “compliance with privacy laws and auditability.”
Design meant “simple, safe, not scary to use.”
Operations meant “we can detect incidents and respond fast.”

All reasonable. But because we didn’t define the word together, each team moved in a slightly different direction. That “slight” drift compounds fast.

The Misalignment Emerges

Two weeks before launch:

Product expected end-to-end encryption (E2EE) in the messaging feature.
Engineering implemented encryption in transit and at rest, with role-based access control—strong, but not E2EE.
Security assumed message redaction in logs and minimal retention; Ops had verbose logs with message snippets to debug issues quickly.
Design shipped a friendly “secure” badge with no explanation; Legal needed explicit consent text and retention policy visible to users.

Same goal, multiple interpretations. Our risk: delay the launch or ship something we’d need to rework under pressure.

The Reset: Define the Word Together

We paused. In a one-hour workshop, we agreed on the meaning of “security” for this feature, written in plain language with testable criteria.

Security definition for patient messaging (v1):

Data protection:
- TLS 1.2+ in transit; AES-256 at rest.
- No message bodies in logs; IDs and metadata only.
Access control:
- Only sender, recipient, and authorized clinicians can read messages.
- Support can access metadata for troubleshooting; message content access requires explicit, auditable approval.
Privacy and retention:
- Retain message bodies for 180 days (legal requirement X), then delete or anonymize.
- Users can request deletion; we honor within Y days.
Auditability:
- Every read/write is logged with user/service ID, timestamp, purpose.
- Alerting on anomalous access patterns.
UX:
- Clear security copy: what “secure” means, how data is used, and retention.
- Consent flow before first message; link to policy.
Out of scope (v1):
- End-to-end encryption.
- Message export by patients.

With this aligned definition, we could make decisions without guessing.

Tools and Habits That Keep Teams Aligned

We didn’t rely on “being careful.” We changed how we communicate.

Vocabulary Glossary

We created a living glossary for high-risk words: security, retention, consent, audit, incident, E2EE.
Each term had a one-line definition and acceptance test (how we verify it’s done).
We pinned this in our docs and Slack channel.

Architecture Decision Records (ADRs)

We wrote short ADRs for key choices:
- “No E2EE in v1; enforce encryption in transit/at rest, with audited content access. Rationale: supportability, time-to-launch, legal needs. Revisit in v2.”
- “Logs exclude message bodies. Rationale: minimize PHI exposure; add correlation IDs instead.”
ADRs made decisions visible and durable, so we didn’t re-argue them weekly.

Two Diagrams, Max

Context diagram: who can access what data paths (patient, clinician, support; services; storage).
Sequence diagram: “send message” and “read message,” with security controls marked at each step (authentication, authorization, encryption, logging).
We annotated diagrams with the glossary terms, e.g., “no bodies in logs.”

Regular Check-ins with Purpose

Weekly cross-functional “quality attributes” check-in (security, privacy, performance, reliability).
Agenda format:
- What changed?
- Risks detected?
- Decisions needed?
- Actions and owners.
30 minutes, timeboxed. The goal: detect drift early.

User-Facing Copy as an Artifact

We reviewed the exact text users would see: what “secure” means, what we store, how long we keep it, and how consent works.
This made legal, product, and design align on the same facts and tone.

Logging and Access Drills

We ran small drills:
- Verify logs don’t contain message bodies.
- Try to access content as a support user—ensure it’s blocked or requires explicit approval.
- Review audit logs to confirm “who read what, when, and why” is traceable.
Drills convert policy into confidence.

The Turnaround: From Confusion to Clarity

Once we aligned:

Engineering added a redaction layer to the logger and updated access policies.
Design adjusted the badge to link to a “How your data is protected” page.
Legal approved the consent flow and retention copy.
Security set alerts for unusual access and added a data retention job with reports.
Product updated the timeline with a small buffer to complete the drills.

We shipped on time—with fewer post-launch surprises—because we shared the same map.

Practical Templates You Can Reuse

Use these verbatim or adapt to your context.

Security Definition Template (per feature)

Data protection: [in transit], [at rest], [redaction].
Access control: [who can read], [who can’t], [approval path].
Privacy/retention: [duration], [user rights], [deletion SLA].
Auditability: [events logged], [alert thresholds], [review cadence].
UX: [copy], [consent], [policy links].
Out of scope (this release): [items].

Architecture Decision Record (ADR)

Title:
Context:
Decision:
Rationale:
Alternatives considered:
Consequences (positive/negative):
Review date:

Meeting Cadence

Weekly quality-attributes sync (30 min).
Agenda: changes, risks, decisions, actions.
Owner: architect or tech lead; recorder rotates.

Two-Diagram Rule

Context diagram with data boundaries and actors.
Sequence diagram for 1–2 critical flows with controls marked.
Keep both updated; remove obsolete diagrams.

Glossary Entry

Term: Security (Messaging v1)
Definition: [one sentence]
Acceptance test: [how we verify it’s true]
Owner: [role]
Next review: [date]

Communication Patterns That Scale

Say the quiet parts out loud: If a term has multiple meanings, pause and define it.
Prefer artifacts over memory: If it matters, write it down where everyone can see it.
Make decisions easy to find: ADRs prevent decision amnesia.
Show, don’t only tell: Diagrams reveal gaps words hide.
Close loops fast: Short, regular check-ins remove surprises.

Final Thought

Architecture is a team sport. My job is to help the team speak a shared language so we solve the same problem in the same way. Words like “security,” “performance,” or “MVP” are not self-explanatory. When we define them together, document decisions, and keep a steady rhythm of check-ins, we trade confusion for momentum—and ship with confidence.

In the next article, we will dive deep into a more technical subject that is key to the success of a project, "Choosing Technologies: The Beauty and the Beast Trap". Selecting the right tool for the job matters. Do you chase the new, shiny technology, or stick to the tried and tested? See you in the next post!

Translating Business Needs into Technical Solutions

Igor Fraga — Sun, 17 Aug 2025 15:57:36 +0000

Software Architecture Unveiled: A Series by Igor Fraga

Hi everyone, Igor Fraga here. This is the second article of these series to unveil the challenges and the role of what we do as a Software Architect. We are going to understand more about one of the key aspects of this role that is translating business into technical solutions. Here is where we start to draw from ideas, goals into a plan to build a concrete system that accomplishes it's goal.

Business leaders speak in goals. Developers think in systems and constraints. A software architect stands in the middle, turning goals into a clear, realistic plan the team can build. This work is not about fancy words—it’s about questions, choices, and shared understanding, and keep this word, UNDERSTANDING.

This work unfolds over a focused week with questions, experiments, and decisions. Here, I'm bringing how this process looks like, sometimes even more than a week depending on time responses and availability from the parts in my experience with these processes.

Let's explore this process with the story of the development of a real-time tracking feature:

Monday — Framing the Goal

9:00 AM. A product manager, Laura, brings a request:

“We need a new mobile feature: instant order tracking. Customers should see the courier on a map in real time. This will help retention and reduce support calls.”

This is a goal with a suggested solution. As an architect, the first step is to separate the goal from the implementation.

Business goal: improve retention and reduce support.
Hypothesis: real-time tracking will help.
Initial solution idea: show courier location on a live map.

I respond with curiosity, not with code:

What metrics will define success? (Retention + fewer support calls)
What is the deadline and why? (Marketing campaign next month)
Which user segments need this first? (Returning customers? All?)
What are the legal or security constraints? (Location data handling)

Defining success early avoids building the wrong thing fast.

By the end of the day, we agreed on success metrics:

Reduce delivery-status support tickets by 30% in 60 days.
Increase repeat purchase rate by 10% among users who use tracking in 90 days.

We aligned on a realistic plan: discovery and design this week; delivery planning next.

Tuesday — From Wish List to Requirements

We run a discovery session with product, design, support, and engineering leads. I guide the conversation to transform the “wish list” into actionable requirements.

We write the first version of the requirements as simple statements:

Must-have
- Show order status updates within 10s of change.
- Provide a map pin for courier location updated every 15–30s.
- Work on iOS and Android with the same API.
- Respect user privacy and allow opt-out of location sharing.
- Provide helpful fallback when courier location is unavailable.
Nice-to-have
- Precise route line on the map.
- Push notifications for major status changes.
- ETA predictions.
Out of scope (for now)
- Live chat with courier.
- Historical route playback.

Now we have clarity. Not perfect, but enough to start technical exploration.

The Right Questions

Before picking technologies, the architect validates constraints:

Data source: Do we get courier GPS from partners or our own app?
Frequency vs. cost: How often do we really need updates?
Scale: Peak concurrent tracked orders? Expected QPS (queries per second)?
Offline behavior: What happens when the app loses connectivity?
Privacy: How long do we store location data? Who can access it?
Failure modes: What do users see if couriers’ apps stop sending updates?

These questions prevent hidden risks from appearing late.

By the end of Tuesday, we had a refined requirement set and a risk list to guide the architecture.

Wednesday — Options and Trade-offs

I sketch three approaches and discuss trade-offs with the team.

Option A: Pure Pull (Client Polling)

Mobile app fetches tracking data every 15–30s.
Pros: Simple, easy to cache, lower server complexity.
Cons: Less “instant,” wasted requests when nothing changes.

Option B: Server Push (WebSockets or SSE)

Persistent connection for pushing updates in near real time.
Pros: Responsive, fewer unnecessary requests.
Cons: More complex infra, connection management, scaling challenges.

Option C: Hybrid (Push for status changes, Pull for location)

Push major status changes; poll for location at a steady cadence.
Pros: Good balance of cost and responsiveness; simpler than full push.
Cons: Slightly more moving parts; needs clear client logic.

Given the deadline and the need for predictable costs, we choose the Hybrid approach for version 1. It gives a “live” feel without building the most complex system first.

Thursday — The Concrete Design

We convert the chosen approach into a concrete, testable design.

Mobile App
- Poll location every 20s when the tracking screen is open.
- Receive push notifications for major status changes (picked up, near destination, delivered).
- Cache last known location for 2 minutes to handle brief drops.
- Show clear states: “Waiting for courier data,” “Last updated Xs ago.”
Backend Services
- Tracking API: GET /orders/{id}/tracking returns location, status, ETA.
- Event Service: publishes status-change events to push notification service.
- Integrations: adapters for courier partners; standardized internal model.
- Rate limiting and caching to protect core systems.
Data
- Store current location and last N updates (e.g., last 15 minutes) for troubleshooting.
- Anonymize or delete precise location after retention window.
- Audit logging for access to location data.
Security & Privacy
- Auth: only the authenticated buyer (or support with permission) can access tracking.
- Opt-out and consent flow for sharing location.
- Clear privacy policy and retention period.
Observability
- Metrics: update latency, API p95 latency, error rates, connection failures.
- Logging: anonymized tracing across adapters.
- Alerts: spikes in failures from any courier partner.
Fallbacks
- If live location is missing, show last known point with timestamp and a helpful message.
- If partner API is down, degrade gracefully: show status without map and notify support.

Friday — Delivery Plan, Risks, and Alignment

In the morning, along with the development team, we've turned the design into a delivery plan we could trust.

Milestone 1 (1–2 weeks):

Tracking API with mock data.
Mobile UI skeleton with polling and fallback states.
Push notification path for status changes.

Milestone 2 (2–3 weeks):

Integration with one courier partner.
Caching, rate limiting, and basic observability.
Privacy and consent flows in the app.

Milestone 3 (2 weeks):

Add a second courier partner and resilience handling.
Performance tests at expected peak.
Feature flag rollout to 10% of users.

We reviewed the risks and how we mitigate them:

Partner instability: contract tests, synthetic monitoring, circuit breakers.
Mobile background limits: adaptive polling; clear UX when the app is backgrounded.
Cost creep: usage caps, alarms, and tuning the polling cadence based on real usage.

In the afternoon, we ran an alignment session. I present a one-page architecture brief and two diagrams:

Context diagram: users, mobile apps, backend, partners, notifications.
Sequence diagram: user opens tracking screen → app polls → backend fetches → returns → status change triggers push.

I close with a simple story: “Maria orders dinner on the way home. She opens the app and sees ‘Picked up 3 minutes ago’ and a map pin moving every 20s. If the courier app pauses, Maria sees ‘Waiting for live data—last update 45s ago.’ She still feels informed. Support calls drop. Marketing has a solid feature to promote.”

The team nods. We have clarity, boundaries, and a path to value.

Reusable Toolkit: Questions and Templates

Keep these handy for future translation work:

Business Questions
- What specific outcome do we want? How will we measure it?
- What is the real deadline and why?
- Which user group gets this first?
Technical Questions
- What are the data sources and their reliability?
- What are the scale and cost targets?
- What privacy/security requirements apply?
Definition of Done
- Functionality meets must-haves.
- Observability in place (metrics, logs, alerts).
- Privacy and security checks complete.
- Rollout plan with feature flags and fallback.
Lightweight Artifacts
- One-page architecture brief.
- Context and sequence diagrams.
- Risk list with mitigations.
- Success metrics and tracking plan.

Final Thought

An architect’s value is not just in knowing frameworks or patterns. It is in making the path from idea to impact clear, safe, and achievable. By asking the right questions, shaping scope, and choosing balanced designs, architects turn big business goals into technical steps that teams can deliver with confidence.

We have seen a happy path of an architectural process to translate business into technical solutions. Most of the times, there are more back and forward on the definitions than explained here but the overall well established process looks much like this.

From my personal experience, many times I've been the architect and the development team, specially in startups, and other times, on bigger companies, I've worked with teams dealing with well defined roles as presented in this article, that is the ideal.

Both of these can happen to you, specially in the AI era where businesses believe that this tool is the holy grail and will solve everything magically (and that is not true at all) but you must need to know how to use it at your favor without any doubt of it.

Being a Software or a Solutions Architect is also to make business understand and participate of this process as much as possible, speaking on their own language.

That's why my next article is about "The Communication Challenge: Speaking Multiple Languages" and how you communicate with the Project Manager, the CEO, CTO and the development team is completely different and that is KEY to your success as a Software Architect.

See you on the next article!

What Does a Software Architect Actually Do?

Igor Fraga — Fri, 15 Aug 2025 12:33:41 +0000

Software Architecture Unveiled: A Series by Igor Fraga

Welcome to a series of articles meant to shine a light on the everyday life of a software architect. My goal is to bridge the gap between complex architectural topics and practical, real-world examples. Each article focuses on a key aspect of the role, told with stories and lessons that are immediately useful.

If you noticed, I've rebranded the blog to bring you much more content about the architect role that is part of the everyday live of a software architect, along with the technical content and career that I usually share.

So, let's get started with our very first article:

What Does a Software Architect Actually Do?

If you ask someone on a software team, “What does a software architect do?” you might get a confused answer. Some might say, “They’re the most senior developer.” Others may say, “They decide how our systems are built.” There’s truth in both, but the real role goes deeper.

Guiding the Technical Ship

Let’s imagine a story.

A group of friends wants to start an e-commerce company. They have a great idea: a platform where small local sellers can easily open online shops. The budget is tight, and the timeline is even tighter. The team hires developers, designers, and someone with the title “Software Architect.” Let’s call her Ana.

Most people on the team write code every day. Ana does too, but she spends a lot of her time doing something different—she listens.

She listens to the business founders talk about goals:

“We must launch before Christmas!”

“We expect 10,000 users in the first month!”

“We absolutely can’t lose any customer data!”

Then, she talks with the developers:

“What framework will let us move quickly?”

“How do we keep the platform secure?”

“What will happen if traffic doubles?”

Drawing the First Map

Ana’s most important work happens before the first line of code is written. She creates a map for the project—just like a captain charts the course before the ship sails.

This map is called the architecture:

What pieces need to be built? (Shopping cart, user accounts, payment processing…)
How will these pieces talk to each other?
Where is data stored?
How will they grow if thousands of users join overnight?

Ana chooses the structures and technologies that make sense for the team’s skills and the company’s goals. Maybe she recommends using a cloud provider, so the website can handle big traffic spikes. Perhaps she picks a simple, secure payment system because speed and safety are crucial.

Making Hard Choices

Sometimes, the business wants everything perfect and fast—but that’s impossible. Ana explains that to add new features later, the foundation must be solid now. She draws a line between “must-have” and “nice-to-have,” making sure the team is focused.

Once, in this e-commerce story, a founder says:

“I want video reviews from buyers, right from launch!”

Ana explains: “That would need lots of servers for video storage. Let’s start with text and photo reviews, and add video later when we’re ready.”

By saying “no” to some requests, Ana keeps the project realistic and on schedule.

Communication: The Secret Ingredient

Good architects are also translators. Ana writes clear documents and draws simple diagrams. Developers understand where their code fits in the bigger picture, testers know what to check, and business leaders see how their goals are being built in, and the way you talk to each of these groups, from business to developers, is completely different.

For example, when Ana shares a big diagram showing all the parts—and which are most important for launch—everyone feels calmer. The road ahead is clearer.

Responsible for the Big Picture

When the website finally launches, and people start shopping, Ana is still there. If bugs appear or traffic surges, she works with the team to fix things—always thinking about how today’s solution will impact tomorrow.

She teaches the team to ask, “How will this change affect everything else?” She helps make the system strong, secure, and able to grow.

In Summary

A software architect is more than a senior developer.

They are map-makers, guiding teams safely through unknown waters.
They listen, translate, and make hard choices.
They focus on the big picture, so every part works together smoothly. And while you may not always see them writing code, you always feel their impact—through systems that are strong, clear, and ready for the future.

In my next article, we’ll see how architects help business and tech teams speak the same language, and why that matters so much.

See you in the next post!

Finding Your Own Voice in the Tech Community

Igor Fraga — Wed, 02 Apr 2025 19:26:34 +0000

Hello everyone, Igor Fraga here resuming the posting series after an amazing "The Developers Conference" that happened some days ago! We will talk about that in a separated post, showing you some pictures and sharing my experience of being a speaker at that event, and today's post is related to this subject, about Finding Your Own Voice in the Tech Community.

Today, we will continue with the series of posts from Interviewing Java Champions, from the interview with Elder Moraes, writer, mentor and Java Champion. This is the seventh post from this series.

During our episode of The Out of the Box Developer podcast, in our conversation, we have explored the idea of finding your own voice as a developer in the tech community. In a world full of content and opinions, it's important to stand out and share your unique perspective.

Elder shared his thoughts with us on how to develop a distinctive voice. He explained, "your voice is what makes you unique. It's about sharing your authentic perspective, your experiences, and your way of seeing the tech world."

I believe that finding your voice is essential for building a strong personal brand. As I discussed with Elder, "when you have your own voice, people connect with you on a deeper level. They are not just hearing information; they are hearing you. This is what makes you stand out from the others or from AI generated content" - I added*.*

Here are some ways we discussed to find and develop your own voice in tech:

Be Authentic: Share your genuine thoughts and experiences. Don't try to be someone you're not.
Focus on Your Strengths and Interests: Talk about topics you are passionate about and knowledgeable in. Your enthusiasm will shine through.
Share Your Personal Experiences: Your unique journey and experiences are valuable. Share your successes, failures, and lessons learned.
Develop Your Own Style: Experiment with different writing styles, presentation styles, or video formats to find what feels natural and effective for you.
Engage in Conversations: Participate in discussions, share your opinions, and respond to others in the community. This helps you refine your voice and connect with others.

Elder encouraged us, "don't be afraid to be yourself and share your unique perspective. Your voice matters, and there's an audience out there who wants to hear what you have to say."

Embrace your individuality and let your authentic voice be heard in the tech community.

Sadly, we are reaching closer to the end of this amazing series. In the next and last post from this series from the interview with Elder, we will talk about “Finding Your Audience as a Tech Content Creator", and the hints that Elder brought to us on this subject.

If you didn’t watched the whole interview, you can do it clicking here.

If you like this content, don’t forget to subscribe to my mail list to receive it first-hand by clicking here

See you in the next post!

Simplifying Multi-line Strings with Text Blocks in Java

Igor Fraga — Fri, 21 Mar 2025 18:38:05 +0000

Hello, Java developers! I'm Igor Fraga, and I'm back after a short pause of some days that I've been busy with the book I'm writing (I will bring it here very soon)

This is the third post from a series called “The upgraded Java Developer” about the latest Java programming language enhancements to be up to date and use these features in your daily work. We will look into some enhancements Java had during these last years regarding String handling before jumping into more advanced stuff.

Today we're exploring Text Blocks, a feature that has revolutionized how we handle multi-line strings in Java. Introduced as a preview feature in Java 13 and standardized in Java 15, Text Blocks are now a robust part of Java 21, offering a cleaner and more intuitive way to work with complex string literals.

What are Text Blocks?

Text Blocks are a new way to represent multi-line string literals in Java. They allow you to write strings spanning multiple lines without the need for most escape sequences or explicit line breaks.

How Text Blocks Work

Here's an example of how to use a Text Block:

    String json = """
        {
            "name": "John Doe",
            "age": 30,
            "city": "New York",
            "hobbies": [
                "reading",
                "swimming",
                "hiking"
            ]
        }
        """;

In this example, the Text Block is denoted by triple quotes (""") and preserves the formatting of the JSON structure.

Why are Text Blocks Better?

Compared to traditional string concatenation, Text Blocks offer several advantages:

Improved Readability: They eliminate the need for escape characters and string concatenation operators.
Preserved Formatting: The structure of the text is visually represented in the code.
Reduced Errors: Fewer escape sequences mean fewer opportunities for syntax errors.
Better Maintainability: Updating multi-line strings becomes much easier.

Best Practices

Use Text Blocks for multi-line strings like SQL queries, JSON, HTML, or any formatted text.
Be mindful of indentation, as it affects the resulting string.
Use the \ character at the end of a line to suppress the following new line if needed.

Conclusion

Text Blocks, fully supported in Java 21, represent a significant improvement in how we handle multi-line strings in Java. They make our code cleaner, more readable, and easier to maintain, especially when dealing with structured text formats like JSON, SQL, or HTML.

In our next article, we'll explore String Templates, that is the evolution of Text Blocks that has been introduced in Java 21 and how it has evolved from String concatenation, to Text Blocks and finally into String Templates. See you then!

How to (NOT) be a boring Tech speaker

Igor Fraga — Fri, 14 Mar 2025 21:35:43 +0000

Hello everyone, Igor Fraga here for another exciting post! Today, we will continue with the series of posts from Interviewing Java Champions, from the interview with Elder Moraes, writer, mentor and as I've mentioned, Java Champion. This is the sixth post from this series.

I am tired of seeing boring presentations that almost make me sleep, so this is a great advice to not fall on the trap that "my content is awesome and that's what matter the most". NO, IT'S NOT, if you are boring as hell, nobody cares how much awesome can be your content.

That's why we will discuss about how to create an awesome tech presentation that is engaging and transforming at the same time.

In our conversation on The Out of the Box Developer podcast, we have talked about giving presentations in the tech world. For many developers, presenting can be nerve-wracking, but it's a valuable skill for career growth and knowledge sharing.

Elder shared some great advice with us on how to create presentations that really connect with a tech audience. He mentioned, "when you're presenting to developers, remember they want to learn something practical and useful. Focus on clear explanations and real-world examples."

I agree that understanding your audience is key. As I discussed with Elder, "tech audiences appreciate presentations that are well-organized, get to the point, and offer actionable insights they can use in their own work."

Here are some tips we discussed for creating effective tech presentations:

Know Your Audience: Think about who you are presenting to. What are their skill levels and interests? Tailor your content to their needs.
Focus on Practical Value: Developers want to learn things they can actually use. Emphasize practical takeaways and real-world applications of your topic.
Keep it Clear and Concise: Avoid jargon and overly complex language. Use clear and simple explanations.
Use Visuals Effectively: Diagrams, code examples, and demos can make your presentation more engaging and easier to understand. Don't just rely on slides full of text.
Practice, Practice, Practice: Rehearsing your presentation helps you feel more confident and ensures a smooth delivery.

Elder emphasized: "don't try to impress people with fancy slides or complex theories. Focus on delivering valuable information in a clear and engaging way."

Google I/O Conference

We also discussed how to keep your audience interested and engaged during tech talks. It's not enough to just have good content; you also need to connect with your audience.

He said, "engagement is about making your audience feel like they are part of the conversation. Ask questions, encourage interaction, and make it a two-way street."

I believe that audience engagement is crucial for a successful presentation. As I mentioned to Elder, "a presentation shouldn't be just you talking at people. It should be a conversation with people, even in a large setting."

Here are some techniques we discussed for engaging your audience during tech talks:

Ask Questions: Start with questions to gauge the audience's knowledge and interest. Ask questions throughout your presentation to keep them thinking and involved.
Use Polls and Interactive Tools: Tools like polls and quizzes can make your presentation more interactive and fun.
Tell Stories and Use Real-Life Examples: Stories and examples make your topic more relatable and memorable.
Encourage Q&A: Make sure to leave plenty of time for questions and answers. This is a great way to address audience concerns and deepen understanding.
Move Around and Use Body Language: Don't just stand behind the podium. Move around the stage and use gestures to keep the audience engaged visually.

Elder advised us, "don't be afraid to step outside of your slides and interact with the audience. A little bit of interaction can make a big difference in keeping people engaged."

And I totally agree, this is something that I tend to do a lot, to look a people eyes, see their reaction and look to establish this connections that goes much beyond just information transfer. And don't ever get nervous with that, use that information to know how much more you will interact with your audience to get then engaged.

By using these engagement techniques, you can create a more dynamic and impactful presentation experience.

Last time I told you guys that this was the last post of this series. Well, I lied, we had sooooo much awesome subjects in this interview that I will continue with some more posts and bringing the highlights of this interview here. And our next subject will be "Finding Your Own Voice in the Tech Community" with the insights I had and the tips from Elder on this subject.

If you didn't watched the whole interview, you can do it clicking here.

If you like this content, don't forget to subscribe to my mail list to receive it first-hand by clicking here

See you in the next post!

The all-new Switch Case with steroids in Java 21

Igor Fraga — Tue, 11 Mar 2025 16:09:04 +0000

Hello, Java developers! I'm Igor Fraga, and this is the second post from a series called “The upgraded Java Developer” about the latest Java programming language enhancements to be up to date and use these features in your daily work.

Today we're diving into two powerful features that have revolutionized how we handle conditional logic in Java: Switch Expressions and Pattern Matching for Switch. Both features have evolved significantly since their introduction and are now fully supported in Java 21.

Wow, you will have it all in a single post, isn't that great?

Sure it is, you will find everything you need to know here, so let's get started!

What are Switch Expressions?

Switch Expressions allow the switch construct to be used as either a statement or an expression. They introduce a new, more compact syntax and eliminate common pitfalls associated with the traditional switch statement.

Before Switch Expressions

Before Java 12, achieving similar functionality required more verbose code:

// Traditional switch statement
String day = "MONDAY";
String typeOfDay;
switch (day) {
    case "MONDAY":
    case "TUESDAY":
    case "WEDNESDAY":
    case "THURSDAY":
    case "FRIDAY":
        typeOfDay = "Weekday";
        break;
    case "SATURDAY":
    case "SUNDAY":
        typeOfDay = "Weekend";
        break;
    default:
        typeOfDay = "Invalid day";
        break;
}

How Switch Expressions Work

Here's an example of how to use Switch Expressions:

String day = "MONDAY";
String typeOfDay = switch (day) {
    case "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY" -> "Weekday";
    case "SATURDAY", "SUNDAY" -> "Weekend";
    default -> "Invalid day";
};

In this example, we use the new -> syntax to directly yield a value for each case. The switch construct is now an expression that returns a value.

As you can see, Switch Expressions offer a more concise and readable syntax.

Using the Yield Keyword

For more complex cases where you need to execute multiple statements, you can use the yield keyword:

String result = switch (day) {
    case "MONDAY" -> {
        System.out.println("It's Monday!");
        yield "Weekday";
    }
    case "SATURDAY", "SUNDAY" -> "Weekend";
    default -> {
        System.out.println("Invalid day provided.");
        yield "Invalid day";
    }
};

In this example, the yield keyword is used to return a value from a block of code within a case.

Why are Switch Expressions Better?

Compared to traditional switch statements, Switch Expressions offer several advantages:

Conciseness: They allow multiple cases to be handled in a single line.
Safety: They enforce exhaustive handling of all cases, reducing bugs.
Expressiveness: They can be used in contexts where an expression is expected.
No Fall-through: Each case is self-contained, eliminating accidental fall-through errors.

Evolution from Java 12 to Java 21

Switch Expressions were first introduced as a preview feature in Java 12. In Java 14, they became a standard feature. Java 21 fully supports them and introduces additional pattern matching capabilities (which we are going to cover in the next lines).

Best Practices

Use Switch Expressions when you need to assign the result of a switch to a variable.
Prefer the -> syntax for simple, single-line cases.
Use the yield keyword for more complex cases that require multiple statements.

Next, we're exploring Pattern Matching for Switch, a powerful feature that has evolved since its preview in Java 17 and is now a standard feature in Java 21. If you're used to Java 8, this enhancement will significantly change how you handle complex conditional logic in your code.

Revolutionizing Conditional Logic with Pattern Matching for Switch

Pattern Matching for Switch extends the capabilities of the switch statement and expression by allowing patterns in case labels. This feature enables more expressive and concise code when dealing with complex data structures and type-based comparisons.

Pattern Matching for Switch allows you to check not just simple values, but also types of objects and their contents. It's like a smarter, more powerful switch statement.

Here's an example of how to use Pattern Matching for Switch:

static String describeShape(Shape shape) {
    return switch (shape) {
        case Circle c -> "Circle with radius " + c.radius;
        case Rectangle r -> "Rectangle " + r.width + " x " + r.height;
        case Triangle t -> "Triangle with base " + t.base + " and height " + t.height;
        case null -> "No shape";
        default -> "Unknown shape";
    };
}

In this example, we use type patterns to match against different subclasses of Shape, extracting their properties directly in the case label.

Pattern Matching for Switch also supports the when clause for additional conditional refinements within a case. Here's an example:

static String describeRectangle(Rectangle rectangle) {
    return switch (rectangle) {
        case Rectangle r when r.width == r.height -> "Square with side " + r.width;
        case Rectangle r -> "Rectangle " + r.width + " x " + r.height;
        case null -> "No rectangle";
        default -> "Unknown shape";
    };
}

In this example, we use the when clause to check if the rectangle is a square (i.e., its width equals its height). This allows us to provide more specific handling for certain conditions.

Before Java 17, achieving similar functionality required more verbose code:

// Traditional if-else chain
static String describeShape(Shape shape) {
    if (shape instanceof Circle) {
        Circle c = (Circle) shape;
        return "Circle with radius " + c.radius;
    } else if (shape instanceof Rectangle) {
        Rectangle r = (Rectangle) shape;
        return "Rectangle " + r.width + " x " + r.height;
    } else if (shape instanceof Triangle) {
        Triangle t = (Triangle) shape;
        return "Triangle with base " + t.base + " and height " + t.height;
    } else if (shape == null) {
        return "No shape";
    } else {
        return "Unknown shape";
    }
}

As you can see, Pattern Matching for Switch offers a more concise and readable syntax.

Why is Pattern Matching for Switch Better?

Pattern Matching for Switch offers several advantages:

Conciseness: It reduces boilerplate code, eliminating the need for explicit type checks and casts, so no need to add tons of instanceof and casts anymore to validate the types.
Type Safety: The compiler ensures exhaustive matching, reducing the risk of runtime errors.
Readability: Complex conditional logic becomes more straightforward and easier to understand.
Flexibility: It allows matching against types, constants, and even null values in a unified syntax.

Evolution from Java 17 to Java 21

Pattern Matching for Switch has evolved through several preview versions:

Introduced as a preview in Java 17 (JEP 406)
Refined in Java 18 (JEP 420) and Java 19 (JEP 427)
Further enhanced in Java 20 (JEP 433)
Finally standardized in Java 21 (JEP 441)

Each iteration brought improvements based on community feedback, resulting in a more robust and versatile feature.

Best Practices

Use Pattern Matching for Switch when dealing with complex type hierarchies or data structures.
Leverage the null case for explicit null handling.
Combine with record patterns for even more powerful data extraction.
Use the when clause for additional conditional refinements within a case.

Conclusion

Switch Expressions and Pattern Matching for Switch in Java 21 represent a significant leap forward in Java's ability to handle complex conditional logic. They make our code more expressive, safer, and easier to maintain, especially when working with polymorphic types or intricate data structures.

In our next article from this series, we'll explore Text Blocks, another feature that has greatly improved string handling in Java. Stay tuned to learn how this feature can make working with multi-line strings a breeze!

The right language to share Tech Content

Igor Fraga — Mon, 10 Mar 2025 15:27:36 +0000

On The Out of the Box Developer podcast, we talked about something important for people who create tech content like me:

What language should you use to reach the most people?

I asked Java Champion Elder Moraes if only using English might stop some people from seeing my content, especially developers who don't speak English as their first language.

This is the fifth post from a series bringing you insights from the interview with Elder Moraes, Java Champion, Red Hat Advocate, Mentor and Writer.

Elder shared some helpful ideas with us about this.
He said, "English is like the main language of the tech world now. If you publish in English, you can reach a very big audience all over the world."

We know that some people might not be able to understand English easily, but he also talked about what is realistic when you are creating content.

During our talk, I asked Elder if only using English could be a problem for developers around the world who could learn from tech content. I wondered if I might be missing out on reaching some people by not using other languages.

Elder's answer to us was very thoughtful. He explained, "It would be great to reach everyone in their own language, but it's often hard for one person or a small team to do that. Making content in many languages takes a lot of time and effort."

He also talked about why using English is helpful, saying, "because so many people in tech use English, most developers can understand tech content in English, even if it's not their first language. So, using English is a practical way to reach as many people as you can with the resources you have."

That's why I write my articles and content mainly in English and you can use the resources in igorfragadev.com blog to read my articles in any language if you don't fully understand it.

However, Elder also gave us some other things to think about:

Think about who you want to reach: Who are you trying to talk to? If you want to reach people in a specific area who speak a certain language, then using that language might be very good. This is specially true when you are giving in person talks at a non-English country, for example.
Start with English and add more languages later: If you want to reach people everywhere, English is a good place to start. When you have more time and help, you can think about translating your best content into other languages.
Use translation tools: Tools that translate languages can be useful, even if they are not perfect. You can use them to add subtitles to videos or translate blog posts like you have here at igorfragadev.com blog.
Join groups with people who speak other languages: Be active in online groups where developers who speak different languages meet. This can help you connect with more people, even if your main content is in English.

Elder finished by saying to us, "there's no single right answer for everyone. It depends on what you want to do, what you can do, and who you want to talk to. English helps you reach a lot of people, but it's always good to think about different languages and how to make your content easier for more people to understand."

In the end, our talk showed that choosing a language for your tech content is an important decision. English can help you reach a huge audience, but thinking about different languages and finding ways to help people understand your content can help you reach even more developers around the world.

If you didn't watched the whole interview, you can do it clicking here.

In the next and last post from this series from the interview with Elder, we will talk about "Creating Engaging Tech Talks Presentations, in a special post and the hints that Elder brought to us on this subject.

If you like this content, don't forget to subscribe to my mail list to receive it first-hand by clicking here

See you in the next post!

Enhancing Collections with Sequenced Interfaces in Java

Igor Fraga — Sat, 08 Mar 2025 14:23:07 +0000

Hi and welcome, Igor Fraga here!

Today I'm starting a series of posts called "The upgraded Java Developer" about the latest Java programming language enhancements for you that are old school Java like me and for you that are learning to program in Java as well, to be up to date and use these features in your daily work.

Each article from these series will bring new language resources that came to make our lives much easier, enhance performance and evolve the Java language, so Java is not the ugly duck anymore that guys from other languages liked to complain about.

It has evolved considerably these last years and with this series you will learn in a easy to understand approach and how to apply in practice everything that is presented here. We will be covering the evolution since Java 8, going through the many version changes until the latest LTS version by the time of this writting that is Java 21. So, let's get started!

Today we're exploring Sequenced Collections, an exciting feature introduced in Java 21. If you're used to Java 8, this addition will significantly improve how you work with ordered data structures.

What are Sequenced Collections?

Sequenced Collections are a set of new interfaces added to the Java Collections Framework. They provide a uniform way to work with collections that have a defined encounter order, such as lists, sorted sets, and linked hash sets.

How Sequenced Collections Work

Here's a simple example of how to use a Sequenced Collection:

SequencedCollection<String> sequenced = new ArrayList<>();
sequenced.addFirst("First");
sequenced.addLast("Last");
sequenced.add("Middle");

System.out.println(sequenced.getFirst()); // Outputs: First
System.out.println(sequenced.getLast());  // Outputs: Last

SequencedCollection<String> reversed = sequenced.reversed();
System.out.println(reversed.getFirst()); // Outputs: Last

In this example, we use new methods like addFirst(), addLast(), getFirst(), and getLast() which are now available on collections that implement the SequencedCollection interface.

Why are Sequenced Collections Better?

Sequenced Collections offer several advantages:

Consistency: They provide a uniform API for working with ordered collections.
Simplicity: Accessing first and last elements is now straightforward across different collection types.
Reversibility: The reversed() method allows easy creation of a reverse view of the collection.
Enhanced Functionality: New methods like addFirst() and addLast() add flexibility to collection manipulation.

New Interfaces in Java 21

Java 21 introduces three new interfaces:

SequencedCollection: For collections with a defined order.
SequencedSet: For sets that maintain insertion order.
SequencedMap: For maps that maintain a specific entry order.

Conclusion

Sequenced Collections in Java 21 represent a significant improvement in how we work with ordered data structures. They simplify common operations, enhance readability, and provide a more intuitive API for developers working with collections that have a defined order.

In our next article, we'll explore Pattern Matching for switch, another powerful feature that has evolved Java's syntax. Stay tuned to learn how this feature can simplify your conditional logic!

The most important programming language in 2025

Igor Fraga — Tue, 04 Mar 2025 21:04:35 +0000

Hi there, Igor Fraga here, so...

Do you know which is the most important programming language in 2025?

Java?

People say that Java is dead for almost 20 years and there are still plenty of people making millions from it.

But it's not Java...

So, maybe Python?

Because of all the AI revolution, this should be the one, right?

Nah... it's growing significantly in the last years but this is still not the MOST important one that you SHOULD dedicate in 2025.

So, which one is it, then?

The answer may surprise you...

....

It is.........

English!

What are you talking about? It's not even a programming language?

Are you sure about it?

What are you typing when you're writing code?

I'm pretty sure it's not binary..... 01110011... (the machine does that for you by interpreting what you code)

If you are a non-native English speaker, you must dedicate to learn more and more on how to communicate better in English

Both written and spoken.

Because this is the global language, either for reading documentations, forums, learning from tutorials (written or recorded), to deal with foreign customers, doing interviews, presentations or even to communicate during that travel you've ever dreamed about across the world.

You will find much more content in English online than in any other language

But your whole career growth also depends on how much you dedicate on this subject.

No matter how good you are technically, if you don't speak English, you will be limited to a certain region that maybe, will not provide the grow you're seeking for your life and career

And limit you to content in your own language only

Because when you are in a interview, or in a stage presenting to people, the translator will not be there for you...

But you can use it before to learn as much as you can

So, if you are a tech guy or girl and wanna conquer the World in 2025

Learn, breathe, practice and speak English, my friend!

In the next post, I'll bring some insights regarding to Sharing Tech Content in English that came from the interview with the Java Champion Elder Moraes.

See you then!

Becoming an AI-augmented developer (and why you have to)

Igor Fraga — Wed, 26 Feb 2025 18:18:42 +0000

Hi everyone, Igor Fraga here! We recently had a really interesting live talk on the Out of the Box Developer podcast. It was called "How to become an AI-augmented developer" and we talked about how AI is changing how we code. We had some great experts who explained how AI is becoming a big part of software development. I want to share the main points we talked about, so you can learn how to use AI to improve your coding!

Here's what we discussed:

1. Think Like an AI-Augmented Developer (It's Important!)

We started by talking about what it means to be "AI-augmented." As we said in the live stream, it's important to know this isn't just a short trend. It's not just about being an AI engineer or a regular coder. It's something new and very important. We said that using AI is key to staying up-to-date in tech today. AI isn't going to replace us, but it's like a helper that makes us better developers, making us faster and more skilled.

2. AI Tools on Your Computer: Using Local AI

I was really happy to talk about local AI tools. Luis Real showed us cool tools like Ollama, which lets you use AI models on your own computer, and CodeGPT, which works inside your IntelliJ IDE. We also talked about how well these tools work and what computer parts you need. Like I mentioned, if you want local AI to run well, a good graphics card like the RTX 3090 suggested by Douglas is a good idea.

3. Cloud or Local AI: Which is Best?

We spent time comparing cloud AI services (like GitHub Copilot and Cursor) with local AI models. We looked at the good and bad of each. We talked about saving money, different uses – like making images that aren't controlled or when company rules limit cloud use – and following rules and laws. We suggested using private AI servers for a whole company, and we discussed if that was possible.

4. AI Makes You Faster and Helps Fix Code

Pedro Cavalero explained how AI is becoming more and more involved in coding. He talked about different levels, from not using AI at all to being a full AI engineer. Then, he showed us GitHub Copilot's "agent mode," which is really amazing. It can do things automatically like write code, test it, and even fix mistakes! We all agreed AI tools are great for changing code to be better (refactoring) and doing boring tasks automatically. This lets us focus on the more important and creative parts of coding.

5. AI in Action: Real Examples

To show how AI works, Pedro did a live demo! He made a snake game in Python using Pygame, with help from Copilot. It was incredible to see AI write code and help solve problems right there and then. We also looked at testing code and how AI can fix errors, showing how AI can improve our coding process. We brought up using AI in big projects with lots of code, which led to a good talk about how to do that.

6. Future Coding: "Vibe Coding" and AI Teams

Looking to the future, Douglas talked about "Vibe Coding." I think this is where coding is going – imagine just telling AI what to do with your voice or by typing! We also talked about how AI can help smaller teams, or even single developers, do as much as big teams. This is a big change in how teams work and how much they can do. Like I said in the stream, if you want to be a good developer in the future, you need to use AI.

7. Learn Tools and Keep Learning: Your Next Steps

The experts gave clear advice: don't try to learn every AI tool at once. Instead, focus on learning one or two well to become good at using AI. We told everyone to try out tools like Cursor and Copilot to see what works best for them. And, like I always say, learning never stops! AI is changing fast, so we need to keep learning.

8. Worries and Doing Things Right: Think About Ethics

We also talked about some problems. We discussed if new developers might rely too much on AI, and not learn how to find and fix problems themselves. We know that AI tools aren't always right – they can sometimes give wrong answers, so we still need to check their work. And, of course, we talked about important ethical things like following rules, keeping data safe, and using AI in a good way.

9. Tool Suggestions: Cursor, Copilot, and Good AI Models

We suggested some specific tools. Cursor was mentioned as a really good one, especially for finding code and using tools. We talked a lot about GitHub Copilot, including its agent mode and different model choices. We also mentioned Claude 3.5 Sonnet models as great for coding and working well.

10. Last Words: Start Using AI Now!

To finish, we all agreed on a strong message. Start using AI tools now! Use them to code faster and stay ahead. Like I advised, start simple, try the basic things, and then explore the more advanced AI features. Becoming an AI-augmented developer is a journey, and it means always learning and changing in the tech world.

Main Point: Our live stream on Out of the Box Developer gave you a simple guide for becoming an AI-augmented developer. By using these tools, always learning, and carefully adding AI to your work, you can become much more productive and creative in the age of AI.

If you missed the live stream, or want to watch it again, you can find it here below. Let me know what you think, and which AI tools you are excited to try!

https://igorfragadev.com/becoming-an-ai-augmented-developer-and-why-you-have-to/

See you in the next post!