joacod | Blog

What I Learned Building My Own AI Harness

Fri, 22 May 2026 00:00:00 GMT

Last month I spent some time building nano-harness, a small personal AI harness.

Not a framework, not the final agent platform that will replace everything and save humanity, or whatever people are saying this week.

Just a local-first desktop app to understand how these systems actually work when you stop talking about agents in abstract terms and start connecting the pieces yourself.

That was the real goal. I wanted to learn the shape of the thing. Provider adapters, local state, runs, tool calls, approvals, events, sessions, memory ideas, MCP, skills, all the boring plumbing behind the nice demos.

And like it usually happens, the project went further than planned.

The app runs on Electron, can be packaged for macOS, Linux, and Windows, has a local database (SQLite), a core runtime, provider abstractions, a run inspector, approval boundaries, and the beginning of a few bigger ideas that are still unfinished or behind feature flags.

Which is fine.

It was never supposed to become a huge product. It was a learning project, and I have a lot of fun building it.

Now I think it is time to wrap it up.

The Main Thing

The most useful thing I got from this project is not that AI can write code, we already know that. The useful part was seeing again how far you can go when you combine good software architecture with a good AI assistant.

No magic there. The assistant helps a lot. It keeps momentum, writes boring implementation details, moves code around, catches mistakes, proposes tests, and makes it easier to keep going when the project has too many small pieces.

But the assistant is not the architecture.

That part still matters, and honestly I think it matters more now, because AI makes it very easy to produce code faster than you can think about whether that code belongs in the right place.

If the structure is bad, AI helps you make the bad structure bigger. If the abstractions are confused, AI extends the confusion. If every feature leaks into every layer, the assistant will not save you from that, it will just help you create a more impressive mess.

But if the structure is clear, AI becomes much more useful.

In nano-harness, the important abstraction was the run.

A run is just a bounded attempt to satisfy one user request. It has messages, provider calls, actions, policy decisions, approvals, events, and persisted state. Nothing fancy, but that one idea makes the rest of the app easier to reason about.

That is the kind of abstraction I like. Not abstract because it sounds smart, abstract because it reduces the number of things you need to keep in your head.

The rest was the usual discipline:

the desktop app owns the UI
the core owns orchestration
the infra layer owns side effects
the shared package owns contracts

Nothing revolutionary, just useful, and useful beats clever almost every time.

The Buzzwords Get Smaller When You Build

There are a lot of words around AI development right now. Agents, harnesses, skills, MCP memory, spec-driven development, self-improving systems, context engines.

Some of those ideas are real, some are overloaded, some are early, and some are mostly marketing, until you try to build the small version and realize what they actually require. That is why I wanted to build my own version.

Not because nano-harness is better than mature tools. It is not. I use other tools every day, but building the small version gives you a different kind of knowledge. You stop treating the concept as magic and start seeing the cracks.

A provider is an adapter.
A tool call is a contract, an input schema, an execution boundary, and a result.
Memory is storage, recall, ranking, confidence, provenance, approval, and deciding what should not be remembered.
MCP exposes resources and tools, and immediately creates questions about filtering, credentials, safety, and context bloat.
Skills are reusable workflow packages, and the hard part is knowing when to inject them and when to leave the model alone.

Once you see it that way, the field becomes less intimidating and more interesting. It also becomes obvious that many of the hard parts are still the same old software engineering problems.

Boundaries, contracts, state, observability, safety, UX, debuggability, maintainability.

Same old friends, different interface.

The Tools

For the actual coding workflow, my tool of choice is still opencode.

I have tried almost everything at this point, and opencode is the one that feels best to me. It is open source, it is not trying to trap me inside one company, and it fits the way I like to work. That matters more to me every month.

For models, I used a combination of GPT-5.5 for planning and GPT-5.4 for execution. And this project reinforced something I already believed, once the plan is good enough, a lot of models can do useful execution work.

The quality of the plan matters a lot, if you ask the model to design the architecture, implement the feature, refactor the code, infer all missing context, and test everything at the same time, sometimes it works. Many times it creates very convincing nonsense.

I had better results when I used stronger models for planning, architecture, and review, and cheaper or local models for simpler execution tasks.

For some parts I even used a local model with MLX, specifically Qwen3.6-35B-A3B. Very impressive for its size.

No, it is not GPT-5.5 or Opus 4.7, it is not the model I would pick for the hardest architecture decisions. But if I showed myself one year ago that a local model could perform this well on real coding tasks, I probably would not believe it.

And that changes something.

Local Is Not a Toy Anymore

I have no doubt that the strongest models will stay inside big companies for a long time, and they will be useful for specific high-value tasks.

But a lot of normal work does not need the biggest possible model. A lot of company workflows are repetitive, structured, private, and full of local context. For that kind of work, open models and local execution are going to be enough in many cases.

That is not only a cost argument, although cost matters a lot with all the crazy pricing changes around AI tools lately. It is also a privacy argument.

We have sold our information very cheaply for a very long time. Maybe we should not repeat the same mistake with every repo, every document, every customer workflow, and every internal decision we feed into AI systems. Maybe we should do it better this time.

At least that is what I want to believe. This is why I keep paying attention to local inference with llama.cpp and MLX. Not because local models are always better, they are not. Because knowing when a local model is enough is becoming a real advantage.

Some useful skills for future engineering are model routing, workflow design, cost control, privacy boundaries, and knowing which model to use for which job.

Less sexy, much closer to real engineering.

What It Actually Taught Me

The most useful part of nano-harness was thinking about the abstractions.

What belongs in the core?
What belongs in infra?
What should be a local artifact?
What should be persisted?
What should require approval?
What should be visible in the UI?
What should never become a primitive too early?

That last one matters a lot. A lot of software gets worse because we promote ideas into primitives too fast.

You add one workflow, then another, then another, and suddenly the core knows about everything. Specs, memory, skills, projects, providers, UI modes, files, shell commands, and half the roadmap. Then every change becomes risky because every layer depends on every other layer.

I wanted to avoid that. So the rule became “keep the core small and boring”.

Most things should be compositions of existing primitives: runs, actions, policy, events, context, and local artifacts.

Spec-driven development does not need to be a new core. It can be a workflow built on runs.

Memory does not need to be shoved into every layer. It can be proposed from evidence and recalled with provenance.

Skills do not need to become a marketplace. They can start as local markdown packages.

MCP does not need to take over the product. It can sit behind filtering, inspection, and approval.

That was the fun part, not because the code is perfect, it is not. But because the project kept forcing small architectural decisions where I had to choose between adding power and preserving clarity. That is the real game.

Wrapping It Up

I am wrapping this project up now.

There is a lot more that could be done. A proper Spec Workbench, better memory, stronger skills, real MCP transport, better packaging, better docs, more benchmarks, a cleaner onboarding flow. Maybe a real release.

But not every project needs to become a product. Sometimes a project has already done its job when it changed how you think, nano-harness did that for me.

It made me more confident building AI-assisted tools. It made me more confident in my own architecture instincts. It gave me a clearer picture of what these harnesses are under the hood. And it reminded me again that every MVP leaves knowledge for the next one.

That knowledge compounds. Every time you finish something, even something small or unfinished or weird, the next thing starts from a better place.

There has never been a better time to try ideas, AI lowers the cost of exploring, refactoring, testing, and learning by doing. You can move faster, but you still need taste, judgment, know when to stop, and you still need to review the code and care about quality. No shortcuts.

Experiment, build the thing, fail a little, refactor, write down what you learned, repeat.

The best is yet to come.

Context Is Not Memory, It Needs an Engine

Fri, 17 Apr 2026 00:00:00 GMT

In my previous article, Human Code Review Is Not the Last Frontier, I argued that human code review is not the final bottleneck.

Underneath that argument was something deeper, one of the real bottlenecks in agent-native engineering, the missing context.

Not context in the vague sense people usually mean when they say, “just give the model more information”. I mean real engineering context. The kind that tells you whether a change is actually correct or just looks correct for five minutes in isolation. The kind of context that lives in old pull requests, half-forgotten migrations, team decisions, outdated assumptions, scattered docs, local workarounds, and painful experience inside a codebase that has been evolving for years.

That is usually the difference between a change that compiles and a change that actually belongs.

A repository is never just its current code. It also contains what the system is trying to move away from, what is still in progress, which ugly pattern still exists for a reason, which assumptions used to be true but should not be repeated, which workaround only makes sense in one corner of the system, and which apparently harmless area is actually fragile. Humans recover that knowledge over time because they have lived through the system, talked to the people around it, reviewed old changes, and seen things break.

Agents do not.

They only work with what is surfaced to them, and most of the time that context is incomplete, stale, too generic, or trapped in the wrong place. That is why I do not think this problem will be solved by simply adding more notes, writing a better prompt, or relying on a memory feature and hoping it behaves like judgment.

If context is one of the real bottlenecks in agent-native engineering, then it probably needs something more serious.

It needs its own system.

Context Is Not a Sidecar Problem

A lot of current AI workflows still treat context like a sidecar. Something attached to a prompt. Something kept in a rules file. Something the tool “remembers”. Something dumped into documentation and hoped to stay fresh.

That can help, I use those things too, but they do not solve the core issue.

The real problem is not whether context exists somewhere. The real problem is whether that context is current, scoped correctly, relevant to the task, and surfaced at the right moment in the workflow.

That is a very different problem, it is not mainly a storage problem, it is a context quality problem, because context has lifecycles.

Context can be global and durable, or narrowly tied to a single repository. It may only matter during a migration, carry enough confidence to shape implementation, or stay weak and temporary because it comes from recent observations that could stop being true next week. Certain context matters most during planning, while other context only becomes important during debugging or validation. And once a transition is over, some of it should stop influencing future work entirely.

Once you look at it that way, context stops being just text, it becomes living information.

And living information needs to be managed, not merely stored.

Why Memory Is the Wrong Mental Model

This is why I do not think context should be treated as memory.

Memory sounds passive, it suggests something you keep around and occasionally recall, something helpful but secondary, something sitting off to the side. That is not enough.

What I am describing is an operational system.

That distinction matters because an operational system participates in the workflow. It can be maintained, revised, ranked, scoped, and delivered when needed. The point is not just to retain context somewhere in the background. The point is to make it usable.

This is also why “more memory” is not automatically better. A pile of remembered notes is still a pile. If context is stale, weak, conflicting, badly scoped, or poorly timed, then surfacing more of it may make the workflow worse, not better.

The challenge is not accumulation, the challenge is usefulness.

Why Raw Files Are Not Enough

This is where the idea starts to become more concrete, I am not talking about saving more notes, I am talking about giving engineering context a canonical system of record.

Not because markdown is bad, but because raw files alone are a weak foundation for something that has scope, freshness, confidence, lineage, version history, review state, conflict states, and natural decay over time.

If context has that kind of lifecycle, then the system behind it should be able to understand things like:

where a piece of context applies
how trustworthy it is
what generated it
whether it conflicts with something newer
whether it is still active
whether it should continue influencing future work
whether it represents a preferred path or a known anti-pattern

Those are not minor details. They are part of what makes context usable.

This is why I think the missing piece is not memory, and not documentation with better search. The missing piece is an engine, a system capable of ingesting, classifying, refining, and retrieving context in a way that matches real engineering work.

The important part is not storage, it is the engine. The storage layer is not the differentiator, the engine is.

Storage matters only because it gives the system structure, but structure alone is not what solves the problem. What matters is what sits on top of that structure.

A useful context system should be able to notice when a new piece of context overlaps with something already known. It should recognize when a previous assumption has started to decay. It should understand that a repository-specific rule should not be treated as a global one. It should learn that a certain implementation path repeatedly gets corrected by humans. It should preserve not only what worked, but also what repeatedly failed or had to be revised.

That last part matters a lot.

A good system should not only remember successful patterns, it should also surface negative knowledge, what to avoid, what keeps breaking, what looks reasonable but repeatedly turns out to be wrong in this specific codebase.

That is one of the biggest gaps in current workflows. Agents are often good at producing plausible work. But plausible is not the same as correct, and it is definitely not the same as locally correct inside a messy, evolving system.

What they are missing is not always capability, they are missing the context that actually matters.

Internally Rich, Externally Simple

One of the most important design principles here is simple: internally rich, externally simple.

Internally, the system should be sophisticated. It should use structured storage, lifecycle management, ranking, revision logic, conflict handling, freshness scoring, and retrieval logic that can adapt to different stages of work.

Externally, though, it should stay simple.

Most agent workflows already consume text extremely well. Prompts, notes, handoff files, planning docs, constraint summaries, migration notes, contextual briefs. That part already works. So instead of forcing every harness, assistant, IDE, or workflow to understand a complicated internal schema, the engine can do the hard work inside and return the result as markdown.

That is the abstraction.

Internally, the system manages context properly. Externally, it delivers one or more markdown artifacts that can be consumed almost anywhere.

That could mean a brief for a quick task, a planning pack for riskier work, migration notes when a system is in transition, recent learnings for debugging, known risks during validation. The exact filenames do not matter, what matters is that the output remains simple enough for almost any workflow to adopt without friction.

That simplicity is not a compromise, it is part of the design.

If every team needs schema awareness, special adapters, and deep knowledge of how the engine thinks, then adoption becomes harder right where the system should be disappearing into the background. The workflow should not need to care how context was stored, promoted, revised, merged, or archived. It should just ask for the right context and receive a clean package.

Why This Matters Now

This matters because the real world is not going to standardize around one assistant, one IDE, one orchestration layer, or one company workflow.

Different teams use different tools, different companies have different processes, different repositories have different levels of entropy, different tasks need different amounts of context at different moments.

So if this idea only works when everything is redesigned around it, then it is already weaker than it should be.

But if the internal system stays rich and the external interface stays simple, then the same engine can plug into planning, implementation, debugging, validation, CI loops, pull request preparation, or longer autonomous workflows without forcing everyone into the same stack.

The workflow asks for context, the engine returns markdown, the agent consumes it.

That is much more realistic.

The Missing Layer

This is the missing layer I was pointing at in the previous article.

When I said human code review is not the last frontier, part of what I meant was that the real frontier is not simply whether agents can generate more code. It is whether they can operate with the kind of context that real engineering work actually depends on.

Not generic context, not bloated context, not stale context, useful context.

Context that knows where it applies, whether it is still true, how strong it is, what it conflicts with, and when it should stop influencing future work. Context that can be maintained instead of forgotten. Context that appears when it matters, instead of arriving as noise.

That is why I think this deserves its own layer.

Not another memory feature, not a prompt trick, not markdown folders pretending to be a system. A real “Context Engine”, internally structured enough to manage context properly, and externally simple enough that almost nobody consuming it needs to care how it works.

They just get a usable context package.

And honestly, that is not a small implementation detail, it is the whole point.

Closing Thought

As agents get better at generating code, the bottleneck becomes easier to see. The issue is often not raw capability, it is contextual correctness.

That is why I think context needs something more deliberate behind it, not passive memory, not loose documentation, not a bigger pile of notes, an engine.

Because the difference between work that looks right and work that is right often lives in all the things the code alone does not tell you. And if those things are becoming one of the main constraints on agent-native engineering, then they should not remain scattered across prompts, docs, habits, and human memory.

They should have a real system behind them.

Human Code Review Is Not the Last Frontier

Mon, 09 Mar 2026 00:00:00 GMT

I found these two articles very interesting: The Self-Driving Codebase and How to Kill the Code Review.

And to be clear, I don’t think they are totally wrong, I think they are pointing in the right direction, but I also think they jump too fast from “this is where things are going” to “we are almost there”.

That is the part I don’t buy.

I’m not anti-AI and I don’t think agents are just hype either. I try tools, I use them, I see what works and what not. The progress is honestly better than many people think.

But software engineering in the real world is harder than the clean version of the story, that is my problem with a lot of this conversation.

When people talk about autonomous agents writing software, they often talk as if the main thing left is removing the human from code review. As if once the agents take care of that and humans stop reviewing every diff, then software development becomes mostly an automation problem.

I don’t think that is true, I think human code review is not the last frontier, I think it is just the last visible step in a much bigger mess, because most real codebases are a mess.

And I mean that in the most normal, boring, everyday way that anyone with enough years in software has seen many times.

The Reality

Big codebases are full of technical debt. They have different coding styles because hundreds of people touched them over the years, lots of “temporary changes” that were supposed to be improved later and became permanent, dead code because the business changed direction three times, bad abstractions because someone tried to generalize too early, weird edge cases because one big customer needed something five years ago and the company never removed it, missing tests, outdated docs, unclear ownership, and I can go on and on.

So when I read ideas like “review the spec, not the code” or “kill the code review”, I get the point, the current review process does not scale well if agents start producing much more code than humans can read, that part is fair. But in many teams, code review is doing more than checking code quality, it is where people bring context back into the change.

The reviewer knows that this ugly part of the system exists for a reason, that another team depends on a strange behavior that nobody documented, that this small looking refactor touches something fragile, which part of the code is annoying but harmless, and which part looks harmless but can break production.

That knowledge is often not written down anywhere, not in the tickets, not in the docs, not in the tests, not in the spec.

A lot of engineering work is not just implementing a clear idea, but discovering what the idea actually means while building it. You start with a requirement, and then you find out:

it was incomplete
it ignored an old system
it breaks an edge case
it creates a performance problem
it conflicts with another team’s flow
it sounds simple at the product level but is messy at the data level

So I think some of these arguments assume a cleaner world than the one most engineers actually live in. If we consider that AI currently amplifies any existing structure, we are not in the best of scenarios, and this is where I separate the future from the hype.

The Future

Yes, this is probably the future, agents will keep getting better, human code review as we know it will probably matter less over time.

But that doesn’t mean we are close to autonomous software engineering, and even less so in environments where software is hardest: large companies, old systems, regulated industries, critical user facing products, codebases with years of debt and weak ownership. That is a different game.

What works inside a frontier AI company does not automatically work inside a financial institution, that does not mean the frontier companies are faking it (well… at least not all of it), it means their environment is different. They are building the models, shaping the tools, and creating workflows around this new way of working.

But the average company is not in that position. Most companies are not working with clean systems, top tier internal tooling, strong documentation, fast decision making, and teams built around agent workflows. Most companies are still trying to survive their own complexity.

Software Engineering

Writing code is only one part of software engineering, and not even the hardest part. The hard part is working inside messy systems with incomplete context, unclear requirements, old decisions, conflicting constraints, and real consequences if something goes wrong.

That is where things still break down, to me, that is the real frontier, not code review by itself, the real frontier is judgment, context, knowing what matters in this codebase in this company at this moment, knowing when a change is technically correct but still wrong for the system, knowing what to ignore, what to clean up, what to leave alone, and what risk is acceptable.

And that my friends, is what software engineering really is. This is the point that gets lost when the discussion becomes too abstract. Because once you leave the world of demos, mvps, benchmarks, and greenfield projects, software is not just a code problem. It is a history problem, a people problem, a maintenance problem, a tradeoff problem, and I didn’t even talk about scalability, maintainability, security and many more important topics.

Where we are

I am not arguing for a conservative view where nothing changes, a lot is already changing, I just think we should be honest about where we really are.

We are getting better at automating code production, we are not yet equally good at automating the deep context that real software engineering depends on.

That is why I don’t believe human code review is the last frontier. It’s the last place where human judgment shows up before the code lands. A deeper frontier is whether that judgment can be made clear enough, structured enough, and trusted enough that the system no longer depends on humans carrying it in their heads.

Maybe we’ll get there, I don’t know, or how we’ll address the problems I mentioned.

But from where most of the industry stands today, we may be on the way, but we certainly are not there yet, it’s not the same thing and it makes a big difference.

My Personal Blog Is Finally Live

Wed, 18 Feb 2026 00:00:00 GMT

After 2 years writing on Dev.to and Medium, I finally decided to build my own blog.

I enjoy the platforms and they were great for a while, but having full control is always better. It took me some time but it was a nice project to ship, and I had fun building it.

This wasn’t just about creating the blog, I took the opportunity to rebuild my personal site joacod.com from scratch with a new look and feel as well.

Tech used

I wanted something very fast, no vendor lock-in, static (SSG), and not tied to any specific frontend tech (React, Vue, Svelte, etc), so the choice was an obvious one, I went with Astro, I love this framework and if in the future I need to extend it or add more client side heavy stuff I can do it, it’s very powerful and I’ve been a huge fan of it for a couple of years now.

Other than that, just plain HTML, Tailwind, and vanilla JS. That’s it.

Since Astro joined Cloudflare early this year, it felt like a good idea to deploy it there, but there are multiple deployment options (if I ever want to change that), right now it just works for me, and I get an extra layer of security as a bonus.

Did I use AI to create it?

Well, we are in 2026. If you are not using AI to help and improve your work, you are living under a rock, so yeah, of course I use AI.

I like to test different tools and models, so for this I used a mix of the following:

Claude Code + Opus 4.6 (Anthropic)
OpenCode + GPT-5.3-Codex (OpenAI)

My coding agent of choice is OpenCode, it’s such a great project, if you don’t know it and you are using something like Claude Code, I’d suggest you give it a try, it’s the same approach, but open source, with better performance. You can also use any model you want with it, it has a lot of different providers you can connect to, and it’s very easy to get up and running.

I was a user of Claude Code and Anthropic models for the past 6 months, but this month I switched entirely to the OpenCode + GPT-5.3-Codex combo. It may take you some time to get used to Codex if you are coming from Opus, Codex asks many more questions and requests clarifications (which is good), but if you know what you’re doing and give precise directions, the results are amazing.

That said, both options are great, and at this point it’s just a matter of personal preference.

Now what?

Having the opportunity to make it work exactly how you want is awesome. So I’ll be adding more functionality, little fixes, and creating new stuff that sounds cool to build.

I’ll continue writing as always, about the things that interest me, as a form of catharsis, or sharing news from the tech world.

The new blog will be the main canonical source, but I’ll keep posting each article on Dev.to and Medium as secondary channels.

It was a good start of the year. It is always good to ship something and see it live. If you have suggestions, comments, or improvements, they are always welcome.

Thanks for reading, and see you on the web!

AI in Corporate, Navigating a Sea of Hot Air

Fri, 16 Jan 2026 00:00:00 GMT

I see several problems in corporate environments and in how AI is being used to speed up development.

On one hand, the more senior devs, who paradoxically are the ones who benefit the most from these tools are resisting. Some out of fear of being replaced, others are stuck with the idea of what an AI from two years ago could do. They don’t try new models or tools, and a lot of them don’t even know for example what Claude Code is…

On the other side, the processes and methodologies companies use are outdated. They already were years ago, but AI made it even more obvious. So no matter how much we speed things up on the dev side, the real bottleneck is somewhere else, and none of the decision makers are willing to have that conversation.

If we’re doing a bit of future telling, the era of small structures and small teams is coming, roles merging, more ownership from start to finish. If you’re a dev, learn product. If you come from product or management, learn code. None of these roles are going to exist the way we know them. How long will it take for the change to arrive? No idea. But it’s coming, and like always in tech, you’ve gotta adapt. The time is now.

And finally, stop parroting whatever people say online, including this post. Research, experiment, see how far you can take those ideas you’ve always had. In my opinion, reality is somewhere in the middle, we’re nowhere near the AGI the AI-Bros talk about, but the tools are way better than what the Anti-AI-Bros claim.

Good luck navigating this sea of hot air!

I don't care about the algo

Wed, 24 Dec 2025 00:00:00 GMT

It’s been an interesting year, a little experiment on social media and building some online presence, my approach right now and for the next year is this “I don’t care about the algo” not any more.

I started as everybody, investigating what was the best approach in general, but at some point every article or YouTube video about it sounds the same, over and over again. Analyze the different way people talk depending on the platform, for example a post on X got nothing to do with how people post and behave on LinkedIn, hashtags yes or no, don’t put external links on posts (that will limit your reach), when starting reply more than you post so people get used to your takes, and every other advice made by the gurus of social media.

Despite some of the advices kind of work at first, the different algorithms and what platforms value most to keep users hooked change over time, and very often. If you want to be up to date with the latest updates you end up worrying more about the new algo than your content or what you want to talk about.

At some point I realized a couple of things. My intention was to be consistent so in order to do that I needed to enjoy what I was doing and doing it my way. Since I was aware of the “magic formulas to make it”, when I read a post I recognize that stuff and is usually a sign to stop reading.

Currently most posts or ideas have no original voice at all, it’s all the same regurgitated text from different AIs, different models but the same kind of slop.

I talked about my experience refining and editing with AI here, long story short, people want to know what real people think, agree or disagree, share different ideas and make their own conclusions, at least that is what I want.

We really need to make much more emphasis on critical thinking, no shortcuts, have your own opinions, and be ready to change your mind if something just makes more sense or you were missing information, you don’t have to be right, you just have to be open to new point of views, and the possibility that you may be wrong about a lot of things.

For all of this, a few months ago I made a decision, I won’t care about the algo any more. That had a huge positive effect, I was no longer following a formula, I just wrote things into internet’s void, most of the time I don’t get any reach at all, but the premise was “I don’t care” so no problem, other times I get some interactions and the chance to discuss some ideas or topics, and very few times something hit a nerve and gets many interactions, shares or likes, that is awesome not gonna lie, but again not the objective of it at all, the point is to be able to share my thoughts, get them out of my mind, and it works really good for me in a cathartic and psychological way.

It was a great year, I learned a lot of things, and this is my approach for 2026: I’ll keep writing stuff I’m interested in, posting when I feel like doing it, and let the algo be.

Happy holidays to everybody, see you in the future!

AI and the Loss of the Flow

Wed, 05 Nov 2025 00:00:00 GMT

Let’s face it, we write less and less code every day. Software engineering changed for good. That ship has sailed.

And while we swing from “oh no, I’m going to lose my job soon” to “this clanker has no idea, of course I’m absolutely right”, depending on the size and complexity of what we’re building, we are not noticing what we are really losing.

The Flow

This one’s short. Mostly because, despite growing up reading books, most of you now doomscroll your social media drug of choice and probably lost the attention span for more than a few lines of text. So if you made it this far, congrats!

What I actually want to talk about is something different, and honestly, a bigger problem than we think.

Those of you who enjoy programming will get this, back in the pre-AI days, coding felt like a craft. You’d have a problem, understand it, design a solution, go through the specs… and finally, the rewarding part, writing the code.

That moment was special because you’d already thought about it. You could see all the moving parts in your mind and you knew what you were about to build. You’d start typing, and soon enough, you’d enter that magical state a lot of people call “the flow”.

It’s that pure focus where distractions fade, you’re deeply immersed in what you’re doing, and time kind of dissolves. It’s not about finishing or releasing your project (though that’s nice too). It’s about that “in the zone” feeling.

But that was the past

Now we just prompt.

It’s rare for AI to nail it on the first try. If it does, it’s because you wrote a hyper-specific prompt, if not you’ll probably have to reword again and again as you catch tiny details that are off. We all love longer context windows, but at some point the slop written starts to multiply.

Sometimes I just bail out of the AI loop and start coding manually, especially when i get tired of arguing with a tool about something I already know how to do.

If you actually use AI at work, you know most of those YouTube demo projects don’t even come close to the complexity of a real production codebase.

Anyway, back to the flow

We’re losing it.

It’s the most automatic, immersive part of our job, and it’s slowly disappearing. Sure, AI keeps getting better, and it’ll eventually handle more and more of what we used to do manually. But beyond that whole debate, losing the flow means losing a huge part of the joy of programming.

Instead of that deep focus where ideas turn into working code, we now live in a loop of reviews, prompts, tweaks, and retries.

I’m not sure where this is going. Maybe we’ll learn to find that sense of flow at higher levels, when designing systems, architecting solutions, or abstracting problems. That can work for some.

I don’t know.

What I do know is that the old way felt better. It was more satisfying. We’re removing a crucial part of the craft, a part that made you care deeply about the quality of what you built, as you shaped it, line by line of code.

And don’t get me wrong, I’m not against AI. It’s an incredible tool. I use it every day. But I can’t help noticing that the more we rely on it, the less time we actually spend inside the problem.

We need to regain attention. Or maybe we’re doomed to trade joy for efficiency, satisfaction for speed. Maybe the flow was the price we paid for progress.

Anyway, if you’re reading this, maybe close your tab, open your editor, and code something today. No AI, no autocomplete. Just you, the problem, and that beautiful silence of being completely lost in it.

Be water my friend.

A New Day, a New Security Attack on npm…

Tue, 16 Sep 2025 00:00:00 GMT

The number of attacks and vulnerabilities popping up every week in npm is becoming ridiculous, and the problem just keeps growing.

Last week, we had a very serious attack where the account of a major maintainer “Qix” was compromised, and today, once again, another important one, an attack on the tiny-color library, potentially affecting more than 180 packages.

And of course, the most common type of attack is a “Supply Chain Attack”.

The risks in the JavaScript ecosystem have always been there, especially with the huge number of dependencies whose origins we don’t fully know. But in recent weeks, we’ve seen more and more news of libraries with millions of downloads being compromised.

The problem is that in JavaScript we often rely on hundreds of packages, and it only takes one being contaminated for the attack to reach your project. You may even be using dozens of packages without realizing it, because they are dependencies of dependencies of something else you’re using.

What is a “Supply Chain Attack”?

A “Supply Chain Attack” is like a modern Trojan horse. Instead of attacking your application directly, they compromise a popular library, which then ends up running inside your application with different objectives. It can even reach CI/CD pipelines, production environments, and more, with countless possibilities for damage or exposure of sensitive data.

Why is it so risky in npm?

High dependency: a single npm install can bring in dozens of indirect libraries you don’t even know about.
Excessive trust: we blindly assume that everything on npm is safe.
Dangerous automation: many CI/CD pipelines update dependencies automatically, opening the door for attacks to spread.

What to do?

Lock versions in your package.json

The caret ”^” is your worst enemy. It’s better to update dependencies consciously than to let any “Minor” or “Patch” version install automatically.

Following Semantic Versioning, we have MAJOR.MINOR.PATCH

"library-example": "^6.1.0" // installs Minor and Patch versions

With the caret, any version like 6.1.1, 6.1.2, or 6.2.0 will eventually be installed in your project. If one of those versions is compromised, you’ll be using it without knowing.

"library-example": "6.1.0" // installs only that specific version

Audit your dependencies

Don’t fall into the “install and forget” trap. Dependencies must be reviewed periodically, because even very popular libraries can be compromised.

Check what you install and use tools such as:

These tools detect known vulnerabilities and help you prioritize security patches.

Also, it’s good practice to check the state of a library before installing: when was it last updated? is there activity on GitHub? how many maintainers does it have?

A library that’s abandoned or maintained by just one person is far more vulnerable to being taken over by attackers.

Minimize dependencies

Every new library you add is a potential entry point into your application. Many times, we install a package for very simple tasks, it’s often better to write 20 lines of your own code than to bring in yet another unknown dependency.

Fewer dependencies = less attack surface, fewer updates to monitor, and a more predictable project. Not everything has to come from npm.

Conclusion

In npm, trust is delegated far too easily. Be careful with what you bring into your project, your security depends on it.

Virtual "Team Building" activities are a massive red flag

Fri, 18 Jul 2025 00:00:00 GMT

Dear execs, HR folks, and managers, please, let’s stop with the virtual team building sessions.

They waste time
They force devs and QAs who are deep into real work to context-switch and lose focus
They’re awkward
90% of the people are just waiting for it to be over
And they never, never, create any real bonding

Just my humble opinion, but here are two things that actually do work

1. Real-life team building activities, in person

Not mandatory. Bonus points if there’s travel involved, even if it’s just for a day or two. The people who show up actually want to be there. When you bring together folks from different teams and roles who may have only interacted virtually for months, conversations happen naturally. Real groups form organically.

2. A good work environment

A healthy workplace, where people collaborate the right way, is actually team building by itself. Some of my closest friendships started like that, just working together every day, helping each other out, bonding over shared interests, games, movies, music, whatever. And again, but very very important, it all happens ORGANICALLY.

Now, why do I say virtual team building is a red flag?

In my experience, these things usually pop up when there are deeper problems on the team:

Unrealistic deadlines
People with weak soft skills being promoted to leadership
A toxic environment where gatekeeping is rewarded instead of collaboration
And the list goes on, you can probably add a few of your own, we all identify this kind of things

If you’re in a leadership role and thinking about starting these virtual bonding sessions, maybe take a step back and look at what’s really going on inside the team. Fix the root cause first.

Let’s be a bit more self-aware. Stop throwing band-aids at deeper issues. And instead, create space for real, meaningful connections to grow.

Unsolicited advice about posting online

Wed, 16 Jul 2025 00:00:00 GMT

About a year and a half ago, I started being more active on different platforms. The goal was simple, share experiences, news, memes, whatever I felt like, and connect with people in the software and startup world from different corners of the globe.

I’ve always enjoyed writing. But thanks to impostor syndrome, the pressure to sound “professional”, and that english is not my native language, I started filtering my ideas through AI, mainly ChatGPT. I’d write a raw draft, then polish it up and translate it with AI. And it felt like magic, the ideas were mine, but the result was perfectly written, not a typo in sight. Awesome! Right?

Well… not quite. I slowly started noticing something, even though the message was what I wanted to say, it didn’t feel like me, the words were too polished, the vocabulary was different of what i normally use on the day to day, the main ideas were there, but definitely the guy that wrote that wasn’t me.

So, I stopped using AI for my posts. I went back to the old school way of doing things, just writing, directly in english, with my own words, editing manually a bit, fixing little things here and there, but more close to a first raw version of my ideas. And what I didn’t expect was how quickly the reach grew, more impressions, more engagement, more people commenting, talking to me on DMs, and actually connecting.

Moral of the story? In this AI driven, hyper curated world where everyone tries to be “professional” and politically correct, we’ve kind of lost our voice and essence, especially on social media. We started to identify when something was written by AI. We read a paragraph, realize it’s just more of the same, and scroll on.

I’m still figuring things out, but I try every day to show up here the same way I am in real life, less smoke and mirrors, more honesty.

Authenticity is going to be the real differentiator in the future we’re walking into.

I don’t want to meet a bot, I want to meet the human behind the screen. So here’s to the imperfections that make us humans, cheers!!

Technical Interviews in the AI Era

Wed, 25 Jun 2025 00:00:00 GMT

Let’s be real, you don’t need more than 1 hour for a proper technical interview.

The way most companies are doing interviews right now? It’s embarrassing.

They completely miss the point of what makes someone a good software developer. And don’t even get me started on how out of touch they are with the current state of AI.

Want to run an effective interview? Want to find out if someone not only has experience but also knows how to use modern AI tools to boost their work?

Here’s the process. One hour. That’s all it takes.

🔹 First 20 minutes: Let’s talk past projects

Ask about the candidate’s previous experience. Dive a bit into the projects they mention. This alone tells you a lot, what kind of challenges they’ve faced, how deep their experience goes, and how they think about solving problems.

Important: before the interview, send them a starter project (depending on the stack) so they can clone it and have it ready.

🔹 Next 40 minutes: Live coding, but make it real

Now here’s where it gets interesting, build a feature live, inside that starter repo.

But with a twist, let them use AI tools, VS Code with Copilot, Cursor, Windsurf, ChatGPT, Claude, Grok, whatever they want.

Autocomplete, AI prompts, agent mode, copy paste, search on the internet, it’s all fair game.

What matters isn’t if they use AI, it’s how they use it.

As they build:

Ask about the code the AI generates, go deep on the candidate explanations about it.
Look at the way they prompt. Are they treating the AI like magic, or are they in control? Do they give clear instructions about architecture, refactors, patterns?

You’ll quickly spot the difference between someone who leads with intention and someone who’s just hoping the AI does it all for them.

So what’s the catch?

Simple, this kind of interview only works if the interviewer actually knows the craft.

That means real technical experience, and being up to speed with modern AI workflows. If you don’t know how these tools work, you won’t know what to look for.

Conclusion

Cut the nonsense, skip memorized LeetCode problems that won’t have any impact on the actual job. Focus on what matters, real world experience and modern tools.

That’s it.

Yes, it really is that simple.

Unlocking Developer Superpowers with Cursor

Tue, 17 Jun 2025 00:00:00 GMT

As a developer who’s been coding for 15+ years, I’ve recently shared my excitement about AI IDE’s in general, and after trying a bunch of them my main editor for some time now is definitely Cursor.

Disclaimer: this is not a paid promotion (in fact I’m the one paying Cursor their Pro Plan), it’s just my honest opinion on using it and my thoughts about the experience.

This AI powered code editor, built as a fork of Visual Studio Code, has transformed how I work, and I want to dive deeper into that on this article.

Here’s how I’ve been leveraging Cursor, why it feels like cheating, and why my foundational skills remain key.

Don’t Be a Passenger, Take the Wheel

AI won’t drive the project for you. It’s fast, confident, and occasionally dead wrong. I’ve seen AI output go sideways a hundred different ways.

But with the right instincts, a bit of judgment and some cleanup, it becomes a serious asset (if you stay in control).

Know When to Step In

Cursor agent mode can refactor code impressively. But sometimes it loops endlessly, bloats logic, or misses the point entirely. I’ve tried all the usual fixes: better prompts, reframing the task, feeding it more files. Most of the time? It slows me down.

What works best: recognize when it’s off, stop the loop, fix it manually, finally hit the AI again with clearer intent. A small manual edit often saves more time than battling the prompt, and keeps things flowing.

Spot the Gaps It Can’t Fill

LLMs doesn’t know your architecture the way you do, or why a certain hack was necessary three sprints ago. I’ve seen it confidently suggest changes that would silently break core business logic.

If you know your system, you’ll catch these instantly. If you don’t, you risk shipping bugs the AI helped you write.

Clean Up the Hallucinations

Wrong API calls. Fabricated methods. Wild assumptions about project structure. They’re not rare. AI can sound convincing even when it’s totally wrong.

This is where experience matters most. I don’t trust the output blindly, I debug it, cross check it, and steer Cursor more effectively the next time around.

Why It Feels Like Cheating (If You’ve Got the Skills)

AI code editors can write code, suggest fixes, refactor functions, and answer project specific questions. Sounds great. But here’s the catch: all of that only becomes powerful in the hands of a developer who can tell good output from bad.

The “cheating” feeling doesn’t come from skipping the hard stuff. It comes from accelerating through it, because you can instantly spot when the AI is almost right, and know exactly how to fix it. That’s not bypassing the challenge. That’s using your experience as leverage.

Do it right, and speed of development starts to increase, like a lot. That’s when it starts to feel like cheating.

The Real Edge Is Still Experience

Cursor doesn’t replace your skills, it amplifies them. If you don’t already know what clean code looks like, what patterns to use, or how changes ripple through a system, AI won’t save you. It might even bury you deeper.

Fluency in languages helps you spot subtle errors AI introduces.
Design pattern knowledge lets you structure AI output into something maintainable.
Software architecture awareness ensures your edits fit the big picture.

Without this, you’re letting the AI take control while you guess what it’s doing, and that is not a good idea, trust me.

Long story short, Cursor isn’t building my apps. It’s helping me build them faster, cleaner, and with more focus, because I bring the judgment, context, and correction it lacks.

I spend less time rewriting boilerplate, more time refining architecture, reviewing logic, and keeping quality high.

The Future of Software Development

A lot of people are talking about completely replacing programmers, I don’t see it, and to be totally honest I think most of those claims are bullshit.

New models aren’t growing exponentially like all the AI companies are advertising. These announcements should be taken with caution. Most of the time, their objective is just to raise more VC money.

That said, we cannot deny that AI is here to stay and that many jobs, while not completely replaced, will change radically. I believe they will change in a good way: fewer repetitive or boring tasks, and more focused on solving challenging problems.

The future of software development isn’t man vs machine, it’s collaboration. Tools like Cursor are getting more powerful: inline chat, project wide edits, agent mode. But none of it replaces the craft. It just makes skilled developers with strong foundations even faster.

Learn the basics of the languages you use, learn about design patterns, learn software architecture.

AI isn’t magic, but you can significantly increase productivity if you know what you’re doing.

The future is now.

Corporate is the Bottleneck, AI Changed the Game

Thu, 12 Jun 2025 00:00:00 GMT

Working in a corporate company feels like time has stopped, the speed of development is ridiculously slow, they are trying to use AI to improve but the problem is not the developers, it is in the infinite processes and layers upon layers of management.

The agile manifesto was created for developers to work better, corporate transformed it into a tool of control and bureaucracy, let’s be honest whatever they are doing is not scrum and much less agile.

Big companies aren’t dumb, they understand the problem they’re in, but the restructuring needed to fix it is massive and one misstep can backfire, and it is backfiring. The different round of layoffs in most cases very poorly managed, only worsen employee sentiment, with key people fired, many others resigning, and an incalculable loss of real knowledge, they are entering uncharted territories.

It’s the time of lightweight startups, the difference is abysmal, the speed is dizzying, corporate is the current champion, confident, poorly trained and pedantic, startups are the challenging underdogs, they are hungry, they have the eye of the tiger, and they are going for the title fight.

The game has changed, the playing field has leveled, the time is now.

Navigating the AI Revolution, Reality, Risk, and the Human Advantage

Mon, 09 Jun 2025 00:00:00 GMT

Artificial intelligence isn’t coming, it’s already here, transforming how businesses operate, how teams collaborate, and how value is created. AI headlines range from utopian promises to existential panic. But most miss the point.

The rise of large language models (LLMs) and intelligent automation isn’t about replacing humans. It’s about redefining roles, enhancing capabilities, and changing how we think about work. AI is a powerful tool, evolving fast, but far from infallible. Its impact depends on how we use it.

In this article I’ll try to cut through the noise. What AI can realistically do? where it struggles? and how humans remain central to this transformation?

I’ll also explore how smart adoption (not blind enthusiasm) creates real competitive advantage.

What AI Does Well and Where It Fails

AI is already crushing repetitive, rule based tasks. It can summarize reports, generate basic content, answer customer queries, and surface insights from vast datasets in seconds. These are meaningful gains in speed and scale.

But it can hallucinate, misinterpret, or reinforce bias. Ask it to write a legal brief, and it might sound convincing… but without legal oversight, it could be dangerously wrong. In healthcare, it can flag anomalies in scans, but only a trained professional can interpret them responsibly.

In high stakes domains, law, medicine, finance, engineering, AI is a smart assistant, not a replacement. It thrives on structure, but stumbles in ambiguity. That’s why human oversight isn’t optional, it’s essential.

The sweet spot? Let AI do the heavy lifting. Let humans bring judgment, ethics, and nuance.

Competitive Advantage Comes from Strategic AI

AI offers real benefits: faster operations, lower costs, scalable solutions. But it’s not completely plug and play. Without a clear plan, it becomes just expensive tech theater.

Strategic adopters ask better questions:

What are the low value tasks draining our team’s time?
Where could automation introduce risk or erode trust?
How do we combine AI with human strengths, not substitute them?

For example, a logistics company might use AI to optimize delivery routes, boosting efficiency without compromising decision making. A marketing team might use AI to brainstorm content, but still rely on humans for narrative and brand tone.

The goal isn’t maximum automation, it’s meaningful transformation. That requires domain knowledge, critical thinking, and intention.

Cut Through the Hype

AI hype is everywhere. We’ve been here before, remember crypto and the blockchain gold rush?

Most promises faded. A few real use cases stuck. AI is following a similar pattern. The smart move now is to stay skeptical and grounded.

Don’t take every claim at face value. Just because a vendor insists their AI product can do something impressive doesn’t mean it’s actually ready for real world use. Always test before you trust. Run small pilots in controlled environments before scaling anything broadly. And stay realistic, AI isn’t magic, it’s math. It has strengths, but also hard limitations.

Hype clouds judgment. Smart leaders focus on outcomes, not trends. They vet, validate, and deploy for real impact, not novelty.

Human Expertise Is the Real Differentiator

If you’ve spent years in your field, you’ve seen what works, what fails, and what never gets documented. That’s priceless, and it’s your edge.

This experience lets you catch what AI might miss: subtle inefficiencies, hidden risks, and clever workarounds. AI can assist, but it shouldn’t call the shots. The real power comes from using AI to sharpen your judgment, not substitute for it. Let it take care of the repetitive tasks so your team can focus on higher impact work.

The pattern is clear, pairing domain expertise with AI muscle is the winning formula.

The Future, Powered by AI, Led by People

The AI revolution isn’t a tsunami wiping out jobs overnight. It’s a wave of change that we can ride (if we’re smart about it). The winners won’t be the loudest adopters. They’ll be the most thoughtful ones.

If you’re a leader, your job is to bring clarity, not panic. If you’re a professional with years of experience, your value just went up. If you’re starting out, use AI to learn faster, but don’t abandon human skills like curiosity, communication, ethics, and creativity.

The market will evolve, and so will we. But let’s do it with intention, strategy, and a healthy dose of skepticism.

This era will reward those who think clearly, act wisely, and lead with purpose.

The AI revolution needs leaders who think critically, move deliberately, and never lose sight of the human advantage.

Stepping Aside to Lead in Tech

Tue, 13 May 2025 00:00:00 GMT

We are living in an exciting era for software development. It has always been an industry of constant evolution, but the rise of artificial intelligence has multiplied the productivity of those who adopted it early.

This new reality, with teams capable of building faster than ever, shines a light on something many leaders still don’t want to see: the main bottlenecks are often not in development, but in how we manage processes and make decisions.

The New Bottleneck

When developers become more efficient, tasks are delivered faster, and AI tools can automate or accelerate repetitive work, the real obstacles are exposed: unnecessary processes, unproductive meetings, outdated hierarchies, and a constant need to “feel in control.” All of this slows teams down.

At the root of the problem is often a human flaw: distrust. In many cases, leaders don’t truly trust their teams. They try to micromanage, schedule constant ceremonies, request irrelevant status updates, or impose artificial social dynamics. The result? Distracted, frustrated, and demotivated teams.

What Good Leaders Have in Common

The leaders I’ve interacted with, those who enabled their teams to work with true autonomy, shared several traits:

Solid technical backgrounds: Unsurprisingly, most came from software development or architecture. They understood what it means to build and the complexities involved.
Few, focused meetings: When the team did meet, it was to resolve blockers or align on concrete goals. No endless chats or empty check-ins.
Genuine trust in the team: Every team member was assumed to be competent and capable of acting responsibly.
A service-oriented mindset: They understood that leadership isn’t about control or imposition, but about setting direction and clearing the path. Their role was to unblock, protect the team’s time, and then, step aside.

The Empty Calendar as a Productivity Strategy

The result of this approach? Clean calendars. Uninterrupted schedules. Developers focused, without context-switching every hour or attending irrelevant meetings that feel like background noise.

When a problem came up, it was solved. How? By speaking directly with the right person, Slack, a quick huddle, a message. No waiting for the daily or setting up a “sync.” Interactions were organic and purposeful. Ironically, this model, which might seem isolating, actually encourages genuine collaboration.

With no external impositions, devs collaborated because they wanted to preserve that space of freedom. They knew helping others sustained a no-bureaucracy culture. Over time, this built real bonds, conversations about hobbies, travel, personal life. Relationships formed naturally, not through forced bonding activities.

Common Practices in Truly Agile Teams

This kind of leadership “stepping aside” doesn’t mean absence, but strategic presence. Some common practices in genuinely agile environments include:

Distributed autonomy: Each team has clarity on objectives and the freedom to decide how to reach them.
Minimal, purposeful meetings: If it doesn’t help move forward, resolve a blocker, or share something new, it’s not needed. Retrospectives are held only when there’s something to reflect on.
Spontaneous pair or mob programming: Not imposed, but encouraged when useful.
Clear definition of “done”: Fewer processes to close tasks, but clear agreements on what’s expected.
Hiring based on real experience: Not on impersonal tests or abstract algorithm challenges, but on a candidate’s ability to adapt, learn, and work well in a team.

The Myth of Forced Bonding

Companies often try to solve a lack of connection with artificial dynamics: games, mandatory virtual coffees, or forced “social Fridays”. But most people don’t want to be friends with everyone at work. What they do want is respect, smooth collaboration, and an environment where they can be themselves without social pressure.

Real diversity in a team isn’t achieved by forcing affinities, it’s about allowing everyone to connect in their own authentic way.

Conclusion: The Future of Leadership

Leading in tech today isn’t about climbing the hierarchy or designing more processes. It’s about knowing when and how to step aside. It’s about building teams that manage themselves, trusting that people want to do good work, and enabling them to succeed.

The software revolution is not just technical. It’s cultural. And it starts when leaders understand that teams perform better when no one constantly interrupts them to “lead” everything.

Bad Data Is Breaking AI: The Cost, the Risks, and How to Fix It

Thu, 10 Apr 2025 00:00:00 GMT

AI promises better decisions, faster operations, and game-changing innovation. But when the data is wrong, everything breaks.

Bad data has become one of the biggest and most underestimated threats to AI success. It causes models to fail, decisions to skew, and costs to spiral.

This article explores how poor data quality impacts AI, examines the real-world damage it’s caused, and outlines practical strategies to fix it before it sinks your systems.

The Business Impact of Bad Data

Bad data is not just a technical nuisance, it’s a bottom-line killer. In 2016, IBM estimated that poor data quality cost U.S. companies around $3.1 trillion annually.

More recent per-company estimates suggest the damage adds up to $12–15 million each year. On average, research shows bad data can erode 12% of a company’s revenue. That’s a massive hit to performance and profitability, one that compounds as AI becomes more central to business operations.

Customer insight is one of the first areas to suffer. When data is inaccurate or incomplete, AI can’t properly segment users, personalize experiences, or predict behavior. This leads to wasted marketing spend, missed opportunities, and faulty automation.

Some reports states that 88% of U.S. companies believed bad data had a direct impact on their ability to understand customers, resulting in lost revenue and reduced competitive edge.

Real-World Failures That Trace Back to Bad Data

The consequences of bad data aren’t abstract, they’ve played out in high-profile, costly, and public failures.

In 2018, Samsung Securities accidentally issued 100 billion dollars worth of phantom shares due to a fat-finger error. Before the mistake could be corrected, employees had already sold about $300 million worth of nonexistent stock. That single input error spiraled into a financial and reputational crisis.

Uber experienced a different kind of data problem in 2017, when it miscalculated commission rates and overcharged drivers. The company ended up repaying tens of millions, about $900 per driver because a simple data-processing error had gone unnoticed for months.

Amazon ran into deeper, more systemic trouble with its AI hiring tool. Trained on historical resume data from a male-dominated industry, the tool learned to downgrade resumes that mentioned “women’s” organizations or came from all-women’s colleges. The bias was baked into the data, and as a result, the system became unusable. The project was scrapped in 2018, highlighting how easily bad data can introduce ethical and legal risks.

More recently, Equifax made headlines in 2022 when a coding error caused credit scores for more than 300,000 consumers to be reported incorrectly. The mistake triggered legal challenges and a 5% drop in the company’s stock, further proof that data quality isn’t just about internal efficiency, it affects real people and public trust.

Technical Failures and AI Performance Issues

From a technical standpoint, bad data can cripple AI systems. Even small flaws lead to big drops in performance. A study from the University of Twente showed that just 5% mislabeled data can reduce model accuracy, while other research observed performance drops of up to 5% when support vector machines were trained on datasets with 20–30% mislabels. These aren’t minor dips, they can mean the difference between a system that works and one that fails in production.

Bias is another critical issue. When training data reflects existing inequalities or errors, AI systems replicate and even amplify those patterns. Amazon’s hiring algorithm is the textbook example, but similar issues have been observed in facial recognition, healthcare diagnostics, and fraud detection.

Another underappreciated consequence is data downtime, when AI systems or data pipelines break due to corrupt, missing, or malformed data. In a 2024 report from Dynatrace, 98% of tech leaders said they were concerned about AI’s vulnerability to bias, misinformation, and data error. These issues aren’t caught during development, they’re often discovered by end users. Different studies agree that almost 74% of data quality issues are first identified by stakeholders or customers, long after the damage is done.

There are some projections that 85% of AI projects will fail to deliver meaningful results, with data quality named as one of the main culprits. When systems are built on shaky foundations, even the best models can’t make up the difference.

The Scope of the Problem: Data Quality by the Numbers

The scale of data quality challenges is massive. Harvard Business Review found that only 3% of enterprise data meets basic quality standards. While some estimates suggest 99% of AI projects encounter data-related issues, exact figures vary across studies. Still, the direction is clear: almost every AI system is wrestling with unreliable inputs.

Operationally, this takes a toll on data teams. Data engineers reportedly spend 30–40% of their time dealing with data quality issues, time that could otherwise go toward innovation or optimization. That firefighting mentality slows progress and increases technical debt, especially in fast-moving AI environments.

Looking ahead, the role of data quality is only going to grow. According to AIBase, by 2025, data quality will be a more important success factor in AI than the generative technologies getting most of the media attention today. And MIT Sloan’s 2025 trends report notes that organizations seeing the biggest productivity gains from AI are the ones that have invested in strong data foundations.

How to Fix It: Strategies for Clean, Reliable Data

Solving the data quality crisis requires more than one-off cleaning jobs. It demands structural change, cultural investment, and smart tooling. The first step is implementing automated data quality monitoring. Ideally systems that can track data freshness, schema changes, and volume anomalies in real-time, flagging issues before they hit production.

Equally important is assigning clear data ownership. When no one is responsible for data quality, problems slip through the cracks. Strong governance policies and data accountability structures help ensure consistency and integrity.

Training data also needs ongoing curation. AI models can’t be trained once and left alone. Data needs to be reviewed regularly for bias, labeling errors, and outdated information. Teams should treat training datasets as living assets, not static resources.

Finally, companies must foster a culture that prioritizes data quality. This includes educating teams about the real costs of bad data, aligning incentives with data reliability, and integrating data trust into every stage of AI development. It’s not just the job of data engineers anymore, it’s everyone’s responsibility.

Conclusion

Bad data is the silent killer of AI. It derails projects, drains resources, and destroys trust, often without being noticed until it’s too late.

But this isn’t a hopeless problem. With the right mix of monitoring tools, clear ownership, and cultural change, organizations can protect their AI investments and ensure that the systems they build deliver real value.

As we head deeper into 2025, one truth is becoming clear: the future of AI doesn’t just depend on better algorithms or more machine power, it also depends on better data.

The Solution Builder: A New Way to Build Software in the AI Era

Wed, 02 Apr 2025 00:00:00 GMT

Agile was meant to help us move faster. But over time, it’s become its own source of drag. Bloated tools, rigid processes, and too many handoffs have turned what should be a nimble workflow into a bureaucratic maze.

For developers and product teams alike, that means slower delivery, less ownership, and frustration across the board.

But there’s a shift happening, one that leans into AI, cuts out unnecessary layers, and puts real builders back at the center of the process. That said, I think a new role is going to be born and I like to call it the “Solution Builder”.

Ok we don’t need to marry with that name, I’m still working on it, but let’s call it that for the rest of the article.

What is a Solution Builder?

The Solution Builder is a hybrid between a developer and a product owner. They don’t just code, they own the entire problem-solving loop. They talk directly with stakeholders, understand the business goals, propose solutions, and build the product. Instead of passing tasks between departments, they take full responsibility for delivering working software, fast.

In this model, there’s no need for long chains of communication or bulky documentation. A Solution Builder has conversations with stakeholders, proposes a plan, and immediately starts building.

If the idea is complex, they might start with a quick proof of concept to test the approach. Otherwise, they begin deploying small chunks of the product and iterating daily. Feedback isn’t delayed until the end of a sprint, it happens continuously.

How It Works in Practice

The Agile Post-AI process (as I call this approach) strips away unnecessary complexity. It starts with a simple conversation between the Solution Builder and the person who has the problem.

Together, they clarify what needs to be built and agree on the next steps. From there, the Builder documents the plan in just a few lines (no multi-page specs), no formal user stories. Then they start coding.

Instead of a heavy project management system, a lightweight board (I like to use Notion, but you can use any other option) is used to track progress. Columns like “To Do”, “In Progress”, and “Ready for Review” are more than enough to stay organized.

The Builder deploys changes daily, and the stakeholder reviews them in real time. If something needs to change, it’s adjusted immediately. This cycle continues until the product is done.

One key difference in this workflow is autonomy. Solution Builders don’t wait for approvals or rely on long chains of command. They’re trusted to make decisions and move fast. That means fewer blockers, more ownership, and a lot less overhead.

AI as a Force Multiplier

AI plays a big role here, but not by replacing developers. Instead, it enhances them. Models like Claude Sonnet 3.7 (or choose your favorite) help speed up the coding process.

You can use similar LLMs depending of your preference to assist in shaping requirements, generating ideas, or even rewriting documentation.

Repetitive tasks like testing or refactoring can be partially automated, freeing up the Builder to focus on higher-value work: logic, UX, and stakeholder communication.

The result isn’t just faster development, it’s smarter development. Builders can focus on solving the right problems instead of wrestling with tools or chasing down vague requirements.

Why It Works (Especially for Startups and Lean Teams)

This model is especially effective for startups or small teams that need to move fast. If you’re building an MVP or testing a new feature, speed and clarity matter more than process purity. The Solution Builder approach delivers both.

You get working software in days, not weeks. You talk directly to the person building the product. And you can steer the result as it evolves, instead of waiting until the end of a sprint to realize something was misunderstood.

There’s also something powerful about simplifying the tool stack. You don’t need a wall of Jira tickets or ten different integrations to stay on track.

Most teams find that a simple board, direct messages, and daily check-ins are more than enough. Trust replaces supervision, and progress speaks louder than status reports.

A Quick Example

Let’s say a founder needs a basic customer management tool. Instead of going through the usual process—product briefs, kickoff meetings, tech spec reviews—they sit down with a Solution Builder.

They talk for a reasonable amount of time (you can adjust the time to your needs), clarify the goal, and by the next day, a first prototype is live. Over the next two weeks, the product is shaped and improved daily based on real feedback.

There are no long delays or miscommunications, just fast, iterative building. At the end of two weeks, they have a working basic product. No fluff, no friction.

The Bottom Line

The Solution Builder model is about reclaiming agility. It ditches the excess process and lets developers own the problem, the solution, and the path in between. Paired with AI, it’s a powerful way to deliver real results, quickly and cleanly.

If you’re part of a startup or a lean team, this could be your edge. And if you’re working in a larger organization, a pilot project using this approach might be a great way to try something different, without committing to a full methodology overhaul.

We don’t need more frameworks. We need fewer blockers. And maybe, just maybe, we need more builders who can own the whole thing.

Anthropic's Claude Sonnet 3.7 is here!

Mon, 24 Feb 2025 00:00:00 GMT

Anthropic has just released Claude Sonnet 3.7, their latest and most advanced AI model to date.

This new version introduces groundbreaking features aimed at enhancing reasoning capabilities, coding proficiency, and user interaction. With hybrid reasoning, improved software development support, and a command-line tool for agentic coding, Claude Sonnet 3.7 is set to redefine AI-assisted workflows.

Hybrid Reasoning

One of the most notable advancements in Claude Sonnet 3.7 is its hybrid reasoning system, allowing users to choose between two modes:

Standard Mode: Provides quick, near-instant responses for general inquiries.
Extended Mode: Engages in step by step, in-depth reasoning for complex problem solving.

This flexibility empowers users to control response depth and accuracy, making it ideal for technical applications, research, and in-depth problem solving.

Advanced Coding Capabilities

Claude Sonnet 3.7 excels in software development, particularly in front-end web development. It achieves state-of-the-art performance in coding benchmarks, making it a powerful tool for developers. Notable improvements include:

Enhanced debugging and refactoring capabilities.
Improved support for modern frameworks and libraries.
Optimized code generation for faster and more efficient development.

Claude Code: Agentic Coding Made Simple

A major addition to this release is Claude Code, a command-line tool currently available in a limited research preview. This tool allows developers to delegate engineering tasks from their terminal, including:

Searching and editing code.
Running automated tests.
Committing changes to GitHub.

Claude Code aims to reduce engineering time by streamlining repetitive coding tasks, potentially cutting down work that would take 45 minutes to mere minutes.

User Control and Customization

Another standout feature of Claude Sonnet 3.7 is the introduction of API-controlled reasoning time. Users can now adjust how much time the model spends on thinking, up to 128K tokens, balancing speed, accuracy, and cost. This level of customization makes the AI adaptable to various business and technical needs.

Enhanced Safety Measures

Anthropic has significantly improved safety mechanisms in Claude Sonnet 3.7, focusing on:

A 45% reduction in unnecessary refusals compared to previous versions.
Better handling of prompt injection attacks.
Improved trustworthiness in reasoning, reducing hallucinations and misleading responses.

These enhancements make Claude Sonnet 3.7 a more reliable and ethical AI, particularly for enterprise applications and sensitive data processing.

Performance Benchmarks and Comparisons

Claude Sonnet 3.7 outperforms previous versions in key areas, particularly in reasoning depth, coding performance, and developer tools.

Below is a comparison of the latest model with its predecessor:

Feature	Claude 3.5 Sonnet	Claude 3.7 Sonnet
Reasoning Mode	Standard only	Hybrid (Standard & Extended)
Coding Proficiency	Strong, benchmark leader	State-of-the-art, improved front-end support
Developer Tools	Limited	Introduces Claude Code (research preview)
User Control	Fixed response time	Adjustable think budget (up to 128K tokens)
Safety Features	Standard	45% fewer unnecessary refusals, enhanced trustworthiness

Pricing and Availability

Claude Sonnet 3.7 is available across all Claude plans (Free, Pro, Team, and Enterprise) and is accessible via:

Anthropic API
Amazon Bedrock
Google Cloud’s Vertex AI

Pricing

$3 per million input tokens
$15 per million output tokens (including thinking tokens)
Extended thinking mode is not available in the free tier

This ensures accessibility while maintaining cost efficiency for professional use.

The Future of AI with Claude Sonnet 3.7

Claude Sonnet 3.7 represents a significant leap forward for Anthropic’s AI models, particularly in reasoning, coding, and customization.

The hybrid reasoning and agentic coding tools set a new standard in AI-driven workflows, making this release a valuable asset for developers, researchers, and businesses alike. With ongoing improvements and user feedback, Claude Sonnet 3.7 is likely to continue shaping the AI landscape in the years ahead.

This release sends a clear message: adapt, innovate and stay ahead.

Microsoft's Majorana 1: A Quantum Computing Breakthrough

Wed, 19 Feb 2025 00:00:00 GMT

Microsoft has unveiled the Majorana 1, a groundbreaking quantum computing chip that employs topological qubits, a technology designed to enable scalability up to millions of qubits.

This development holds the potential to revolutionize fields such as drug discovery and material science, but also raises concerns regarding cybersecurity and encryption vulnerabilities.

A New Path for Quantum Computing

Majorana 1 is built on a novel approach utilizing a Topological Core architecture. This architecture is based on a material known as a topoconductor, which facilitates the creation and control of Majorana particles. These particles, theorized since the 1930s, serve as the foundation for topological qubits, which Microsoft claims offer greater stability and scalability compared to conventional quantum computing technologies.

The chip currently houses eight topological qubits, with ambitious plans to scale up to a million qubits per chip, a threshold believed necessary to solve real-world computational challenges that classical computers cannot handle.

Applications of such quantum computing power include advancing materials science, chemistry, and artificial intelligence, potentially unlocking self-healing materials, efficient drug discovery, and novel energy solutions.

Initial Reactions: Excitement and Skepticism

The announcement of Majorana 1 has generated a wave of enthusiasm, particularly within the scientific community and among technology enthusiasts. Many industry experts have expressed excitement over the chip’s potential.

Despite the optimism, skepticism persists. Microsoft has previously faced setbacks in its quantum computing research, most notably in 2021 when a study it co-authored claiming evidence of Majorana particles was retracted. This history has led some to question the validity of Microsoft’s latest claims, indicating skepticism over the branding and marketing approach.

Additionally, concerns regarding cybersecurity risks have been raised, for example the possibility of using the new quantum chip to be able to crack Bitcoin private keys and global password encryption. This underscores the urgent need for advancements in post-quantum cryptography to counteract possible security threats posed by quantum computing.

Future Implications: Promise and Challenges

The impact of Majorana 1, if successfully scaled, could be transformative across multiple industries. Microsoft’s goal of achieving a million-qubit system suggests that quantum computers could soon be capable of solving problems once deemed impossible, such as:

Drug Discovery & Medicine: Simulating molecular interactions with unprecedented accuracy, potentially leading to the rapid development of new pharmaceuticals.
Material Science: Designing self-healing materials and novel compounds with unique properties.
Optimization Problems: Enhancing logistics, financial modeling, and artificial intelligence by solving complex optimization problems beyond classical computing capabilities.

However, significant hurdles remain. While topological qubits are theoretically more stable, Microsoft has yet to demonstrate large-scale quantum error correction.

Cybersecurity Risks Considerations

One of the most pressing concerns is the potential for quantum computers to break current encryption standards. RSA encryption, which underpins much of today’s digital security, could become obsolete in the face of large-scale quantum computing.

This could jeopardize the security of financial transactions, online communications, and even national security infrastructures.

To counter this threat, the field of post-quantum cryptography is already developing new encryption methods designed to withstand quantum attacks. Microsoft and other tech giants are working with governments and research institutions to address these risks, but the transition to quantum-resistant cryptography will require extensive effort and time.

Conclusion

Microsoft’s Majorana 1 represents a significant milestone in quantum computing, offering a glimpse into a future where quantum systems could solve some of humanity’s most complex problems.

However, skepticism regarding its feasibility and the potential risks associated with quantum computing highlight the need for cautious optimism. As research progresses, the balance between innovation, security, and accessibility will shape the trajectory of quantum computing for years to come.

The coming years will be critical in determining whether Microsoft’s bold claims materialize into practical, scalable quantum solutions, or if history repeats itself with another setback in the race toward quantum supremacy.

This year keeps giving us one breakthrough after the other, buckle up it’s just February.

Networking Is the Key

Mon, 10 Feb 2025 00:00:00 GMT

Throughout history, relationships have been the foundation of success. From business ventures to personal growth, strong connections have opened doors, sparked innovations, and built thriving communities.

In today’s digital era, networking is more critical than ever. However, simply adding someone on LinkedIn or following them on social media is not enough. Genuine networking goes beyond surface level interactions, it requires meaningful engagement and authentic connections.

Building valuable relationships doesn’t mean becoming best friends with everyone you meet. Instead, it’s about developing mutual understanding and trust. Face to face meetings, when possible, strengthen professional bonds, foster deeper conversations, and provide opportunities for collaboration that virtual interactions often lack.

Identifying the Right People in Your Network

Just like in life, networking introduces you to different types of people. Some are genuinely interested in building long term, mutually beneficial relationships. They seek to learn, collaborate, and support one another. These individuals are invaluable and should be prioritized in your network.

On the other hand, there are opportunists, those who view networking purely as a means to extract personal gain. They might show enthusiasm initially but disappear once they’ve taken what they need.

Recognizing such individuals early on is a skill worth developing. As philosopher Epictetus wisely said, “It is not what happens to you, but how you react to it that matters”. Being selective about whom you invest your time in will make your networking experience more productive and fulfilling.

Recognizing Meaningful Connections

Like any skill, networking improves with practice. Over time, you’ll develop an instinct for identifying people who align with your values, goals, and professional aspirations. Meaningful connections often stem from shared interests, industry alignment, or complementary expertise.

A strong network is particularly valuable when you’ve honed your skills in your field. It not only opens doors to new opportunities but also helps you spot those who talk a big game but lack real substance. Asking a few insightful questions can often reveal whether someone genuinely understands their craft or is simply using buzzwords.

The Hidden Superpower of Cross-Disciplinary Networking

One of the most overlooked advantages of networking is the exposure it provides to different industries and perspectives. For instance, if you’re a software developer, it’s easy to get caught up in technical challenges while losing sight of the bigger picture. However, connecting with professionals in management, product development, human resources, and other domains can offer fresh insights that improve collaboration and innovation.

Engaging with decision-makers is particularly valuable, as their challenges and priorities often differ from those of technical professionals. Understanding their perspectives helps bridge communication gaps and makes you more effective in leadership and strategic roles.

Networking as a Path to Leadership

Leadership isn’t for everyone, but networking helps you explore whether it aligns with your aspirations. By interacting with leaders and decision-makers, you gain a clearer understanding of the responsibilities, challenges, and rewards that come with leadership roles.

Moreover, career growth often involves expanding beyond your technical expertise. The knowledge, insights, and relationships you build through networking equip you to navigate new responsibilities and take on future challenges with confidence.

Taking Action: Start Building Your Network

The best way to become a better networker is to start now. Look for industry meetups, professional events, and networking gatherings relevant to your field. Attend a few, initiate conversations, and show genuine curiosity about other people’s experiences and challenges.

Offer value, share insights, and step outside your comfort zone. You never know when a single conversation could lead to an unexpected opportunity.

If you have a good resume, experience, solid knowledge in your field and you have also cultivated a good network, nothing can stop you!

Be authentic, engage meaningfully, and start building the network that will shape your career and future opportunities.

Trending Programming

Wed, 05 Feb 2025 00:00:00 GMT

In today’s world of software, many developers find themselves caught in what I call “trending programming”. With the rise of tech influencers and social media driven hype, it has become increasingly common to adopt new technologies, not out of necessity, but because they are popular and generate online engagement.

The appeal of learning something new, combined with the influence of online tech communities, often leads developers to hop from one tool to another without truly mastering any of them.

This constant cycle of technological churn significantly impacts how teams and companies choose their tech stacks, sometimes prioritizing trends over practicality.

The Influence of Trends

A prime example of this phenomenon is JavaScript’s widespread dominance over the years. At one point, it seemed as though everything had to be built with JavaScript, even when it wasn’t the best tool for the job.

Similarly, microservices became the default architecture choice for many projects, even when a monolithic structure would have been simpler and more effective.

More recently, PHP has made an unexpected comeback, reclaiming relevance after years of being dismissed as outdated. Ruby on Rails appears to be following a similar trajectory, garnering renewed interest despite past criticisms.

The real issue is that developers often chase trends rather than critically evaluating whether a tool suits their specific needs. This results in projects built on technologies that are chosen for their popularity rather than their appropriateness, leading to unnecessary complexity and potential long-term setbacks.

The Pitfall of “False Simplicity”

Learning a new technology typically begins with simple projects, a to-do app, a static website, or a basic console application. While these projects serve as a great introduction to syntax and structure, they often create an illusion of simplicity.

These beginner-friendly projects follow the “happy path”, where everything works as expected. However, real-world software development is far from linear. The real learning begins when developers encounter challenges that force them to think critically and dig deeper for solutions.

Some of these real-world challenges include:

Scalability: Building an app for 100 users is vastly different from scaling to 10,000 or a million. Database architecture, performance optimization, and server infrastructure become critical factors.
Integration with Legacy Systems: Many projects involve integrating with pre-existing systems, requiring adaptability and a deep understanding of how different technologies interact.
Security: Production-level applications demand robust security measures, including authentication, authorization, data encryption, and protection against common vulnerabilities like SQL Injection and Cross-Site Scripting (XSS).
Maintainability and Code Evolution: Quick fixes may work in small projects, but long-term maintainability requires well-structured, scalable, and adaptable codebases.

Developers who only skim the surface of technologies risk underestimating the complexities of real-world software development, leading to unstable, inefficient, or insecure applications.

Curiosity and Experimentation: Necessary but Not Sufficient

Exploring new languages and tools is an essential part of growth as a developer.

Curiosity drives innovation and learning. However, real expertise comes not from chasing the next big thing but from facing real-world problems and understanding the trade-offs of different solutions.

Solving Real Problems: The Best Path to Mastery

The most effective way to learn a new technology is by using it to solve actual problems.

When working on real projects, developers are forced to research the best combination of tools and techniques to achieve practical solutions. This hands-on experience uncovers critical details that tutorials often overlook.

Every technology comes with trade-offs. There is no universal tool for every scenario. What truly matters is understanding these trade-offs and making informed decisions based on project requirements.

By committing to a technology and working through its intricacies, developers build intuition for:

Handling Edge Cases: Identifying and managing exceptions that arise in real-world usage.
Scaling Applications: Optimizing code and infrastructure as an application grows.
Integrating External Solutions: Leveraging APIs, libraries, and third-party services effectively.
Understanding the Build Process: Learning how code is compiled, packaged, and deployed in production environments.

Mastering these skills allows developers to transition seamlessly between technologies when necessary, rather than constantly relearning surface-level concepts.

Stay Focused, Choose Wisely

The tech landscape moves quickly, and staying informed about new trends is beneficial. However, chasing trends without fully understanding existing tools can be counterproductive.

Instead of constantly switching frameworks or languages, developers should prioritize mastering core principles that will serve them across technologies.

Before adopting a new tool, ask yourself:

Does this technology solve a real problem that my current tools cannot?
Have I mastered my current stack enough to justify switching?
What are the long-term implications of choosing this tool?

Depth of knowledge matters more than the number of tools listed on a resume.

A developer who truly understands one framework can learn another quickly when needed. In contrast, a developer who skims the surface of multiple technologies may struggle to apply them effectively.

The Road Ahead

As you progress in your career, your familiarity with your primary programming language will grow. You’ll deliver features faster, recognize patterns across projects, and develop confidence in your technical decisions.

This expertise will make adopting new technologies a strategic decision rather than a reactive one.

Remember, the goal isn’t to know every trending tool, it’s to understand technology deeply enough to choose the right tool for the job.

Master the fundamentals, tackle real-world challenges, and when the time is right, you’ll be equipped to explore new technologies, not because they’re trending, but because they genuinely add value to your work.

And when your informed decisions start to add value, that’s when the magic happens.

The Only Thing You Need Is Consistency

Tue, 07 Jan 2025 00:00:00 GMT

In September 2024, I set myself a clear goal: to write at least one article per week about technology, my personal experiences in the field, and my opinions on various topics.

I allowed myself breaks during vacations, holidays, or special occasions, but I remained committed. Some weeks were more productive than others, some days I felt more motivated. Yet, by staying consistent, I wrote 20 articles by the end of the year.

This is my first article of 2025, and I plan to keep this habit going. Along the way, I’ve learned something you’ve probably read in many places before, and it’s true, that consistency is the single most important factor in building lasting habits, and it’s taught me lessons that extend far beyond writing.

What I Learned Through Writing

Writing regularly didn’t just make me a better writer, it made me a better thinker. To write clearly, I had to think clearly. Each article forced me to organize my thoughts, refine my ideas, and repeat that process until it felt right.

It also encouraged me to read more. As I consumed tech articles and opinion pieces, I absorbed insights on structuring content, simplifying complex topics, and exploring diverse perspectives.

For instance, an article from a software engineer often differs drastically from one written by a data engineer or someone in sales or marketing. These varied viewpoints enriched my understanding and reminded me that there’s no single way to approach a topic.

Writing became more than a medium for sharing knowledge, it became a process of reflection. Over time, I grew better at distilling complexity into clarity, and that clarity carried over into other aspects of my life.

The Trick Is Enjoying What You Do

Years ago, I had a blog in spanish that no longer exists. I loved writing for it, even though I didn’t have a big audience. That enjoyment stayed with me when I started writing this tech related content. However, writing about tech requires a different set of skills and a great attention to details, among other things, that I’m constantly learning one article after the other, and I’m loving it.

Of course, this isn’t unique to writing. For others, the same sense of fulfillment might come from creating YouTube videos, painting, or making TikToks. The key is to enjoy the journey, yes, even if it sounds a bit cliché.

I also discovered something else, writing can be therapeutic. Putting an idea or concern into words often feels like a release. Once it’s written down, it stops lingering in your mind, freeing you to move forward. Writing became not just a productive habit but also a source of mental clarity.

There will always be days when motivation is low, but if you don’t genuinely enjoy what you’re doing, it’s hard to sustain the effort. That’s why finding joy in the process is essential, it’s what keeps you going.

Consistency Is Key

Over time, consistency transforms effort into habit. Small victories begin to emerge, an article gets more views, you gain new followers, or someone leaves a thoughtful comment. These moments are deeply rewarding, but they’re not the main reason to stay consistent.

Goals are important, whether it’s growing an audience, reaching milestones, or achieving recognition. But goals shouldn’t drive you entirely. When recognition comes, it’s gratifying, but the real reward lies in the process, the act of expressing your ideas and releasing them into the world.

The Power of Consistency Beyond Writing

Consistency isn’t just about writing, it’s a principle that applies to every area of life. Whether you’re building a skill, adopting healthy habits, or pursuing a career goal, showing up consistently is what makes the difference. It’s not about perfection, it’s about persistence.

Take fitness, for example. Working out a few times a week consistently over months or years yields far better results than sporadic bursts of intense activity. Relationships thrive on consistent communication and effort, building trust and deepening bonds over time. Even personal growth depends on regularly dedicating time to read, learn, and reflect.

Consistency also builds discipline and resilience. It teaches you to show up even when motivation is low, relying on the habit itself to carry you forward. Motivation may spark action, but consistency sustains progress.

Focus on the Process

The secret to maintaining consistency lies in focusing on the process rather than the outcome. When you’re overly fixated on results (gaining followers, earning recognition, or hitting milestones) you risk burning out when progress feels slow.

Instead, shift your focus to the daily actions. Enjoy the act of doing, and the results will follow naturally.

For me, writing has become more than a way to share knowledge, it’s a tool for reflection, a source of joy, and a practice of consistency.

So let’s see what is the balance at the end of 2025 and if I can keep going deeper into this rabbit hole, it’s exciting not knowing what’s at the end of it, see you on the other side!

Is AGI Already Here?

Mon, 30 Dec 2024 00:00:00 GMT

The pursuit of Artificial General Intelligence (AGI) has been a long-standing fascination, sparking debates across scientific, philosophical, and technological spheres.

With rapid advancements in AI, the question of whether AGI has already arrived feels more relevant than ever.

This article explores evolving definitions of AGI, its societal implications, and the critical ethical and regulatory challenges it presents.

What Is AGI, and Why Does Its Definition Matter?

As defined by Wikipedia, AGI refers to artificial intelligence that matches or surpasses human cognitive capabilities across a wide range of cognitive tasks. This contrasts with “narrow AI”, which is limited to specific tasks.

AGI is often referred to as “strong AI,” while Artificial Superintelligence (ASI), on the other hand, represents a future state where AI far surpasses human intelligence.

However, the definition of AGI is far from universal. For some organizations, it serves as a marketing buzzword aimed at attracting venture capital. This ambiguity complicates efforts to determine when AGI has genuinely been achieved and what that milestone truly signifies.

AGI vs. Mimicry

Large language models (LLMs) like GPT-4o, Llama 3.3, DeepSeek 685B, Claude 3.5, to name a few, have intensified debates around AGI. These systems mimic reasoning and perform tasks that often appear indistinguishable from human cognition. Yet, most experts agree that mimicry is not the same as true AGI, a self-aware, autonomous intelligence capable of independent decision making.

LLMs are highly skilled at recognizing patterns and generating coherent outputs, but their process lacks genuine understanding. Yet even human scientific methodologies often follow patterns: observe, hypothesize, and verify.

This raises a profound question: Does the distinction between mimicry and genuine intelligence matter if these systems outperform humans in many cognitive tasks?

Have We Already Achieved AGI?

Some argue that we may already live in a post-AGI world. Advanced models like OpenAI’s recently launched o3 exceed human cognitive performance in various tasks. While they may not outmatch every human in every domain, they are “better than most humans at most tasks”, according to specialists in the field and different benchmarks.

I’m not a fan of benchmarks, it is not usually reported exactly what was used to generate them, sometimes they are real for a certain domain or problem but not for others and we can discuss them for hours.

What is undeniable for anyone who has interacted with these recent models is that for a large percentage of tasks they work very well, and paradoxically to what people think, the more knowledge we have about the subject we are trying to solve, the better the results obtained, since we can recognize failures or hallucinations much faster, or ask a question in a specific way reducing the context and simplifying the problem to be solved. The results obtained are mind-blowing.

This development challenges traditional notions of AGI. If current AI systems consistently perform at or above human levels in diverse areas, does the concept of AGI as a distinct milestone become obsolete? OpenAI CEO Sam Altman suggests that as we near AGI, the term itself loses relevance, shifting focus to practical capabilities over theoretical labels.

Transforming Daily Life: Implications of Advanced AI

The accelerating evolution of AI systems is reshaping everyday life in profound ways. From healthcare diagnostics to legal assistance, AI is becoming an indispensable tool.

While these advancements promise greater efficiency and accessibility, they also raise critical challenges:

Job Displacement: As AI outperforms humans in more tasks, industries face potential disruptions, threatening livelihoods.
Education: Bridging the knowledge gap between advanced AI systems and the average user is crucial for effective integration.
Ethics: Ensuring that AI aligns with societal values and avoids perpetuating biases is an ongoing challenge.

Navigating Regulation and Privacy in Uncharted Waters

AI policy remains a novel area, full with uncertainties. Over-regulating a nascent industry risks stifling innovation, while inaction could lead to dire consequences. Key concerns include:

Privacy: AI systems trained on vast datasets often process sensitive personal information, raising serious ethical concerns.
Accountability: Determining responsibility for decisions made by autonomous systems is a legal and moral dilemma.
Global Standards: A lack of international consensus on AI regulation creates an uneven playing field and opportunities for misuse.

The increasing capabilities of AI demand an urgent, balanced approach to regulation, one that fosters innovation while safeguarding public interests. To be honest, achieving this globally sounds more difficult than achieving true AGI itself.

We have already seen this with social media, and how bureaucracy and the ignorance of those who have to legislate on these issues, leave the important discussions behind until it is too late. The truth is that the genie is out of the bottle and nothing can stop it.

Redefining AGI for the Future

Traditional benchmarks for intelligence struggle to keep pace with modern AI. Current systems, like LLMs, possess vast general knowledge derived from their training on extensive datasets. Yet the debate persists: Does this knowledge equal understanding?

Many experts advocate for moving away from viewing AGI as a singular milestone. Instead, they propose recognizing incremental advancements that highlight the practical utility of AI systems without getting bogged down in philosophical debates about consciousness.

Discussions about AGI often intersect with debates on the nature of human intelligence, which is far from a singular concept. Traditional measures of intelligence, such as logical reasoning and problem-solving, have long been central to defining human cognitive ability. However, frameworks like Howard Gardner’s theory of multiple intelligences highlight other dimensions, such as emotional intelligence (EQ), interpersonal skills, creativity, and even kinesthetic and spatial intelligence.

These broader definitions challenge the narrow, logic-centric benchmarks typically used in AGI discussions. Current AI systems excel in logical and analytical domains but struggle to replicate the nuanced emotional understanding or social intuition that humans exhibit daily.

For all these concepts there is no majority consensus, so even in the definition of human intelligence as we know it there are still discussions about it.

But this raises some good questions: Should AGI strive to emulate the full spectrum of human intelligence, or is replicating specific domains sufficient? Incorporating this multidimensional perspective into AGI debates not only broadens our understanding of intelligence but also helps define what constitutes “general” in artificial general intelligence.

Conclusion: The Dawn of a New Era

Whether AGI has “officially” arrived largely depends on how one defines it. What is undeniable, however, is that advanced AI systems are reshaping the boundaries of human cognition and capability. As new and better AI models emerge, the implications for humanity grow ever more profound.

From redefining intelligence to addressing regulatory and ethical challenges, the journey towards AGI is as much about humanity’s evolution as it is about technological progress.

One thing is clear, whether or not we call it AGI, the era of transformative AI is already here, and its impact will only deepen in the years to come.

Like all technology, it will have good and bad uses, but we are going through an exciting moment in history. I always like to think that the best is yet to come, that we will be able to solve existing problems that were unthinkable a few years ago, and find different ways to help and improve everyone’s lives.

Fasten your seatbelts, 2025 is about to take off and this new propulsion system we call AI is going to reach new speeds.

Exploring Sora by OpenAI: My First Impressions 🚀

Mon, 23 Dec 2024 00:00:00 GMT

Yesterday, I had the opportunity to explore Sora by OpenAI. What I discovered was not just a tool but a visionary glimpse into the future of creativity.

Here’s what stood out and why I think Sora and future video generation models are set to revolutionize content creation.

Custom Presets and Storyboard

One of Sora’s most compelling features is its customizable presets. These presets allow creators to configure and fine-tune creative elements effortlessly, unlocking boundless possibilities. Here are some of the standout options:

🎨 Color: Tailor the palette to match the mood or theme of your project. 🎥 Camera: Specify angles and movements for cinematic precision. 💡 Lighting: Set the ambiance with detailed lighting controls. 🌟 Vibe: Infuse your video with a distinct aesthetic or emotion. 📽️ Film Stock: Emulate classic or contemporary film styles. 🔄 Content Transformation: Seamlessly morph and adapt visual elements.

The ability to experiment with and reuse presets makes Sora a versatile powerhouse for creators. Whether you’re aiming for consistency across projects or exploring bold variations, the potential feels limitless.

Another standout feature of Sora is its storyboard tool, which allows users to precisely specify inputs for each frame of their video. This granular level of control ensures that every detail aligns perfectly with your creative vision, making it ideal for complex projects or storytelling with sequential visual cues.

Additionally, Sora supports image uploads, enabling you to animate any static image seamlessly. Whether you want to breathe life into an illustration, transform a photo into a dynamic scene, or build intricate animations frame by frame, these tools open up endless opportunities for creators to craft truly unique and personalized content.

The Power of Presets: Redefining Simplicity

Sora’s presets don’t just enhance creativity, they simplify it. The big range of styles and variations achievable with presets alone it’s amazing. Instead of obsessing over every visual detail (presets take care of most of this), you can focus on what truly matters: crafting compelling actions, characters, and narratives.

This streamlining is a game-changer for creativity, offering a perfect balance between efficiency and high-quality output. It’s clear that Sora was designed with creators in mind.

Keep It Simple: The Art of Prompting

One of the more surprising revelations was how well Sora responds to simple prompts. While you might assume that more detailed instructions yield better results, the opposite often holds true.

For instance:

Instead of: “A dramatic sunset over a futuristic city with intricate holograms and flying cars,”
Try: “A sunset over a futuristic city with flying cars.”

The simplified prompt often delivers clearer, more visually coherent results, avoiding the risk of overloading the system and generating unintended artifacts (or hallucinations). This underscores the importance of precision over complexity.

Generational Quality: A Leap Forward

Sora feels like a leap into the next generation of AI video creation. It’s reminiscent of the early days of AI image generation, where the results were groundbreaking yet rough around the edges. Fast forward to today, and we’re seeing polished, near-photorealistic images.

Sora’s videos are impressive, even in this early stage. They already hint at a future where AI video rivals (and perhaps surpasses) the fidelity and artistry we currently associate with image models.

By 2025, it’s easy to imagine the wow factor of video models reaching jaw-dropping new heights, and not only Sora but all the new video generation models that are appearing.

Looking Ahead: The Bright Future of AI Video

The future of AI video generation isn’t just promising, it’s exhilarating. As models evolve, here are a few advancements we can anticipate:

Real-time video generation for interactive content.
Hyper-realistic visuals with minimal artifacts or imperfections.
Greater accessibility, empowering non-creatives to bring their visions to life with just a few words.

These innovations will redefine what’s possible for creators, educators, marketers, and storytellers alike.

By blending imagination with cutting-edge technology, 2025 is shaping up to be a year where creativity and reality intertwine in unprecedented ways.

Here are some examples of videos I generate, playing a little bit with it:

Final Thoughts

Sora by OpenAI represents the dawn of a new era in video generation. With its intuitive presets, emphasis on simplicity, and impressive generational quality, it’s an essential tool for creators ready to explore uncharted territory.

As AI models continue to advance, the only true limits will be the boundaries of our imagination. Creativity, once constrained by tools and technical know-how, is now liberated to soar higher than ever before.

The future of AI-driven creativity is here, and it’s only getting brighter, 2025 is going to be 🔥 🚀

The Silent Struggles of Working in Oversized Organizations

Tue, 17 Dec 2024 00:00:00 GMT

In large companies, inefficiencies often become normalized, hidden behind layers of bureaucracy and seemingly functional structures.

These challenges don’t always manifest in obvious ways, like interpersonal conflict or toxic behaviors, but rather in slow-moving systems, poor team dynamics, and a lack of effective leadership.

Over time, these hidden struggles can erode productivity, morale, and innovation, and they’re much harder to detect and address.

The Hidden Problem Behind the Facade

At first glance, everything might look fine. Teams appear supportive, leaders seem approachable, and processes give an impression of order.

However, as time passes, cracks begin to show: inefficiencies, stagnation, and growing frustration among team members. These issues are often due to oversized organizational structures, where layers of bureaucracy and poor decision-making create obstacles rather than opportunities.

One of the most common underlying problem is the lack of competence and that some people reach certain decision-making positions not because of their skills but because of their time in the company. These people end up making many bad decisions, or worse, no decisions at all, which prolongs unnecessary discussions and demoralizes everyone involved, which ultimately affects all team members.

Another common one is the balance between senior and junior devs. In a high-functioning team, having one or two members with less experience isn’t an issue, others can step in to guide and support them. But when the majority of the team lacks necessary skills or merely does the bare minimum to get by (don’t get me started on underperforming devs), the burden falls disproportionately on the more competent members. Over time, this imbalance can cause burnout and demotivation.

How Bureaucracy and Inefficiency Manifest

In large companies, the problems are often isolated to certain teams, but if they spread across departments, they can have a significant impact on operations, delaying features, neglecting bugs, and ultimately affecting the user experience.

Below are some of the most common problems you may encounter.

1. Ineffective Leadership

Teams without strong, empowered leadership struggle to prioritize tasks, manage workloads, or implement meaningful improvements. Overloaded leaders or absent technical direction further aggravate the problem.

2. Bureaucratic Overload

Simple tasks become drawn-out projects due to unnecessary processes, approval loops, excessive documentation and meetings to plan other meetings (this sounds like a joke, but it’s not).

3. Artificial Success Metrics

Performance indicators are manipulated to “show progress” while real issues remain unresolved, creating a false sense of achievement.

4. Burnout Among Skilled Team Members

Competent members often shoulder the burden of others’ inefficiencies, leading to frustration and eventual burnout.

Why These Struggles Are Hard to Detect

Unlike other dysfunction, such as interpersonal conflict or toxic behavior, inefficiencies in large organizations are often masked by the appearance of normality.

Bureaucratic processes and polished reports give the impression that everything is under control. However, for those within these teams, the reality can be very different: tasks stall, frustration builds, and true progress becomes increasingly difficult to achieve.

Having spent over 15 years navigating such environments, I’ve seen these scenarios play out repeatedly. In some cases, the problems are so deeply embedded that only senior management intervention can enact meaningful change.

When leadership is unwilling or unable to act, staying in these environments often leads to burnout. Other times, cultural resistance to change or a preference for sticking to the status quo, makes improvement almost impossible.

In these cases, walking away is often the best choice for you.

When It’s Worth Pushing for Change

Occasionally, you may find individuals within the organization who recognize the same issues and want to make improvements. While these opportunities are rare, they are worth pursuing.

Here’s how you can approach such situations:

Speak Up: Clearly articulate the problems you see and propose actionable solutions in meetings or one-on-one conversations.
Focus on Solutions: When raising concerns, always come prepared with alternatives or ideas for improvement.
Engage Leadership: Work with managers or project leads to gain their buy-in and push for necessary changes.

The process is rarely easy. It can lead to uncomfortable conversations, resistance, or delays as teams debate the feasibility of proposed changes.

However, when project leaders and managers feel the same pain points, they are often receptive to solutions like reorganizing teams, streamlining processes, or dedicating time to address technical debt.

If your efforts to drive change are met with indifference or resistance, it’s a strong indicator that the environment isn’t conducive to improvement. In such cases, again, leaving may be the healthiest option for your career and well-being.

Tips for Navigating These Challenges

1. Propose Solutions, Not Just Problems

Don’t be the person who points out issues without offering ideas for improvement. Constructive feedback is far more effective.

2. Communicate Clearly

Learn to express your ideas in a way that resonates with different roles (e.g., QA, developers, managers, product owners). Tailoring your message increases the likelihood of being understood and supported.

3. Embrace the Process

Even if your suggestions don’t lead to immediate changes, the experience will teach you valuable skills in communication, teamwork, and problem-solving.

4. Know When to Walk Away

Not every environment is worth fixing. Recognizing this early can save you time, energy, and stress.

The Value of These Experiences

Even failed attempts to drive change can be transformative.

Identifying problems, communicating effectively, and proposing solutions are essential skills for advancing in your career. These experiences prepare you for leadership roles by giving you a deeper understanding of team dynamics and organizational challenges.

Focus on improving what’s within your control, even if you’re not in a leadership position. Your efforts will not only benefit your team but also help you grow professionally.

The ability to navigate and address inefficiencies in oversized organizations is a valuable skill that will serve you well.

Don’t be indifferent and don’t let everything be the same for you.

Always try to do the right thing, spoiler alert, at some point in your career the right person will notice it.

Nothing Beats Meeting Face to Face

Thu, 05 Dec 2024 00:00:00 GMT

The shift to remote work has revolutionized how teams operate, offering flexibility and convenience like never before. Yet, despite these benefits, something is undeniably lost when human connections are mediated solely through screens.

In a world increasingly dominated by virtual interactions, face-to-face connections remain irreplaceable and highlights the importance of genuine team building.

My Experience: Rediscovering In-Person Connections

Last week, I had the opportunity to attend a four-day event organized by Binagora the company I work for, an annual tradition aimed at bringing remote employees together.

The event offered more than just a break from the routine, it was an opportunity to strengthen bonds in a way that only in-person interactions can achieve.

For different reasons and prior commitments, I had never attended previous editions, but this year I made it a priority. Over the past three years at this company, I’ve collaborated on numerous projects and developed strong virtual ties with my colleagues.

Working remotely since 2017 has given me a unique perspective on the challenges of maintaining professional relationships virtually, and I still think it’s the best work-life balance for the software industry. That said, after an eight-hour trip, finally meeting lot of them in person, exceeded all expectations.

In this article, I will reflect on key takeaways from the experience and provide some data and insights that support the value of face-to-face connections, at least once, in an era of remote work.

Bonding Happens Organically, Not Through Forced Interaction

One of the most important lessons I’ve learned is that genuine bonding cannot be engineered. Many corporate “team-building” activities often feel forced, with participants counting down the minutes until they can return to their work.

True connections emerge naturally, influenced by individual preferences, communication styles, and life circumstances.

Unlike many organizations that rely on cookie-cutter solutions, my company prioritizes the human aspect from the outset. During hiring, cultural alignment is as important as technical skills. This focus isn’t just corporate lip service, it’s evident in day-to-day interactions, the support team members offer one another, and the values embedded in our work culture. This authentic approach fosters a sense of belonging that carries over to in-person gatherings.

The Ripple Effect of Small Actions

Over the years I have had to mentor some colleagues and I had to conduct technical interviews with potential new candidates. I enjoyed all of these tasks, but I forgot that I had done them.

So I was very surprised when some anecdotes came up about questions asked in interviews or situations during mentoring, and we shared a lot of laughs.

One of the most heartwarming moments during the event came during casual conversations, where colleagues shared how my small actions had positively impacted their professional journeys. A few recounted instances where I had helped them integrate into the team or provided advice during their early days. These anecdotes were reminders of the ripple effects our everyday actions can have on others.

From my personal experience, employees who feel recognized and valued are more likely to perform their best at work. Moments of genuine appreciation, like those shared during our gathering, underscore how meaningful in-person interactions can be in building trust and morale.

The Unique Value of Face-to-Face Connections

Virtual communication tools like Zoom and Slack are invaluable, but they have limitations. Face-to-face interactions enable a depth of connection that video calls simply cannot replicate. Whether it’s the nuances of body language, the shared laughter over a meal, or spontaneous brainstorming sessions, these moments create bonds that last.

Although we have spent countless hours with some of them on calls and chatting about hobbies or things we like, being face to face, looking into each other’s eyes and being without a computer in between, sharing a meal, a coffee or a beer is irreplaceable. I discovered many other activities outside the technological world that several of us share and had never talked about. So I brought recommendations from movies, series, music and games, to musical groups, recipes, tips on places to eat in different cities, and the list goes on.

These interactions added a rich layer of camaraderie to our professional relationships. These exchanges build trust and empathy, two fundamental elements of teamwork.

Time Together in Person: A Catalyst for Success

Studies from MIT’s Human Dynamics Laboratory reveal that teams that have had face-to-face interactions are more productive and innovative. These interactions foster nonverbal cues, empathy, and a stronger sense of connection, all of which are harder to achieve virtually.

Reflecting on my career, the most successful projects I’ve been part of have one thing in common: we spend at least some time together in person. For example, a two-week trip to the United States for a high-stakes project not only enhanced our collaboration but also turned colleagues into lifelong friends. That specific project lasted 3 years and was completely remote, but there was a clear turning point after that two-week trip we made.

Face-to-face meetings are critical for building trust and understanding, which directly impact team performance. A Harvard Business Review study found that 95% of professionals believe in-person meetings are essential for long-term business relationships. Furthermore, teams with strong personal connections report higher levels of collaboration and problem-solving.

Remote Work and the Growing Need for In-Person Gatherings

Remote work is here to stay, but it shouldn’t come at the expense of human connection. According to a Buffer State of Remote Work Survey, loneliness is one of the top challenges for remote workers, cited by 24% of respondents. Face-to-face gatherings provide a much-needed antidote to this isolation, reinforcing a sense of community and belonging.

To address this, many companies are investing in periodic in-person events. For instance, GitLab, a fully remote company, holds an annual summit where team members gather from around the globe. These efforts are crucial in maintaining strong team dynamics in a remote-first world.

If your company organizes an in-person event, don’t hesitate, just go. Stepping out of your comfort zone to meet colleagues face to face can yield surprising rewards. The relationships you build, the trust you foster, and the memories you create will enrich your professional and personal life.

Final Thoughts

I still prefer remote work, it has a lot of benefits for both our personal and professional life, but occasionally meeting your colleagues or at least meeting them in person once, adds trust and a whole different approach to teamwork.

The ability to sit down, share stories, and laugh with colleagues in person adds an invaluable dimension to our relationships. As we navigate the future of work, let’s not lose sight of the power of genuine human connection.

Let me end with this: “One face-to-face meeting is worth a thousand virtual calls”.

My Experience Giving an On-Site Tech Talk

Tue, 26 Nov 2024 00:00:00 GMT

Last week, I had the exciting opportunity to give a tech talk for the JavaScript community in Montevideo, Uruguay, about Microfrontends.

While I’ve done some presentations before, this one felt different, it was entirely in person, hosted in an office and with an audience of people I didn’t know. It marked a big shift from the virtual setups I’m used to, like Zoom or Google Meet.

It was a learning experience in the best way possible. It wasn’t just about delivering the talk, it was about preparation, connecting with a live audience, and growing as a communicator.

In this article, I’ll share my insights, blending my experience with some tried-and-true advice on giving effective tech talks.

Whether you’re considering giving your first talk or looking to improve, I hope you find these tips helpful.

Why Give a Tech Talk?

Let’s be honest, public speaking can feel intimidating, and the prep work takes effort. So, why even bother? Because the rewards far outweigh the nerves:

Share Knowledge: Contribute to your community and help others learn.
Build Confidence: Strengthen your communication and storytelling skills.
Make Connections: Talks open doors to collaborations, friendships, and career opportunities.

Whether you’re an expert or a curious learner with something to share, giving a tech talk is an incredible way to grow and make an impact.

What I Learned from This Experience

Giving a tech talk in person feels different from a virtual one. It’s rawer, more immediate, and, honestly, a little more intimidating. Here’s what stood out:

1. Nerves Are Normal

Standing in front of strangers can feel overwhelming, but nerves are part of the process. I leaned into preparation, practicing my material multiple times, and reminded myself that the audience wasn’t there to judge. They were there to learn, just like I’ve been in their shoes at countless talks.

2. Keep It Engaging

Tech talks can sometimes get too serious or dry. I wanted my presentation to feel approachable and enjoyable, even while discussing technical concepts. I included a bit of humor, paused to ask the audience questions, and used relatable analogies to keep the atmosphere relaxed.

Takeaway: Your talk isn’t just about content, it’s about how you deliver it. Make it fun, engaging, and interactive.

3. Focus on Value

Rather than proving my expertise, I aimed to provide actionable insights the audience could take away. For example, I shared practical trade-offs in microfrontend architectures and included digestible code snippets they could try on their own.

Ask yourself: What will attendees remember or use after your talk? Design your content around that.

How to Prepare for a Tech Talk

Preparation is everything. Here’s my process, combined with some classic advice for crafting a memorable presentation:

1. Start with a Story

Every great talk follows a narrative structure. Here’s a simple framework:

Introduction: Introduce your topic, explain why it matters, and outline the problem you’re solving.
Development: Dive into the details with examples, stories, and trade-offs. Share challenges and lessons.
Conclusion: Wrap up with practical takeaways, like code snippets, demos, or resources for further exploration.

Audiences don’t want a textbook, they want your unique perspective and experience. Stories make your talk stick.

2. Make Slides Your Ally

Slides should enhance your talk, not distract from it. Keep them clean and purposeful:

Use bullet points sparingly.
Include visuals like diagrams, charts, or simple code snippets.
Avoid text heavy slides, your audience is there to listen, not read.

I also made my slides accessible online afterward so attendees could revisit them. Sharing resources helps extend the value of your talk beyond the event.

3. Practice Until It Flows

Rehearsal isn’t just about memorizing words. It’s about:

Timing: Ensuring your talk fits within the allotted time.
Flow: Spotting gaps or awkward transitions.
Confidence: Building muscle memory so you can focus on connecting with the audience, not on remembering your next point.

Another option that many use is to record themselves, it can be a little embarrassing at first, but it is incredibly useful.

4. Engage Your Audience

Interaction turns a passive audience into an active one. Early in my talk, I asked how many attendees had experience with microfrontends. This helped break the ice and gave me cues to adjust my explanations.

Ideas to try:

Ask questions or conduct quick polls.
Encourage people to share their own experiences.
Save time for a Q&A session at the end.

5. Be Yourself

This might sound cliché, but it’s true: authenticity matters. Share your personality through humor, anecdotes, or even the way you explain things. People connect with speakers who feel genuine, not perfect.

Common Advice for Effective Tech Talks

Here’s a quick roundup of widely recommended tips that worked for me:

Know Your Audience: Tailor your content to their expertise. Beginners? Stick to the basics. Advanced crowd? Dive deeper into technical details.
Pace Yourself: Avoid overwhelming your audience with too much information at once. Give them time to absorb key points.
Break the Monotony: A light joke, a relevant meme, or a visual break can refresh the room’s energy after heavy technical content.
Anticipate Questions: Think about potential queries and prepare answers. It’s okay to admit if you don’t know something, but being ready shows you’ve thought things through.
Learn from Others: Watch tech talks to see what works. Borrow ideas and adapt them to your style.

Encouraging Others to Give It a Try

If you’ve ever thought about giving a tech talk, I encourage you to take the leap.

You don’t need to be a seasoned expert, some of the most inspiring talks I’ve attended came from people sharing their side projects or lessons learned.

Start small:

Speak at local meetups or company events.
Record a short talk and share it online.
Volunteer for a topic you’re passionate about.

Your first talk might feel clunky, and that’s okay. The key is to start, gather feedback, and improve with each attempt. Over time, you’ll find your rhythm and build confidence.

Final Thoughts

Giving this in-person talk reminded me why I love sharing knowledge, it’s not just about teaching but also about connecting, learning, and growing. Standing in front of an audience, seeing their engagement, and sparking conversations afterward was incredibly rewarding.

If you’re on the fence about giving a talk, let this be some encouragement. Your perspective, experiences, and lessons learned are valuable. Whether it’s your first talk or your fiftieth, every presentation is a chance to grow, not just as a speaker, but as part of a larger community.

So go ahead, take the stage. You might just surprise yourself.

Microfrontends a Developer's Guide: Best Practices and Lessons Learned

Wed, 20 Nov 2024 00:00:00 GMT

In this final article of the microfrontends series, we will discuss some best practices for implementing microfrontends, share lessons learned from real-world experience, and provide a practical example of adding a new microfrontend to an existing architecture.

These insights will help you navigate the complexities of building and maintaining a microfrontend-based application, ensuring it is scalable, maintainable, and easy to work with.

Best Practices for Implementing Microfrontends

Implementing microfrontends can introduce a number of challenges. Following best practices can help teams overcome these challenges and create a well-structured application:

Define Clear Boundaries: One of the most important aspects of microfrontends is defining clear boundaries for each microfrontend. Each microfrontend should have a well-defined purpose, focusing on a specific business feature or domain. This helps ensure that each microfrontend remains small, maintainable, and easy to reason about.
Establish a Shared Design System: Consistency in the user experience is crucial when working with multiple microfrontends. Establishing a shared design system that includes reusable UI components, styles, and design guidelines ensures that all microfrontends follow the same visual language, providing a cohesive user experience across the application.
Minimize Shared State: One of the key principles of microfrontends is independence. To maintain autonomy, it is best to minimize shared state between microfrontends. Any shared state should be well-defined and managed through a centralized utility, such as an event bus or shared service, to avoid creating tight dependencies.
Standardize Communication Contracts: Communication between microfrontends should be standardized through well-defined contracts. Whether you are using RxJS, a global event bus, or shared state management, defining clear communication contracts ensures that different microfrontends can interact seamlessly without breaking each other.
Use Lazy Loading: To improve performance, use lazy loading to load microfrontends only when they are needed. This helps reduce the initial load time of the application and ensures that users only download the code relevant to the current page or feature they are interacting with.
Version Control and Dependency Management: Proper version control and dependency management are essential for maintaining a stable microfrontend architecture. Use tools like import maps to manage versions of shared dependencies and ensure compatibility across microfrontends. This allows for updates to be made safely without breaking the application.
Automate Testing and Deployment: Each microfrontend should have its own testing and deployment pipeline. Automating unit tests, integration tests, and end-to-end tests ensures that microfrontends work correctly both in isolation and as part of the larger application. Automated deployments allow teams to release updates independently without disrupting the overall application.

Lessons Learned from Real-World Implementations

After working on several microfrontend projects, we have gathered a few lessons that can help you avoid common pitfalls:

Start Small and Grow: It is best to start with a small proof of concept before transitioning your entire application to a microfrontend architecture. This approach allows your team to get familiar with the tools and processes involved and identify potential challenges early on.
Avoid Over-Engineering: Microfrontends can add complexity to your project, so it is important not to over-engineer the solution. Use microfrontends only when necessary—typically for large applications with multiple teams working on different features. For smaller projects, the added complexity may not be justified.
Staying Ahead of Potential Impacts: Microfrontend architectures reduce the need for constant communication between teams, allowing them to work more independently. However, it’s crucial for team leads to stay informed about changes in other microfrontends that could impact their project, ensuring smooth integration and overall system stability.
Prioritize Performance Optimization: Performance can be a challenge in a microfrontend architecture, especially when each microfrontend has its own set of dependencies. Prioritize performance optimization by reducing duplicate dependencies, using lazy loading, and leveraging caching where possible.
Cultivate Consistency Without Limiting Innovation: While consistency in UI/UX is important, allow teams the flexibility to innovate within their microfrontends. Set up shared standards for design and communication, but don’t constrain teams by enforcing unnecessary restrictions on technology choices. Balance autonomy with consistency.

To demonstrate how to add a new microfrontend to an existing architecture, let’s walk through the process of adding a Footer microfrontend to our current setup.

This exercise will give you hands-on experience with integration patterns and demonstrate how microfrontends can maintain a cohesive user experience.

Use the Single-Spa CLI to generate the new microfrontend for the footer:

npx create-single-spa --module-type app-parcel

This command will scaffold a new microfrontend project that can be customized for the footer.

Create the Footer component as part of the new microfrontend. You can use your preferred technology or experiment by building the component with different technologies to explore various integration approaches and understand the nuances of each.

A typical footer includes elements like links, copyright information, and other global site details.

Ensure the component adheres to the shared design system for consistent styling across the application, regardless of the technology used.

Update the import map in the root config project, to include the new footer microfrontend. This allows the root config to know where the footer code is located and how to load it.

Example, import map configuration:

{
  "imports": {
    // ... other microfrontends
    "@project/footer": "https://cdn.example.com/footer.js"
  }
}

Replace it with your microfrontend url, and bundle filename.

Modify the root config to load the footer at the appropriate place in the application’s layout.

This could be done by adding a reference to the footer microfrontend in the root layout html file, example:

<single-spa-router>
  <header>
    <application name="@project/navigation"></application>
  </header>

  <main class="main">
    // your apps and routes
  </main>

  // new footer component
  <footer>
    <application name="@project/footer"></application>
  </footer>
</single-spa-router>

Step 5: Testing the Integration

Ensure that the footer microfrontend is working correctly. Test the entire application to make sure that, the footer integrates well with the existing microfrontends, complies with the shared design standards, and does not introduce any new issues.

Automated tests should be added to validate the integration of the footer with other microfrontends, ensuring that links and interactions behave as expected.

Conclusion

Implementing microfrontends requires careful planning and adherence to best practices to ensure scalability, maintainability, and a cohesive user experience. By defining clear boundaries, establishing shared design systems, and using tools like Single-Spa, you can create a modular and flexible architecture that supports independent development and deployment.

In this article, we explored best practices for microfrontends, shared lessons learned from real-world experience, and provided a practical example of adding a new microfrontend to an existing application.

We hope this series has provided you with the insights and tools needed to start your own microfrontend journey.

Remember, while microfrontends can be a powerful tool for large applications, always evaluate the trade-offs to ensure that they are the right fit for your project.

Now go and build something cool!

Microfrontends a Developer's Guide: Exploring Projects and Managing Communication

Mon, 18 Nov 2024 00:00:00 GMT

In our previous article, we covered the tools and technologies for building microfrontends, including a step-by-step guide to setting up a microfrontend architecture using Single-Spa.

Now, let’s explore specific microfrontend projects and understand how different technologies can be used together to create a cohesive application.

We will also discuss how to manage communication between these microfrontends to ensure a seamless user experience.

And finally we’ll provide links to different repositories we created on GitHub for each microfrontend described, so you can clone and run the entire project, play with it, look at the code, or use it as reference.

Overview of Microfrontend Projects

To illustrate the potential of microfrontends, let’s take a look at an example setup where we have divided a large-scale application into different microfrontend projects:

Navigation: Built using React, this microfrontend is responsible for rendering the main navigation bar across the application.
Products: Developed with Vue, this microfrontend displays product listings and details. It focuses on the user interface for browsing products.
Checkout: Built using Angular, this microfrontend handles the checkout process, including the shopping cart and payment flow.
Utility Module: Created with RxJS and Single-Spa, this microfrontend manages shared utilities and handles communication between different parts of the application.

Each of these microfrontends is an independent application that can be developed, tested, and deployed separately. Let’s explore each one in more detail.

We mix all this techs to show the possibilities of what you can do, in a real project you’ll probably have 1 or 2 frameworks at most. And in my personal opinion it is not a good practice to mix them all, just because you can do it, doesn’t mean you should do it.

The Navigation microfrontend provides a consistent navigation experience across the application. It is built using React and serves as a shared component for the entire application.

By developing the navigation as a microfrontend, it can be updated independently of the other parts of the application. For example, if there is a design change or a new menu item needs to be added, the navigation team can make those changes without affecting the rest of the application.

Key Considerations: Make sure that navigation seamlessly integrates with other microfrontends. Any changes in routes or URLs need to be carefully coordinated with other microfrontends to ensure a smooth user experience.

Products Microfrontend (Vue)

The Products microfrontend handles the product catalog and is built using Vue. This microfrontend is responsible for displaying product listings, product details, and filtering options.

Vue was chosen for its lightweight nature and its ease of integration into existing applications, making it a good choice for developing feature-focused microfrontends like the product catalog.

Key Considerations: Ensure consistent styling across the entire application. Vue components should follow a shared design system to maintain a consistent look and feel across the application.

Checkout Microfrontend (Angular)

The Checkout microfrontend is built using Angular and focuses on the checkout experience, including handling the shopping cart, customer information, and payment flow.

Angular is a good choice for this part of the application due to its strong support for building complex forms, as well as its dependency injection system, which can simplify state management within the checkout process.

Key Considerations: The checkout microfrontend must interact smoothly with the products microfrontend to ensure that products added to the cart are correctly carried over to the checkout process.

Utility Module (RxJS and Single-Spa)

The Utility Module is built with RxJS and Single-Spa to manage cross-microfrontend communication. This module serves as a shared utility that can be used to share state, trigger events, or communicate between different microfrontends.

RxJS is particularly useful for implementing the Observer Pattern, allowing different microfrontends to subscribe to events and react accordingly. For instance, if a user adds an item to their cart in the Products microfrontend, the Checkout microfrontend can be notified through the utility module to update the cart contents.

Key Considerations: Communication between microfrontends should be designed in such a way that they remain loosely coupled. Using RxJS allows for asynchronous communication without creating tight dependencies between different microfrontends.

Managing Communication Between Microfrontends

Effective communication between microfrontends is crucial for maintaining a seamless user experience. There are several approaches to manage this communication, depending on the complexity of the application and the requirements of the microfrontends.

Global Event Bus

A global event bus is a simple way to manage communication between microfrontends. It acts as a central hub where microfrontends can publish and subscribe to events. This is similar to an event emitter, allowing different parts of the application to communicate without directly referencing each other.

In our setup, RxJS can be used as a global event bus, allowing microfrontends to broadcast events (e.g., item added to cart) and enabling other microfrontends to react accordingly.

Shared State Management

In more complex scenarios, a shared state management solution can be implemented. This involves creating a global state that is accessible to all microfrontends, allowing for consistent data across different parts of the application.

Libraries like Redux or MobX can be used for state management, but it is important to weigh the pros and cons of introducing a centralized state.

For microfrontends, it is crucial to maintain independence, so any shared state should be minimal and well-defined. For example, if you have to share a lot of state between two microfrontends, that’s usually a sign that you should merge the logic into a single microfrontend, as always this will depend on several factors, so analyze and evaluate the trade-offs based on your needs.

Cross-Frontend Communication with RxJS

As mentioned earlier, RxJS is well-suited for managing communication between microfrontends. By using subjects and observables, microfrontends can subscribe to changes and react accordingly.

For example, the Products microfrontend can use an RxJS subject to broadcast when an item is added to the cart, and the Checkout microfrontend can subscribe to this event to ensure that the cart is updated.

Ensuring Consistency Across Microfrontends

One of the challenges of using microfrontends is ensuring a consistent user experience across different parts of the application. Here are some best practices to help achieve consistency:

Shared Design System: Establish a shared design system that includes reusable components, styles, and guidelines. This ensures that all microfrontends follow the same visual language and provide a cohesive user experience.
Centralized Utilities: Create centralized utilities for common functionality (e.g., API calls, authentication) to avoid duplication and ensure consistent behavior across microfrontends.
Communication Contracts: Define clear communication contracts between microfrontends. This helps prevent breaking changes and ensures that all microfrontends can integrate seamlessly without unexpected issues.

GitHub Projects

In the following links you can find the implementation of the different projects we went through:

Conclusion

Exploring different microfrontend projects highlights the flexibility of a microfrontend architecture. By splitting a large application into smaller, independently deployable units, teams can work autonomously while ensuring that the overall user experience remains consistent.

Managing communication between microfrontends is key to providing a cohesive application, and tools like RxJS can help facilitate this communication in a loosely coupled manner.

In the next and final article of this series, we will explore best practices and lessons learned from implementing microfrontends, along with a practical example of adding a new microfrontend to the existing architecture.

Microfrontends a Developer's Guide: Tools, Technologies, and Step-by-Step Setup

Sat, 16 Nov 2024 00:00:00 GMT

In the previous articles, we introduced the concept of microfrontends and discussed their advantages and disadvantages. Now it’s time to dive into the tools and technologies that can help bring a microfrontend architecture to life.

We will cover some of the popular frameworks and libraries available, and guide you through setting up a microfrontend architecture using Single-Spa.

Overview of Microfrontend Tools and Technologies

The adoption of microfrontends has led to the development of several tools and libraries that facilitate the implementation and integration of multiple frontend applications.

Below are some of the most commonly used tools.

Webpack Module Federation

Webpack Module Federation is a feature introduced in Webpack 5 that allows you to share code between different JavaScript applications at runtime. It simplifies the process of dynamically loading code from other applications, making it a powerful tool for microfrontend integration.

Advantages: Module Federation enables seamless sharing of dependencies across microfrontends, reducing duplication and improving performance. It also allows for dynamic loading, meaning teams can independently update their parts of the application without a full rebuild.
Disadvantages: One of the key challenges with Webpack Module Federation is the complexity of configuring the federation properly. Managing shared dependencies can lead to version mismatches and potential conflicts, especially when different microfrontends require different versions of the same library. Additionally, it requires deep knowledge of Webpack, which may have a steep learning curve for some developers.

Single-Spa

Single-Spa is a popular microfrontend framework that stands out due to its runtime integration capabilities and true framework-agnostic approach that allows you to combine multiple JavaScript frameworks in a single application. It serves as a “root config” that helps in managing how different microfrontends are loaded and interact with each other.

Advantages: It provides a centralized “root config” to orchestrate how different microfrontends are loaded and interact with each other, giving developers granular control over the lifecycle of each microfrontend. Single-Spa also offers a comprehensive set of plugins, strong community support, and detailed documentation, making it an ideal choice for those getting started or working with diverse technologies.
Disadvantages: The flexibility of combining multiple frameworks within a single application comes with added complexity. Single-Spa requires a good understanding of how each framework manages state and rendering, which can be a learning curve for teams that are not familiar with hybrid environments.

Vite Plugin Federation

Vite Plugin Federation extends Vite’s functionality by enabling module federation, similar to Webpack’s approach. This tool provides a modern alternative to traditional bundlers and focuses on faster build times.

Advantages: With Vite’s fast build times and the added benefit of module federation, this plugin is well-suited for those who prefer a modern, lightweight development experience.
Disadvantages: Vite Plugin Federation is relatively new compared to Webpack, which means it may lack the stability and maturity that Webpack provides. It also has limited community support, which can make troubleshooting issues more difficult. Compatibility with other existing tools and frameworks may also be limited.

Open Components

Open Components is a library that focuses on server-side rendering (SSR) and dynamic delivery of components. It allows developers to create reusable components that can be independently published and consumed by different applications.

Advantages: Ideal for server-side rendered applications where delivering small, reusable components is a key requirement. It helps in achieving dynamic rendering and faster time-to-interactive.
Disadvantages: Open Components can introduce additional server-side complexity, as it requires setting up and maintaining a dedicated server for delivering components. It also lacks the flexibility to handle complex frontend requirements, making it more suitable for simpler use cases. The community around Open Components is not as active, which can limit access to support and resources.

Luigi

Luigi is an open-source microfrontend framework developed by SAP. It allows developers to create a consistent navigation experience while integrating different microfrontend components.

Advantages: Luigi comes with built-in features like routing and authorization management, which makes it a strong choice for enterprise-grade applications.
Disadvantages: Luigi is tightly coupled with its own set of tools and conventions, which can limit flexibility. This can be restrictive for teams that prefer more customization or need to integrate with different routing or authorization solutions. Additionally, the learning curve can be steep, especially for developers unfamiliar with Luigi’s specific conventions.

Piral

Piral is a framework that enables you to create modular frontends using microfrontend architecture. It allows teams to independently develop and deploy different parts of an application while still delivering a cohesive user experience.

Advantages: Piral offers an extensive set of plugins and customizable options, which makes it suitable for projects that require high flexibility and modularity.
Disadvantages: The extensive customization options can make Piral challenging to configure, particularly for teams new to the framework. The complexity of setting up Piral’s infrastructure can lead to longer development times. Additionally, managing versioning and updates for shared components across microfrontends may require significant effort.

Mosaic

Mosaic is another microfrontend framework developed to help large teams build cohesive frontend applications from smaller, self-contained components. It focuses on scalability and collaboration across multiple teams.

Advantages: Mosaic emphasizes team collaboration and allows each microfrontend to be easily integrated with others, supporting scalability for larger projects.
Disadvantages: Mosaic may introduce performance overhead due to the additional layers of abstraction involved in managing microfrontends. It also requires a steep learning curve, as it involves understanding Mosaic’s specific integration and deployment workflows. The community around Mosaic is smaller compared to more established tools, which can make finding support more challenging.

Why We Choose Single-Spa

After evaluating all the options mentioned, we chose Single-Spa as our primary tool for implementing microfrontends. Here are some of the reasons behind our decision:

Comprehensive Documentation: Single-Spa has well-structured, easy-to-follow documentation that helps guide teams through the entire microfrontend lifecycle—from setup to deployment. This makes it easier for teams to onboard and begin implementing microfrontends without unnecessary delays.
Active Community: The framework’s active community ensures that there are frequent updates, improvements, and a wide range of available plugins and integrations. This community support reduces the risk of being stuck on issues and provides a wealth of resources for troubleshooting and best practices.
Runtime Integration and Framework-Agnostic Approach: Unlike other tools that are often framework-agnostic only at build-time, Single-Spa offers true runtime integration of multiple frameworks. It allows developers to mix and match different frontend technologies (e.g., React, Angular, Vue) within the same application, all managed at runtime. This flexibility makes Single-Spa uniquely capable of allowing different teams to work autonomously on different parts of the application without needing to align around a single stack or technology. This is especially valuable when migrating legacy codebases or when different teams prefer different frameworks.
Unified Orchestration and Lifecycle Management: Single-Spa provides a centralized “root config” that acts as the entry point for all microfrontends. It offers detailed lifecycle management for each microfrontend, including mounting, unmounting, and updating, allowing developers to have granular control over each part of the application. This level of control is key for optimizing performance, memory usage, and overall application behavior.
Versatile Use Cases: Single-Spa supports a wide range of use cases, including server-side rendering, lazy loading, and seamless communication between microfrontends. This makes it a comprehensive solution for complex applications that require flexibility and scalability. Its versatility allows teams to address different architectural needs, such as integrating legacy systems or gradually adopting microfrontends.
Testing and Debugging Capabilities: The robust testing and debugging tools provided by Single-Spa help developers quickly identify and resolve issues across different microfrontends. The framework supports tools that allow for isolated testing of individual microfrontends, which is crucial for maintaining stability in a complex multi-framework environment.

In summary, Single-Spa’s unique ability to handle multiple frameworks at runtime, its robust lifecycle management, and its flexibility in allowing different technologies to coexist made it the ideal choice for our microfrontend implementation.

It allows us to effectively manage complexity, support team autonomy, and maintain a consistent user experience across the entire application.

Step-by-Step Guide to Setting Up Microfrontends with Single-Spa

To help you get started with microfrontends, let’s go through the basic steps involved in setting up a microfrontend architecture using Single-Spa.

These steps are up to date with the Single-Spa documentation at the time of writing, we recommend checking the official documentation for updates.

Create the Root Config Application

The root config is the container application that serves as the entry point for your microfrontends. It handles the loading and orchestration of all the microfrontends that will be part of your application.

Use the Single-Spa CLI to generate the root config application:

npx create-single-spa --module-type root-config

This will scaffold a basic root config that can be customized to meet your specific needs.

Set Up Microfrontend Applications

Create individual microfrontends for different parts of your application. For example, you could create a Navigation microfrontend using React, a Products microfrontend using Vue, and a Checkout microfrontend using Angular (Spoiler alert: this is what we’re going to do in the next articles).

Use the Single-Spa CLI to create each of them:

npx create-single-spa --module-type app-parcel

Each microfrontend can be developed and deployed independently.

Configure Import Maps

The import map is a crucial part of Single-Spa’s architecture. It defines where each microfrontend is located, allowing the root config to dynamically load and execute them.

Import maps can be used to register the URLs for each microfrontend, making it easy to update and version different components without modifying the root config.

You can find this file in the root-config project:

src/importmap.json

Set up routing in the root config to determine when and how each microfrontend should be loaded. Single-Spa uses path-based routing, allowing each microfrontend to be mounted based on specific URL paths.

Routing can be configured to ensure a seamless transition between microfrontends, giving users the experience of a single, unified application.

To start with this, again in the root-config project, you can take a look at:

src/microfrontend-layout.html

Shared Dependencies

Sharing dependencies between microfrontends can help reduce duplication and improve performance. Single-Spa allows you to share common libraries like React or Vue across microfrontends, ensuring that each microfrontend doesn’t need to load its own instance.

In the root-config project, you can manage shared dependencies by adding them to the importmap.json file. For example:

{
  "imports": {
    "react": "https://cdn.jsdelivr.net/npm/react@17.0.2/umd/react.production.min.js",
    "react-dom": "https://cdn.jsdelivr.net/npm/react-dom@17.0.2/umd/react-dom.production.min.js"
  }
}

By using shared versions, you can ensure consistent behavior across all microfrontends and improve load performance by reducing duplication.

Communication Between Microfrontends

Communication between microfrontends can be achieved using RxJS or similar tools. This allows microfrontends to share data or trigger events without direct coupling.

To implement this, you can create a Utility Module that uses RxJS to facilitate communication.

Use the Single-Spa CLI to create it:

npx create-single-spa --module-type util-module

Inside of that project, for example, you could create a module named counter-module.ts

import { BehaviorSubject } from "rxjs";

// Initialize the shared count state with an initial value
const countSubject = new BehaviorSubject<number>(0);

// Expose an observable to subscribe to the count changes
export const count$ = countSubject.asObservable();

// Define getter and setter functions for the count
const getCartCount = (): number => {
  return countSubject.getValue();
};

export const setCartCount = (): void => {
  countSubject.next(getCartCount() + 1);
};

This utility module can be imported by different microfrontends, allowing them to communicate through events without being tightly coupled.

Conclusion

There are several tools and technologies available for implementing microfrontends, each with its own advantages and use cases.

In this article, we explored popular tools like Webpack Module Federation, Single-Spa, Vite Plugin Federation, and more. We also provided a step-by-step guide to setting up microfrontends using Single-Spa, a framework that offers flexibility, scalability, and ease of use.

In the next article, we will dive into the specifics of each microfrontend project, exploring how to implement different technologies within a cohesive microfrontend architecture.

💜 The Special Meaning Behind the New CSS Logo #rebeccapurple

Fri, 15 Nov 2024 00:00:00 GMT

CSS (Cascading Style Sheets), introduced in 1996, revolutionized how websites are designed and created. Over the years, it has become an essential part of modern web design.

In August 2024, Adam Argyle, Chrome CSS Developer Advocate at Google, launched a project to create a new official logo, highlighting CSS’s growth and relevance. The design process was open to the global community, inviting submissions and ideas for consideration.

After months of entries and voting, a final design by Javier Aguilar was chosen. On November 12, 2024, the new official CSS logo was revealed, featuring a striking purple design.

Far from being a random aesthetic choice, this color represents love, loss, and the enduring connections that bind us all.

If you’ve never heard the story behind the color #rebeccapurple, let me explain why it’s so special and a reminder of humanity within the tech world.

Who is Eric Meyer?

To understand the importance of #rebeccapurple, we must start by talking about Eric Meyer. A prominent figure in the web development community, his work with CSS has shaped how developers create websites. His books, Eric Meyer on CSS and CSS: The Definitive Guide, remain essential resources in web design education.

However, Eric’s influence goes beyond his technical expertise. He is known for his generosity, humility, and dedication to accessibility. Yet, it’s not just his professional achievements that define him—it’s the profound humanity he brought to the web community while facing personal tragedy.

The Origin of #rebeccapurple

In 2014, Eric’s life took a heartbreaking turn when his daughter, Rebecca Alison Meyer, passed away at the age of six. She loved the color purple, a shade that was always with her.

To honor her memory, a proposal was made to name a color in the CSS palette after Rebecca. The CSS Working Group and the web community supported the idea.

As a result, developers can use the name #rebeccapurple in their CSS, instead of its hexadecimal equivalent, #663399:

p {
  color: rebeccapurple;
}

Today, all modern web browsers support it.

A United Community

This proposal deeply resonated with the web development community. In a field known for precision and logic, the community showed its heart through this collective act of empathy. Developers and designers worldwide embraced the idea, moved by Rebecca’s story and Eric’s courage in sharing his grief.

Tab Atkins Jr., co-editor of the CSS Color Module Level 4, noted that this was the first time a color in the CSS specification was named in honor of a person.

Ten years later, we still remember Rebecca, and the selection of her color for the new CSS logo confirms its ongoing significance.

A Symbol of Connection

The impact of #rebeccapurple extends beyond its use in web development. It has become a powerful symbol of connection, illustrating how personal stories can shape even the most technical domains.

Today, #rebeccapurple appears in many tutorials and educational materials, teaching not only CSS mechanics but also the importance of community, empathy, remembrance, and the human stories that shape the web.

In a world dominated by screens and technical challenges, it’s a reminder that behind every line of code are people: people with lives, families, and stories.

It’s a story I didn’t know before, but one I found important to share. 💜

Microfrontends a Developer's Guide: Advantages and Disadvantages

Thu, 14 Nov 2024 00:00:00 GMT

In our previous article, we introduced the concept of microfrontends and explored the challenges that arise with monolithic frontend architectures. Now, let’s take a closer look at the advantages and disadvantages of microfrontends, helping you understand whether this architectural pattern is right for your project.

Advantages of Microfrontends

Microfrontends offer a number of benefits, especially for large-scale projects involving multiple teams and complex requirements. Here are some of the key advantages:

Independent Development: With microfrontends, teams can develop different parts of the application independently. Each microfrontend is a self-contained unit, by splitting the application into smaller parts, multiple teams can work in parallel, without interfering with each other’s progress and speeding up the development process. This reduces bottlenecks and enables faster development cycles.
Team Autonomy: Each team can have full control over its own microfrontend, including decisions about the tools, libraries, and frameworks used. This means teams can choose the technology stack that best suits their needs, promoting autonomy and reducing the need for cross-team alignment on technical details.
Independent Deployment: One of the most significant advantages of microfrontends is the ability to deploy individual parts of the application independently. This means a team can release updates or fixes to their microfrontend without waiting for other teams or redeploying the entire application. This reduces the risk of downtime and allows for more frequent, incremental and reliable releases updates.
Scalability: Microfrontends allow different parts of the application to be scaled independently. If one part of your application starts receiving a lot of traffic, it can be scaled without affecting other microfrontends. This level of flexibility is particularly important for applications that need to handle varying levels of load across different features.
Isolation: Since microfrontends are separate entities, a bug or issue in one microfrontend does not necessarily bring down the entire application. This isolation enhances the application’s overall resilience and makes it easier to identify and resolve issues.
Better Maintainability: By breaking a large application into smaller, more manageable parts, maintaining and updating the code becomes easier. Teams can focus on smaller codebases, making it simpler to understand, maintain, and refactor over time.

Disadvantages of Microfrontends

While microfrontends offer numerous benefits, they are not without their drawbacks. Here are some of the key disadvantages to consider:

Increased Complexity: Microfrontends introduce additional complexity in managing multiple codebases, deployments, and dependencies. For smaller projects, this complexity may outweigh the benefits. Setting up the infrastructure, managing different repositories, and coordinating changes can be challenging.
Consistency Challenges: Ensuring a consistent user experience across different microfrontends can be difficult. Each microfrontend may use different tools, styles, or libraries, leading to inconsistencies in the look and feel of the application. To mitigate this, teams need to establish shared guidelines for UI/UX design and maintain a common design system.
Coordination Overhead: Although teams can work independently, there is still a need for coordination to ensure that the different microfrontends integrate seamlessly. For example, changes in shared dependencies or API contracts must be communicated across teams, requiring additional planning and coordination efforts.
Performance Overheads: Integrating multiple microfrontends into a single cohesive application can lead to performance issues. Each microfrontend may have its own set of assets and dependencies, which can result in larger bundle sizes and slower page loads. Optimizing performance in a microfrontend architecture requires careful attention to shared dependencies and loading strategies.
Initial Setup and Maintenance: Setting up a microfrontend architecture requires a solid understanding of the underlying technologies and a well-thought-out development strategy. The initial setup can be time-consuming, involving tasks like configuring the container application, defining communication mechanisms, and managing routing between microfrontends. Ongoing maintenance can also be more involved compared to a monolithic approach.
Risk of Fragmentation: If teams are given too much autonomy without proper guidelines, the risk of fragmentation arises. Different teams may adopt different practices, leading to a fragmented codebase that is hard to maintain in the long run. Establishing governance and shared best practices is essential to avoid this pitfall.

Conclusion

Microfrontends offer a compelling solution for organizations dealing with large, complex frontend applications, providing benefits like team autonomy, independent deployments, and scalability. However, they also come with their own set of challenges, including increased complexity, coordination overhead, and the need to maintain consistency across the application.

Before adopting microfrontends, it’s important to carefully evaluate your project’s requirements and weigh the pros and cons.

If your application is large and requires multiple teams working on distinct features, microfrontends can be a game-changer. On the other hand, if you’re working on a smaller project, the added complexity may not be worth it.

In the next article, we will explore the tools and technologies for building microfrontends, including a step-by-step guide to setting up a microfrontend architecture using Single-Spa.

Microfrontends a Developer's Guide: The Challenges of Monolithic Frontends

Tue, 12 Nov 2024 00:00:00 GMT

This is the first article in a 5-part series on microfrontends.

In this series, we’ll explore what microfrontends are, their advantages and disadvantages, tools and technologies for implementation, and project examples, including links to my public GitHub repositories related to this topic.

We’ll also cover best practices to help you navigate the complexities of building and maintaining a microfrontend architecture.

Introduction

In the world of modern web development, scalability and maintainability are key challenges. As applications grow, the traditional monolithic approach to building frontends often starts to show its limitations.

Enter microfrontends: an architectural pattern designed to address the growing complexity of large-scale frontend applications. In this article, we will explore what microfrontends are, why they matter, and how they help solve some of the common problems faced by monolithic frontends.

The Monolithic Frontend Problem

Monolithic frontend applications are those where the entire user interface is built as a single, unified codebase. While this approach works well for small to medium-sized projects, it can become a burden as the application scales.

As the codebase grows, so do the challenges of maintaining and enhancing it. Let’s take a closer look at some of these challenges:

Difficult Onboarding: Onboarding new developers to a monolithic frontend can be challenging. The larger the codebase, the longer it takes for a new team member to become productive. Understanding dependencies, architectural decisions, and intricate business logic is often overwhelming.
Slowed Development Process: A monolithic structure can create bottlenecks in the development process. Multiple teams working on the same codebase often require careful coordination to avoid stepping on each other’s toes, leading to delays in releasing new features.
Deployment Complexity: In a monolithic application, every change—even a minor one—requires a full redeployment. This process increases the risk of something going wrong, especially when changes made in one part of the application unexpectedly impact other parts.
Code Conflicts: With multiple developers working on the same project, the risk of code conflicts is high. Managing merges and handling version control can quickly become a complex and time-consuming endeavor.
Team Coordination Overhead: The larger a team working on a monolith, the more coordination is required. It can be difficult to clearly define team responsibilities, which often leads to duplicated efforts or conflicting approaches to solving the same problem.

These challenges are not unique, and many organizations have faced them as their applications grew. To tackle these issues, the industry started adopting microfrontends as a solution.

What are Microfrontends?

Microfrontends are an architectural pattern in which a large frontend application is broken down into smaller, independent parts, often called “micro-apps.” Each micro-app serves a specific business function or user feature and can be developed, tested, and deployed independently.

The goal of microfrontends is to bring the benefits of microservices to the frontend world. In a microfrontend architecture, different teams can work autonomously on different parts of the application without worrying about impacting the rest of the system. These independent pieces are later composed together, creating a cohesive user experience.

Key Principles

Independence: Each microfrontend should be developed and deployed independently. This allows teams to work without needing to coordinate heavily with other teams, minimizing development friction.
Team Autonomy: Teams working on a specific microfrontend have full control over their piece of the application. They can choose the tools, libraries, and frameworks that best fit their needs without being bound by the decisions of other teams.
Modularity and Scalability: Microfrontends promote modularity, making it easier to scale both the application and the development team. By dividing a large application into smaller, manageable parts, teams can focus on their area of expertise, leading to better quality and faster iterations.

With all this freedom comes a common sense approach, it will all depend on the company, the technical leaders involved and what you want to achieve, as always, trade-offs will take center stage in decision making.

When Should You Use Microfrontends?

While microfrontends offer a lot of benefits, they are not a one-size-fits-all solution. Implementing microfrontends comes with its own set of complexities, including managing multiple repositories, ensuring consistency in the user experience, and coordinating deployments across different teams.

Microfrontends are generally best suited for large-scale applications where multiple teams are working concurrently on different features. They are particularly helpful for companies with well-defined business domains that can be easily separated into smaller, focused teams.

However, for smaller projects, the added complexity of managing multiple microfrontends may not be worth the benefits.

Conclusion

Microfrontends provide an effective way to break down large, complex frontend applications into manageable, modular components. They enable faster development, independent deployments, and better team autonomy, making them an attractive solution for organizations facing the challenges of scaling monolithic frontends.

However, it’s essential to weigh the pros and cons before jumping into a microfrontend architecture, for the right project they can be a game-changer, but for smaller applications they may introduce unnecessary complexity.

In the next article, we’ll dive deeper into the advantages and disadvantages of microfrontends to help you decide if they are the right fit for your project.

Why Sending a Resume Isn’t Enough Anymore

Mon, 04 Nov 2024 00:00:00 GMT

In today’s tech industry, sending a resume and waiting for a call simply isn’t enough. Companies have become more selective, prioritizing hires who bring the most relevant skills to compact, highly-optimized teams.

Although developers remain essential, the scope of their work has transformed. Some tasks that once required days can now be completed in a couple of hours with AI-enhanced workflows.

AI has undeniably boosted productivity, but it’s most effective for those who understand the field’s common challenges and can prompt tools precisely. In this competitive climate, standing out means demonstrating your value through real-world projects and proactive engagement.

Here’s how you can differentiate yourself from other tech candidates.

Creating content that showcases your journey and expertise can elevate your profile significantly. You don’t need to be an expert, everyone has valuable insights, whether it’s about technical challenges or the learning curve for newcomers.

Consider starting a blog, posting on LinkedIn or X, or experimenting with audio Podcasts or video formats like YouTube or TikTok.

Topics to explore: Seasoned developers can cover common challenges, unique solutions, or technical advice. Beginners can share learning strategies, struggles, or helpful resources they discover along the way.
Platform-specific tips: Each platform has its unique style, audience, and engagement methods. LinkedIn is ideal for professional discussions, a Podcast is great for long-form discussions, while TikTok and YouTube offer interactive formats that allow you to show skills in action. Experiment, gather feedback, and refine your approach.

Regular posting builds a foundation for your “online persona”, helping potential employers see your consistency, dedication, and growth.

Attend and Speak at Events

Events and meetups provide an excellent way to connect with the tech community. Most cities offer developer meetups, conferences, or tech-related events that foster networking and idea-sharing.

If you’re comfortable with public speaking, consider giving a talk to boost your visibility.

Benefits of attending events: Not only can you learn from industry leaders, but these gatherings also allow you to build connections and stay updated on industry trends.
Opportunities for public speaking: Sharing insights publicly displays your expertise and builds credibility within the community. Speaking at events can lead to new contacts, collaborations, or even job offers.

It’s important to be proactive, introduce yourself, and get involved in the community. Helping others and being an active participant can lead to rewarding, unexpected opportunities.

Build, Document, and Deploy Projects on GitHub

If you don’t like social media or you prefer a more hands-on approach, use GitHub to showcase your work. A strong GitHub profile speaks volumes about your skills, problem-solving approach, and commitment.

Beyond simply posting code, however, there are several ways to elevate your profile and demonstrate your knowledge of software development best practices:

Showcase Git knowledge: A well-maintained GitHub profile demonstrates your proficiency with version control, including creating pull requests (PRs) and organizing branches. Employers and peers can see your collaborative skills and attention to detail in your commit messages, branch structures, and well-constructed PRs.
Organized project structure: Your code organization and file structuring show your systematic approach to software development. A neatly arranged project is not only easier for others to navigate but also highlights your understanding of best practices in code organization.
Deploy projects: If possible, deploy some of your projects to show your understanding of CI/CD (Continuous Integration and Continuous Deployment) pipelines. Being able to push projects from development to production is a critical skill. It shows that you know the stages of software release and can take a project from concept to completion.
Readable and user-friendly README: Your README files don’t need to be complex, but they should make it simple for others to clone and run your projects. Clearly explain dependencies, setup instructions, and the purpose of the project. A well-written README reflects your communication skills and consideration for other developers, especially in open-source environments.

Experiment with the technologies you like, build a great profile, just ship or contribute to open source projects you find useful and help the community.

Commit to Consistency

Whichever path you choose, sharing content, speaking at events, or building projects, for all of them consistency is key. Success doesn’t happen overnight, but a steady commitment pays off over time.

Aim to create or contribute regularly, and don’t be discouraged by initial engagement levels. Often, the content you least expect will gain attention, so keep putting yourself out there without overthinking it.

Setting a goal for consistency: Commit to at least a year of consistent effort, whether weekly, biweekly, or monthly. This will give you a body of work to reflect on and learn from, plus you’ll start seeing feedback, engagement, and potential collaborations over time.
Small wins add up: As you build a presence, you’ll notice small wins along the way, comments on posts, new connections, or project inquiries. These small interactions accumulate, gradually building momentum and visibility in the community.

Why This Matters More Than Ever

All of this hard work has a purpose. A consistent and authentic online presence demonstrates your passion and dedication to learning and growth. Employers are actively looking for candidates who don’t just have the right skills but also show initiative. Over time, your projects, insights, and community involvement will open doors and make you a standout candidate.

Your portfolio, be it on GitHub, through blog posts, a Podcast, or a YouTube channel, becomes a visual CV, showcasing the skills and problem-solving abilities that a traditional resume cannot fully capture.

Final Thoughts

In today’s tech landscape, it’s all about showing what you can do rather than merely telling. Take that first step.

Commit to consistency and let your work speak for itself. In a year’s time, you’ll be amazed at the progress you’ve made and the connections you’ve built.

So get out there, do the work, and keep pushing forward. Not only will you grow as a professional, but you’ll also build a reputation and network that sets you up for a fulfilling career.

And who knows, the opportunities you once thought were out of reach may be closer than you think.

Effective Cross-Team Communication: Breaking Down Barriers

Thu, 24 Oct 2024 00:00:00 GMT

In my previous article The Importance of Communication in a Software Team, we discussed the importance of maintaining strong communication within your team. Exploring how clear, effective communication can prevent misunderstandings, and drive better results.

However, while team-level communication is essential, it’s only part of the picture. When multiple teams across a project or organization need to work together, the stakes are even higher. In this article, we’ll dive into cross-team communication, how different teams can collaborate, overcome barriers, and avoid the pitfalls that come from misaligned goals or poor communication practices.

Ensuring smooth collaboration between various teams is crucial, yet it’s often where communication breaks down, leading to siloed work, misalignment, and project delays. Cross-team collaboration presents unique challenges, but when done right, it can significantly boost overall productivity and project success.

The Importance of Cross-Team Communication

Cross-team collaboration involves more than just sharing updates or following protocols, it’s about understanding how your work impacts others. When teams operate in isolation without considering the effects of their decisions on other groups, misunderstandings, misalignment, and project delays are almost inevitable.

For instance, a backend team may introduce a change that inadvertently affects how the frontend team interacts with the system. If not properly communicated, this could cause integration failures, delays, or even customer dissatisfaction. Open communication channels across teams, with proactive updates and early involvement, can prevent these issues.

Moreover, effective communication isn’t just about the technical aspects, it also involves setting the right expectations, understanding shared goals, and developing a collaborative mindset. As projects scale and involve more stakeholders, communication becomes even more critical to ensuring that different teams remain aligned.

Understanding the Impact Between Teams

A common issue in many organizations is the lack of understanding of the ripple effect one team’s work can have on others. Development teams often focus solely on their own objectives, unaware of how their decisions may impact the larger system, such as shared services, dependencies, or product timelines.

To overcome this, teams need to adopt a mindset of shared responsibility. Everyone involved in a project, from developers to project managers, should be aware of how their work ties into the broader objectives of the company.

Ensure teams are informed about what other teams are working on and how it impacts them. When you realize some work you are doing may impact other teams, communicate it by email or offer a sync-up meeting between dependent teams, especially during critical project phases. These emails or syncs help teams align on priorities, timelines, and potential blockers.

Accessible and up-to-date documentation can help teams understand the broader scope of a project and how their tasks fit into it. It also serves as a reference point when questions or issues arise.

Ultimately, teams that take ownership of their role in the larger system contribute to smoother collaboration and faster resolution of conflicts.

The Importance of Precise Language and Terminology

When different teams collaborate, clear and consistent communication becomes a necessity. One of the biggest obstacles to cross-team collaboration is inconsistent terminology, which can easily lead to misunderstandings. For example, different teams might use different terms to refer to the same functionality, causing confusion and delays.

To combat this issue, it’s essential to establish a shared language early in the project. Some best practices include:

Glossaries and Style Guides: Developing a shared glossary of terms helps teams ensure they’re on the same page. This resource should be maintained centrally and updated regularly as new terminology emerges.
Naming Conventions: Set standard naming conventions for all shared components, APIs, or services. This creates consistency across teams and reduces the chances of errors during hand-offs.
Cross-Functional Input: Involve team members from different functions (development, design, product, etc.) in the creation of these terminologies to ensure that they make sense to everyone.

Using consistent language across teams prevents miscommunication, saves time, and ensures that all teams understand the project’s goals in the same way.

This is even more important in situations like company mergers or acquisitions, where depending on the side, you use different terminology. I worked in that scenario before, and being on the same page about the precise language and terminology from the start, was a big part of the success of that project.

Collaboration Beyond the Organization

Modern software often requires integrating third-party libraries or collaborating with external teams, these bring additional challenges, adding complexity to communication, and different project priorities.

To ensure smooth collaboration with external teams, organizations should assign a dedicated point of contact to manage external communication. This role ensures that any messages are consistent, clear, and timely, preventing miscommunication and duplication of effort.

Alignment of expectations is another key, involve external stakeholders early in the planning phase to ensure that expectations and project objectives are aligned from the start. Having clear deliverables and deadlines upfront can reduce potential conflicts later.

The goal of external collaboration should be to integrate external contributions seamlessly into internal workflows, minimizing the risk of misalignment and delays.

Overcoming Common Challenges

Cross-team communication can break down for various reasons: misaligned goals, lack of transparency, or simply poor coordination. Here are some strategies to address these challenges:

Avoiding Information Silos: Teams often operate in silos when they don’t have visibility into what others are doing. Leaders must break down these silos by participating in cross-functional meetings, using shared tools, and looking for transparency across projects. Collaborative tools such as Slack, Confluence, or Jira can help provide visibility into other teams’ work.
Managing Dependencies: Many cross-team issues arise from poorly managed dependencies. Teams should clearly define the dependencies they have on others and regularly track their progress. In complex projects, dependency matrices or Gantt charts can help visualize and manage these connections.
Addressing Conflict Head-On: Disagreements between teams are inevitable, but they can become productive if handled well. Foster a culture of open feedback, where teams feel comfortable raising concerns or questioning decisions without fear of blame. And most important, have one person that can make a decision in case there is no agreement between the priorities of different teams.

Having strong, experienced leaders in each area of a project is crucial for cross-team success. These leaders must effectively balance the dependencies between teams, manage their own team’s priorities, and align with broader company goals.

A key challenge lies in clearly defining responsibilities and decision-making authority across teams. Successful leaders not only navigate these complexities but also communicate clearly about what their teams can realistically achieve and where limitations lie.

By setting clear expectations, managing dependencies proactively, and ensuring alignment with company objectives, leaders can create a solid foundation for successful cross-team collaboration and project outcomes.

Conclusion

Effective communication between teams is just as vital as communication within teams, if not more so. Miscommunication or lack of alignment can lead to costly delays, failed projects, and organizational inefficiencies. By establishing a shared language, breaking down silos, and fostering a culture of collaboration, organizations can overcome these challenges and drive projects forward more efficiently.

The bottom line is that great communication fosters great collaboration, and great collaboration leads to better outcomes.

Communicate openly, deliver quality work and contribute to the overall success of the organization.

The Importance of Communication in a Software Team

Thu, 17 Oct 2024 00:00:00 GMT

In software development, good communication is just as crucial as technical skills. It doesn’t matter how skilled a developer is if they can’t convey their ideas, collaborate with the team, or understand the product’s needs. Many of us love coding and learning new technologies, and while these skills are essential, there comes a point in your career where you realize that one of the biggest challenges in the software industry, and in any activity where people must collaborate to achieve a common goal, is communication.

Poor communication can lead to misunderstandings, delays, and issues with software quality. In a constantly changing work environment where different teams must coordinate to meet ambitious goals, the ability to communicate clearly and directly is not only key to project success but also to your professional growth.

So, let’s explore some common situations you may encounter and how to approach them effectively so that projects run smoothly and you can stand out as a valuable team member.

Participate Actively in Plannings and Always Ask Questions

It’s essential to attend and actively participate in team planning meetings. These sessions are the key moment to align with others, understand priorities, share ideas, and most importantly, ask questions. Don’t underestimate the value of good planning, as it lays the groundwork for the next sprints or iterations. Participation allows you to anticipate potential issues and ensure expectations are clear from the start.

Often, developers, especially juniors, don’t feel comfortable asking questions during planning sessions. The fear of asking a “wrong” question or exposing gaps in knowledge can lead many to remain silent. However, this lack of participation is counterproductive. If you don’t ask questions when everyone can clarify them, you’re letting others make decisions you might not fully understand. Senior developers with more experience may take certain details for granted that you might not grasp. If later you’re assigned a task you didn’t fully understand, you’ll still have to ask the questions, but at a less convenient time when everyone is focused on their tasks, making it harder to find the right moment to resolve them.

Questions, even if they seem basic, are crucial to avoiding misunderstandings and long-term issues. Resolving doubts at the beginning of the process reduces surprises during development and may even uncover gaps in task definitions. Moreover, if you’re new or less experienced, a seasoned Tech Lead (TL) won’t mind explaining what you need to know. Raising your hand and asking for help not only unblocks your work but also shows your willingness to learn and improve.

Although planning meetings can be long and tiring, they allow us to work more independently later on, minimizing interruptions and reducing meetings to daily stand-ups, as long as the agile approach is well-implemented (though that’s another topic).

Saying NO: A Superpower

Knowing how to say “no” when something isn’t feasible or isn’t the best recommendation is a crucial skill in software development. It’s not just about rejecting an idea, but backing up that “no” with solid reasons and, most importantly, offering viable alternatives. Saying “no” with arguments shows your ability to analyze problems and find solutions, strengthening your credibility as a developer. Additionally, setting boundaries when necessary leads to more efficient work and higher quality products.

It’s essential that when you say “no,” you can defend your stance. It’s not enough to say something can’t be done or just oppose for the sake of it (that’s a red flag). The ideal approach is to explain why it’s not possible or why it’s not the best option, and then offer alternatives that can solve the problem in another way. This skill not only makes you more valuable to the team but also improves decision-making by providing useful perspectives.

It’s also crucial to be aware of your own knowledge limits and maintain an open attitude toward learning. There’s no point in questioning every decision made, but sometimes, due to a TL’s responsibilities like meetings, architectural decisions, or changing priorities, some details may slip through the cracks, no one is perfect. This is where developers who are more hands-on with the code play an important role, identifying those small gaps that might have been overlooked.

If the TL or product team decides to take a different approach, ideally, they’ll explain the external factors that influenced that decision. Understanding these “whys” is a valuable learning opportunity, helping you improve your decision-making in the future and better understand how to balance technical and product needs in your project.

Leave Your Opinions and Decisions in Writing

When you have a strong opinion about a critical feature or a change you consider potentially problematic, it’s essential to record your perspective in writing, whether in a comment on a ticket or a related email. This ensures your voice is heard and creates a record that you flagged potential risks.

Leaving your opinions in writing helps clarify who’s responsible for what. One of the most common issues in teams is the lack of ownership, where responsibility for certain decisions shifts based on tickets or current priorities. By documenting your concerns or suggestions, you make it easier to identify who has the knowledge and authority to decide the course of action.

At the end of the day, someone must take responsibility for those decisions. Balancing technical knowledge and product needs is key to finding effective solutions. Documenting these opinions not only protects your work and ensures transparency, but it also helps the team avoid dispersed responsibilities, making technical decisions more coherent and aligned with product goals.

Communication with QA: Collaboration, Not Confrontation

It’s common for tensions to arise between developers and QA, which is understandable given the differences in their roles. Time and again, the biggest problem isn’t finding bugs, but the lack of clear communication between both teams.

Sometimes QA reports problems they consider obvious, but that are not clearly specified in the user story or the task’s acceptance criteria. This can lead to misunderstandings if not well-communicated from the start. That’s why your role as a developer, if you spot ambiguities in a ticket, is to communicate this to the QA team, the product manager (PM), and/or product owner (PO). This way, we can anticipate potential issues in tests and ensure that the QA team is aware of what might arise, thus adjusting everyone’s expectations.

Some of these problems can be solved by actively participating in planning sessions, as mentioned earlier, but there are cases where certain obstacles only appear once we start looking at the code.

Communicating with Non-Technical Stakeholders: The Art of Simplifying

One of the biggest challenges when interacting with non-technical stakeholders is translating complex concepts without resorting to technical jargon. Learning how to simplify these concepts and explain them clearly using practical examples is essential for stakeholders to make informed decisions. In general, everyone wants to solve problems in the best way possible and get good user feedback, but often the difference lies in understanding what’s technically possible or efficient.

A very common mistake is that product owners present solutions instead of problems. Instead of explaining what they need to achieve, they often come with a ready-made solution, which might work for simple issues. However, in most cases, the solutions they propose are just one option among the few alternatives they know, without considering that there could be many better ways to approach the problem. As a developer, it’s your responsibility to ask questions that help you understand the real problem and then offer alternatives based on your technical knowledge.

If you can suggest a better solution to a problem, you’re not only demonstrating your technical ability but also showing initiative and a genuine interest in the product. This builds trust with the leadership team, as it shows you’re thinking about the product and features as a whole, rather than just as a series of isolated tasks.

This kind of approach can open many opportunities for you in the future, as it shows you can strategically contribute to the product’s success.

Final Thoughts

Being a valuable member of a software team isn’t just about writing code, but about actively contributing to creating a solid product aligned with the business’s needs.

When we communicate effectively in the various opportunities we have to ask questions and define key aspects like workflows or technical decisions, we’re not only improving communication within the team but also enriching the development experience as a whole. By interacting and learning from the different people involved in the process (not just in the software side), we’re building closer and more trusting relationships with our colleagues.

Good communication also allows us to be more productive and work more independently, as everyone is clear about their responsibilities and the decisions made. This not only improves the work environment but also makes the process of working in the software industry more enjoyable.

Finally, with an attitude focused on improving communication and doing things right, that extra effort may not only boost your performance but even lead to a promotion or new opportunities within the company.

Working Remotely Since 2017: My Experience 🌎

Fri, 04 Oct 2024 00:00:00 GMT

With recent news about many companies wanting employees to return to the office, and in some cases eliminating remote work entirely, I started reflecting on the topic.

In this article, I’ll share my experience, my thoughts on these changes, some relevant data, and how I see the future.

My Journey Towards Remote Work

I’ve been working remotely since 2017, yes, before the pandemic and the boom of this work model. Before that, I worked in hybrid formats, and as I spent certain days at home, I began wondering: why not work from here all the time?

In 2017, I switched companies, and they offered me the chance to work completely remotely. Since I was integrated as staff augmentation into a team entirely made up of people from the U.S., and I participated mainly in online meetings, going to the office didn’t make sense.

Since then, I haven’t looked back. With each job change, I’ve made remote work a non-negotiable priority, and it remains one of my top requirements when evaluating new opportunities.

Face-to-Face vs. Remote

Meeting face-to-face is irreplaceable, especially at the start of a project. However, in today’s software world, where teams are spread across multiple countries, working in an office often doesn’t make much sense. In large companies, teams can consist of people from different nationalities, further reducing the need for in-person interaction.

That said, I do enjoy visiting the office or a coworking space occasionally if colleagues from the same company are in town. I’ve also had great experiences traveling to U.S. offices to meet with teams for one or two weeks. These trips not only allow us to work together but also to build stronger relationships outside of work. This connection is especially important at the beginning of a project or shortly after it starts, as it often strengthens communication, trust, and team cohesion.

However, these trips aren’t always feasible. But even when I’ve worked exclusively with teams based in the U.S., we’ve successfully completed projects without meeting in person even once. The only downside? My list of places to visit keeps growing along with the names of people I’d love to meet in person after years of collaboration.

The Flexibility of Remote Work

One of the biggest advantages of remote work is the flexibility to work from anywhere in the world. I’ve been fortunate to live and work in countries like Spain, Croatia, the United States, and Portugal for periods of one to three months as a digital nomad.

I often combine these trips with vacations, expanding the list of places I’ve been able to explore, although that’s a topic for another article.

Keys to Success in Remote Work

To succeed in a remote work environment, some practices are essential:

Time management: You need to be disciplined with how you structure your day.
Clear communication: In all aspects of work, clear and constant communication is crucial.
Transparency: Try to be as transparent as possible with the work you’re doing, and if you’re blocked, communicate it in a timely manner.
Dedicated workspace: Having a home office or a space where you can work without distractions is essential.
Reliable internet: This is a no-brainer, but without a solid connection, remote work simply isn’t possible.

The Benefits of Remote Work

There are several clear benefits of working remotely:

No commuting: In big cities, this can save several hours every day.
More family time: You can always take a few minutes to recharge and clear your mind by chatting with your loved ones.
Healthier eating: Being at home makes it easier to prepare nutritious homemade meals, which is an underrated long-term benefit.
Time savings: The time saved commuting to and from the office can be used for other activities, like going to the gym, taking a walk, or meeting friends for coffee or a beer, it’s like extending your day by a few extra hours.

What the Data Says

Now, let’s look at some data from Forbes about remote work in 2024, which clarifies where this trend is headed.

It’s a growing trend: as of 2024, 1 in 5 workers operates remotely, marking a significant shift in work dynamics. This change challenges the traditional office model and signals a move toward more flexible and innovative ways of working.

It’s expected that by 2025, 32.6 million Americans (or 22% of the workforce) will work remotely. This continued growth reflects the importance of remote work in professional life.

Employee preferences are clear: a staggering 98% of workers prefer to work remotely, or at least part-time. Flexibility, autonomy, and a better work-life balance are now top priorities for employees. Companies that can meet these needs are more likely to attract and retain top talent.

Some companies are already fully remote. 16% of companies now operate without a physical office, proving that with the right infrastructure, a fully remote model can be feasible and successful.

Some industries have embraced remote work more effectively than others. In 2024, IT and information technology lead the way, followed by accounting and marketing. These sectors have leveraged digital tools to maintain productivity in a remote environment.

The most common jobs posted for remote work include:

Software engineers
Accountants
Executive assistants
Customer service representatives

These roles demonstrate that both technical and administrative tasks can be efficiently performed from home.

Who’s Leading the Way? The largest group of remote workers falls within the 24 to 35 age range, with 39% working remotely full-time and 25% part-time. This younger workforce is attracted to the flexibility remote work offers, making it essential for companies to implement flexible work policies if they want to attract and retain these employees.

Conclusion

The future of software development (and many other fields) clearly lies in remote work. As technology advances, new and better ways of collaborating and maintaining productivity will continue to emerge.

While there are situations where in-person work can be beneficial, such as when continuous collaboration is needed or when solving extremely complex problems, in most cases, it’s not only unnecessary but also less effective.

Remote work makes people happier, and as a result, more productive, who would have thought, right?

🎧 From Articles to Podcast: Powered by AI! 🚀

Wed, 25 Sep 2024 00:00:00 GMT

I’m constantly experimenting with new ways to enhance how I share content. This weekend, I decided to play around with Google’s NotebookLM, and the results were pretty good.

It led me to launch “Code Quests”, an AI-generated podcast based on my DEV.to articles, now available on Spotify! 🎙️

But how did this come about, and why use AI to turn written articles into podcast episodes? Let’s dive in.

Why a Podcast?

Writing technical articles is a great way to share knowledge, but audio allows people to consume content on the go, whether they’re commuting, exercising, or simply prefer listening over reading.

However, as much as I love the idea of podcasting, recording and editing episodes manually can be time-consuming. That’s where AI came in. I thought, “What if I could use AI to automate this process?” And that’s when I stumbled upon Google’s NotebookLM.

What is Google’s NotebookLM?

NotebookLM acts as a virtual assistant designed to analyze and summarize information. By leveraging the Gemini 1.5 Pro model, it can digest large volumes of content and then generate conversational insights.

In my case, I simply input my DEV.to articles, and it generates a conversation between two AI voices. These voices highlight the key points of my written content and package them into a podcast-friendly format. 🤖💬

For example, if one part of my article covers a complex concept, the AI voices can engage in a back-and-forth conversation, breaking down the idea and making it easier to digest for listeners. This approach mimics real-life discussions, making the podcast feel less like a monologue and more like an insightful conversation.

The process was surprisingly smooth, and I was impressed with how natural the conversation sounded. It didn’t feel like a robotic repetition of my text but more like two intelligent voices having a thoughtful discussion about the article.

That said, I’m treating this as a learning process. Every new episode teaches me something about how AI interprets my articles, and I’m constantly experimenting to improve the results.

Comparing the Written and Audio Experience

A big part of this experiment is seeing how the written and audio experiences differ. Reading an article allows for deep, focused engagement with the content, while listening offers convenience and accessibility. What I’ve noticed is that the AI podcast episodes provide a condensed version of the articles, which is great for getting the key takeaways quickly.

For those who prefer a more detailed exploration, I still recommend reading the original articles. But if you’re on the go or want a quick summary, the AI-generated podcast offers a handy alternative.

This experiment is about more than just showcasing AI technology, it’s about finding out what works best for my audience. I encourage everyone to give the podcast a listen and share feedback. Did the AI capture the essence of the article? Was the conversation engaging? What could be improved?

AI in Content Creation: A Growing Trend

The use of AI in content creation is a growing trend, it is rapidly changing how we produce and consume content. I see tools like NotebookLM as part of a larger movement that’s making content creation more accessible, especially for solo creators or small teams who might not have the resources for full production processes.

As I continue this journey with “Code Quests”, I’m excited to see how AI will further evolve and impact the way we share knowledge.

Conclusion

While this is still an experiment, it’s clear that AI can help creators repurpose their content efficiently and reach broader audiences. The key is to embrace the technology while continuing to refine and improve the output.

So, whether you’re reading my articles on DEV.to or tuning into “Code Quests” on Spotify, I hope you find value in this exploration.

Oh, and here’s where it gets a little meta… I’m pretty curious to see what the AI will generate for this article about the AI! 😅 It’s like AI-ception!

Once the podcast episode for this goes live, I’ll drop the link in the comments so you can listen to the AI discussing itself. Should be interesting, right? Stay tuned! 🎧

From Playing on PC to Building Software: My Journey into Programming

Mon, 16 Sep 2024 00:00:00 GMT

My First Encounter with a Computer

It all started many years ago when I was just a kid, and my dad brought home a 486 PC. Back then, every time he went to work, he’d let my brother and me use it, and that’s how it all began.

I quickly learned how to navigate through the system directories using a few basic commands, and while I only remember using the classic MS-DOS text editor, that wasn’t the point. What really blew my mind were the video games, especially one in particular: “Prehistorik”. I spent countless hours battling dinosaurs and solving the game’s challenges. That’s when my curiosity and love for computers were born.

A New World

Every few years, we’d upgrade our computer, and with each new machine came more innovations and possibilities: 5 1/4 and 3 1/2 inch floppy disks, the mouse, better monitors, more disk space, more RAM, and so on.

And with that came new games. I particularly remember Prince of Persia, Maniac Mansion, Monkey Island (the GOAT), and Wolfenstein 3D. These experiences weren’t just entertaining, they also taught me new things about how to interact with technology, often without me even realizing it.

Time passed between one game and another, and soon it was time to decide what to study. Although I had many interests, so many years in front of a screen left their mark on my subconscious. And off I went… a Bachelor’s Degree in Computer Science.

Time to Really Study

The Computer Science degree wasn’t what I expected. It was a world filled with complex mathematics, algorithms, new concepts like recursion and pointers, computer architectures, system design, statistics, compilers, and many more topics.

I learned to program in languages like Assembly, Pascal, Lisp, Delphi, and Java. These first steps were tough, but they were fundamental for what was to come. Little by little, I improved and began to understand how software worked.

By this time, something new had emerged called “the Internet”. Maybe it could be used for more than just sending nudges on MSN Messenger.

First Job

At some point, the opportunity for my first job came along. A friend offered me the chance to work on HTML and CSS layouts for WordPress sites, all compatible with Internet Explorer 6 (yes, the horror), but it was freelance and remote. What started as small projects gradually grew. I began playing around with PHP, a bit of JavaScript, and learning the quirks of working on the web.

Not long after, another friend from university told me about an opening at the company he worked for. I applied, went through several interviews, health exams, aptitude tests, and who knows what else. Finally, I got the news: “You start next Monday”.

This was my first formal office job. Surrounded by people with much more experience than I had, I learned 90% of what I would apply in the next ten years. Beyond the technical knowledge, the most important thing from this job was that all my dev colleagues became great friends to this day, and it was one of the best teams I’ve ever been a part of.

I had four courses left to graduate, but I decided to focus on work, at least for a year, then I’d go back… spoiler alert: I never finished my degree.

Absorbing Everything

Working at a startup often means rolling up your sleeves and doing everything. We coded, did deployments, configured servers, backed up data, provided support, monitored different products, estimated new features, and more.

It was a dynamic environment, where I encountered technologies like MS SQL Server, Entity Framework, VB.net, and C#. It was a time of intensive learning in databases, design patterns, testing, web, and desktop applications, and many other areas of software development.

It was also my first experience with agile methodologies and version control technologies like TFS and Tortoise SVN. It was a constantly evolving world, and there was always something new to learn every day.

New challenges

Over time, and with some job changes, my path started leaning more toward backend development with .Net and mentoring junior developers. In one of these projects, I got a glimpse of a frontend framework they were using: AngularJs.

Suddenly, a new challenge came up: a temporary project that required full-stack skills, particularly C# and Angular. They urgently needed 2 people for the positions, and they offered me a few months of ramp-up on the frontend. I accepted and recommended a colleague specializing in frontend who I was working with. They hired her. We shared knowledge, I learned a bit more about Angular, and I explained what I could about the backend.

Three years later, we had turned that 3-month temporary project into a long-term project for the consulting company we worked for, hired over 40+ people for that client, I had my first trip to the US, and made new friends who I’m still in touch with today.

Pandemic

Then came layoffs due to mergers and the pandemic, a new reality. COVID-19 hit.

I decided it was time to explore new horizons and focus on personal projects with Node.js and Python. However, with the rise of cloud platforms and microservices everywhere, I found myself moving away from backend development and decided to return to my roots: frontend.

The latest version of Angular at the time was pretty cool, but there was a lot of hype around React and Vue, so I decided to build the same small project with all three technologies. The one I enjoyed the most was React.

I dove into that new world, discovered hooks, and soon landed my first formal job as a frontend developer with React.

Since then, I’ve stayed in frontend-oriented roles, with occasional adventures into backend development with Node.js or Go.

What I’ve learned along the way

What started as playful curiosity turned into a career that has opened many doors for me: I’ve had the opportunity to travel, meet amazing people, stay up to date with the latest technologies, and, above all, learn something new every day.

It’s not always easy, I still struggle with imposter syndrome, but that’s part of the process. Over the years, I’ve worked with complex architectures, microservices, microfrontends, UI component libraries, various AWS services, CI/CD pipelines, and I’ve seen a lot of things, from the chaos of a small startup to the structure of large corporations. And I’m sure the best is yet to come.

The world of development never stops evolving, there’s always a new approach to learn and emerging technologies. I’m looking at you, AI.

And here I am, after that first game of Prehistorik… centering a div.

Using LLMs in Software Development: A Simple Tip for Beginners

Mon, 09 Sep 2024 00:00:00 GMT

If you’re new to using large language models (LLMs) like ChatGPT in software development, you might find yourself following a familiar pattern:

Writing a prompt
Copying and pasting the generated code
Not fully understanding everything, but as long as it works, you run with it
Telling yourself, “If it works, don’t touch it.”

While this approach might seem efficient in the short term, it’s not sustainable if you want to grow as a developer.

A simple tip to help you get the most out of using LLMs for coding: 💡 Focus on understanding what you’re doing, not just getting the code to work.

Here’s how you can level up your LLM usage:

1. Ask for Explanations of the Code After generating code from an LLM, don’t just settle for the output. Write a new prompt asking the model for a step-by-step explanation of what each part of the code is doing. This will help you understand the logic behind it.

2. Clarify What You Don’t Understand If there are parts of the generated code that don’t make sense, ask about them specifically. LLMs can break down complex code into more digestible explanations if you request it. Understanding these details is crucial for your growth as a developer.

3. Test Your Understanding by Rephrasing After getting an explanation, test your understanding by writing a new prompt that explains the code in your own words. This forces you to engage more deeply with the problem. If the model’s response matches your explanation, you’re on the right track. If not, you’ll know exactly where your gaps are.

4. Iterate Until You Can Explain It Continue asking for clarifications and refining your explanations until you can confidently describe every part of the code as if you had written it yourself. This process ensures you’re not just copying and pasting but truly grasping the underlying concepts.

5. Reach Out to More Experienced Developers When you’re still stuck or unsure, don’t hesitate to ask a more experienced developer on your team. A short conversation or call can clear up confusion much faster than struggling on your own and can save you hours of confusion.

By taking the time to understand the code you’re working with, you’ll avoid common pitfalls such as:

Tedious code reviews: Submitting code you don’t fully understand can lead to painful, lengthy feedback sessions.
Awkward moments in pair programming: It’s hard to collaborate effectively if you can’t explain what your code is doing.
Unnecessary discussions: “I copied and pasted it from ChatGPT” isn’t an acceptable response when someone questions your approach.

LLMs can be an incredible tool for accelerating learning, whether you’re adapting to new languages, understanding libraries, or designing software architecture. But to use them effectively, you need to learn and internalize the basics. This will not only help you avoid embarrassing moments but also ensure that you’re growing as a professional.

Remember, it’s not just about making things work, it’s about understanding what you’re doing. This will benefit not just you, but also your team and the quality of your work. When used correctly, LLMs become an invaluable tool for learning and problem-solving.

You can thank me later 😉

What I Learned from Mentoring: A Mentor's Perspective

Mon, 02 Sep 2024 00:00:00 GMT

Being able to share knowledge and experiences with someone who is just starting out in the world of software and watching them evolve must be one of the most rewarding things I’ve ever done.

But what many don’t realize is that mentoring is as much a learning experience for the mentor as it is for the mentee. Here are some key insights from the mentor’s side that I’ve learned through my own mentoring journey:

Conquering Imposter Syndrome 🛡️ Imposter syndrome is something almost everyone in the tech industry struggles with at some point. You might often feel like you don’t know enough or that you don’t belong in the position you’re in. However, when you start mentoring, you quickly realize that you know more than you give yourself credit for. As you guide someone through the basics and see them progress, it reinforces your own expertise and helps to diminish those lingering doubts about your capabilities.
Discovering Knowledge Gaps 🔍 Mentoring forces you to reflect on your own understanding of different topics. You may notice that there are things you thought you knew but don’t fully understand, or you need to improve some gaps in your foundational knowledge. Exploring and filling those gaps helps you advance professionally. It’s a win-win situation where both you and your mentee are constantly learning and evolving.
Improving Communication Skills 🗣️ Technical skills are only part of the equation, communication skills are equally crucial. It’s one thing to know how to do something in your head, but being able to clearly explain certain concepts and the reasoning behind them to someone else is a whole different challenge. Mentoring helps you develop the ability to articulate complex concepts in a way that’s understandable to others, which is a skill that’s beneficial not just in mentoring but in any collaborative environment. You learn to be patient, to listen actively, and to adapt your explanations based on the audience’s level of understanding. The result: your communication soft skills improve significantly.
The Contagious Enthusiasm 🌟 If you’re lucky enough to mentor someone who is eager to learn, that enthusiasm is contagious and pushes you to keep learning and improving yourself. It’s a reminder of why you choose a software career in the first place and helps rekindle that initial passion.

Mentoring is more than just teaching someone how to code or navigate the industry, it’s about contributing to the growth of the next generation of professionals.

In summary, if you ever have a similar opportunity, don’t hesitate to take it. It’s a two-way street of learning and growth!

Have you ever mentored someone or been mentored? What was your biggest takeaway? Share your stories below! 📖💬

🌐 Frontend Development with AI: Hype vs. Reality

Thu, 29 Aug 2024 00:00:00 GMT

Last weekend, I was working on an institutional website for a personal project and decided to use the new version of Vercel’s v0. Even though I had early access to the first version and really liked it, I saw a lot of hype online about the latest improvements.

I used Next.js, TypeScript, Tailwind, and Shadcn. After a very simple setup, I asked v0 to generate a landing page with specific features, including the use of the mentioned technologies.

After a couple of iterations, I had 80% of the landing page ready:

Light and dark mode
Responsive design
A color theme configurable in a single file
Different sections for the content
Photo carousel
Contact form
Certain animations in specific places

How long did it take? Approximately an hour and a half 🤯

Yes, I have experience with React and Next.js, and I didn’t just copy and paste, I iterated on the AI’s results to adjust them to what I wanted, added some code manually, and made small refactors here and there. But still, I was surprised by how quickly I progressed and how neat everything turned out.

Now, a key point: while this experience is fantastic for an MVP or a startup development, frontend development in an already established company is a completely different story (and, in my experience, the bigger the company, the more complicated it gets).

Some similarities I’ve seen in frontend projects at large companies using React:

Older versions of React, in some cases with a significant percentage of class components.
Proprietary component libraries that, although useful in some cases, complicate others and slow down new features depending on the abstractions used.
Generally, these component libraries are developed and maintained by another team, so any change we need might take weeks, even months, depending on priorities.
Several teams modifying the same codebase, or microfrontend architectures that, while solving many problems, add considerable complexity and other types of challenges, each with its trade-offs.
Real technical debt, with massive components full of hard to follow logic, lots of repeated code, few custom hooks to reuse logic, to name just a few smells. All this makes it more complicated to fix bugs, maintain, and improve the product.
Little emphasis on testing, which complicates future refactoring, to mention just one thing, but it’s much more severe.
Not to mention app state management, with a variety of approaches and a large number of different libraries, depending on the company a whole world in this aspect.

In summary: although the advances with AI are undeniable, we are far from replacing frontend work entirely. The complexity of maintaining and evolving a system in production while meeting deadlines and addressing priorities cannot be underestimated. What is true is that AI significantly improves developer performance in many aspects (as long as you know what you’re doing and are familiar with the technologies being used).

Also, it’s important not to forget that implementing new technologies in large projects comes with its own challenges, and that’s something that AI, no matter how advanced, still cannot fully solve.

The big picture is that while the hype is justified in certain contexts, the daily reality in established companies is much more complicated than is often portrayed.

As always, the keyword is “it depends”.