Deisbel (Sr. Software Developer)

I don’t want to be a front-end developer only. I don’t want to be a Backend developer only. I don’t want to be a DevOps or Cloud developer only. I don’t want to be a Data engineer only. I've been, I am, and I'll be a Full-Stack developer, working in parallel or switching among tech stacks continuously, and I love it. This is my strength because I can solve practically any problem. I will post more content about my daily experience connecting those ends. If you are a developer on one of those sides only and want to learn about the others, then follow me, ask me questions, and let’s do it together.

@RaulJuncoV I hope every team working with AI agents watch this video!

2026 will be the year we see the first major AI agent security breach. And it won’t be caused by a hacker. It’ll come from a well-meaning engineering team. Right now AI agents can: • Read private repositories • Execute shell commands • Call internal APIs • Trigger CI pipelines • Access secrets That’s a lot of power. And most teams are adding agents without thinking about infrastructure and boundaries. If agents operate in your system, they should run inside environments with: • clear isolation • scoped access • audit logs • identity controls This is my take on a simple architecture that helps make that possible. And why I think this will become important as agents move from experiments to real production systems. Thanks to the team at Coder for supporting the video. Here is the link to check out what they’re building. 👉 fandf.co/4rycsYg

@svpino Thank You for sharing. I was just checking the new things from Google AI. A Helpful feature for sure.

Google is cooking on all cylinders! It's just not Gemini 3—which is awesome! But they are putting a lot of work into the ADK (Agent Development Kit). Here is just one example of how they are focusing on development experience: You build your agent. You 100% focus on your code and make it work locally. When you are done, you can use Google's agent-starter-pack to add everything you need to make it production-ready. One command, and you'll get infrastructure, CI/CD, observability, and security: $ uvx agent-starter-pack enhance Pretty magic stuff!

@RaulJuncoV This is why my favorite method is Money-Driven development. Think first about the cost, then act!

Meeting-Driven Development is real. And it’s killing your progress. We’ve normalized a workflow where talking about work has replaced actually doing the work. - 30 minutes of standup - 1 hour of grooming - 1 hour of retro - 1 hour of “alignment” - 45 minutes for “sync” And somehow... You’re shocked no one’s shipping code. You’ve built a workflow optimized for talking, not building. Every meeting you add steals from focus. And context switching is a tax. A brutal one. Here’s the irony: Most meetings exist to fix problems caused by...too many meetings. - You're aligning because no one documents. - You're syncing because no one owns. - You're debating because the goal isn't clear. - You're blocked because the system is too complex. 👉 The best teams I’ve worked with have brutal discipline about this. 1. They optimize for output, not optics. 2. They treat focus like a scarce resource. 3. They default to trust, not consensus. Because they know: Every hour you spend in a meeting is an hour you're not building. What’s one meeting that should’ve been an email... but wasn’t?

Enthusiastic Developers: Do you want the secret for saving yourself 800 bugs, 1800 headaches, 2800 hours of work, sleepless nights, and probably saving your job? There you go: - Don't touch what is already working! Unless absolutely necessary, don't change the code working in Production. Localhost is an environment that often has nothing to do with Production, especially in systems that allow customizations or adding plugins on demand. When changes must be made, they should be made, but avoid the temptation to make them out of enthusiasm.

My company's Project Manager decided to dedicate a full sprint to reviewing the error logs for all projects. The idea seemed excessive to me: a full two-week sprint looked like a waste of time. Was the Project Manager wrong, or was I wrong? But first, some relevant conclusions: It's incredible how good we are at logging errors, but terrible at checking them. Checking logs is one of the most hated tasks because if the software works, who cares about all those thousands of lines of warnings and "errors"? And you might think, 'You have terrible developers.' Well, no, we're outstanding (modesty aside). Bugs that cause your software to crash are easy to detect, but silent bugs are tough: they don't bother you, but they shouldn't be there either. So, it is time to answer the main question, but changing it a little bit to save my self-esteem: Who was more wrong? Well, me!, because we didn't need a whole Sprint, but possibly more than one. My three tips for you, Product Owner or Project Manager: 1- Every 6 months, allocate a significant portion of your resources to cleaning up the error logs. 2- If the errors you see aren't critical, then don't log them: change the type to "Info" or delete that line from the log. 3- Refrain from mixing other tasks with this one; otherwise, we, the developers, will dedicate our time to those tasks and avoid bug purging as much as possible. I must admit it, in the end, it was an exciting Sprint.

@RaulJuncoV Code Review is a tough task because we don't have enough motivation to do it at any time. If this AI does not need motivation, it will be better than us. 😁

"The purpose of code review is building, learning, and teaching." Not blaming. But let’s be honest, time gets in the way. You’ve got features to ship, bugs to fix, meetings to sit through... and suddenly that PR review becomes a checkbox. It’s not that we don’t care. It’s that thoughtful reviews take time. • Time to understand the context. • Time to catch subtle issues. • Time to give feedback that actually helps That’s where @coderabbitai comes in. It shows up in your PRs with helpful suggestions, not just “what’s wrong,” but why it might matter. It handles the small stuff, the things that slow you down but still matter: • Formatting issues and style nits • Unused variables or unreachable code • Risky patterns (unhandled nulls or hardcoded secrets) • Missed test coverage • Subtle bugs that hide in plain sight So you can focus on the big stuff: 1. Architecture decisions 2. Business logic 3. Mentorship 4. Asking the right “what if” questions It keeps the review process moving without turning it into a blame game. Because good feedback builds better teams.

@Franc0Fernand0 I could not agree more with you, Fernando. If you don't enjoy your time at work, you'd better leave it. If you don't make any friends there, maybe you are the problem.

Work takes up a significant part of your time. If you don't make any friends and have some fun, it's better to find something else. Honestly, I wouldn't want to work at a place like this.

A coworker just got this paradoxical error message: The view 'NotFound' was not found! 😂🤣

@svpino @snyksec Could you imagine it if this robot were in the middle of a surgical procedure? 😂

How long until a vibe-coded robot hurts someone? On May 28th, @snyksec is hosting a live virtual event focused on securing apps in an AI-native world. This session will help you understand what happens when you start using AI to build software and what your security strategy should be. Expect: • A talk on how AI is shifting software architecture • A look at emerging security blind spots • Practical ways to keep your applications secure This session is FREE and open to everyone. Link below 👇

@svpino I though I was alone on this!

You should still learn to code. And you should start as early as possible.

It's a good time to remember great leaders and their feelings toward immigrants. This is Ronald Reagan's last speech as president. youtu.be/2R8QxCD6ir8?si… PD: Sorry for sharing a nontechnical content. It is a one-time exception.

@svpino PD: All characters in this story are fictional. Any resemblance to actual events is purely coincidental.

I never taught my kid how to read. Why waste time? I instead gave him an unlimited subscription to audiobooks. He doesn't write either. There's no point in learning something that he can do with a Grammarly subscription. Even his iPhone writes everything for him! Art, History, and Math are all useless dinosaur concepts from another time. They were useful before, but you don't need them now that we have AI, Wikipedia, and calculators. I laugh every time I see people learning other languages. Do you understand you have a computer in your pocket that can speak every language? And of course, I’d never let my kid learn to code. I'd never bother with such a useless skill in the era of AI. Welcome to the all-inclusive resort of your future! Don't worry about a thing. We take all forms of payment and take care of everything! Unlimited fun in the lobby, and food is served at 6.

@RaulJuncoV A short, simple, and effective summary of what makes the difference in projects. I know developers writing beautiful lines of codes but failing at some of the basic points you are mentioning.

Most software failures aren’t from bad code. They’re from bad decisions. Common engineering mistakes: 1. Over-engineering – Complexity kills velocity. Build what you need, not what you imagine. 2. Ignoring the basics – Logs, monitoring, and error handling aren’t optional. 3. Skipping tests – If you don’t test it, your users will. 4. Tightly coupling everything – Future refactors shouldn’t feel like surgery. 5. Chasing trends – The right tool > the latest tool. Good engineers write code. Great engineers make good decisions.

I even left a company because I didn't want that micro-sh... for the rest of my life. They had one of the most inefficient projects I've worked on. It was super-split into micro-services. The time lost daily due to dependency bugs and coordination was incredibly high. Whenever a tiny piece had an error, finding which of the 40 dependencies it occurred in took hours. That company paid millions of dollars upfront for that super-design, which cost millions more to maintain.

Microservices won’t fix bad design—they’ll amplify it. Splitting a monolith into microservices doesn’t magically solve scaling issues. It introduces network latency, data consistency challenges, and operational complexity. Before going micro, ask: • Does each service have a clear, single responsibility? • How will services communicate—sync or async? • Can failures be isolated without breaking the whole system? • Have we properly defined bounded contexts? • Who will be the owner of that new service? • Is the team structured for microservices, or will this cause silos and slowdowns? • Can you afford it? Microservices work best when your architecture demands it, not when hype drives it. Choose wisely.

@RaulJuncoV Do you really know an architect who does not add complexity to a solution? 🤣😂🤥

Over-engineering slows you down. Under-engineering breaks at scale. Then what's the sweet spot? Ask yourself: Is this decision reversible? Does this complexity solve a real problem today? Can this evolve without a rewrite? Are we coupling services unnecessarily? What happens when traffic spikes 10x? Instead of trying to predict the future, you should design for change. Simple, don't scale. Complexity delays. Adaptability secures survival.

@svpino Death field set to false is different from getting benefits and checks from the SS. Making a simple People INNER JOIN payments Will respond to the Elon doubts but he prefers to spread rumors and fraud theories.

I've worked with databases for the past twenty-plus years, and this table posted by Elon gives me no information to assess whether there's fraud or not. This is just an aggregation. I don't know how that data was collected, processed, and grouped. There might be fraud or not. I don't know, so all I can do is speculate. Two things: First, if you look at this as some sort of "proof" there's fraud, you don't know what you are talking about. Second, I like to use Occam's Razor when I don't have enough information. What do you think is more likely? A. This query is missing something, so this table is not telling the correct story or B. There is indeed massive fraud, and 180-year-old people have been collecting social security, and nobody has ever found out until today. I guess you'll have to make up your own mind about what you want to believe.

@svpino The question is: When a person dies, who and how is the SS Administration notified to mark him as dead? Another theory is that the SS Administration uses the same 'year measurement' used by Elon when he makes false promises about delivering a product in X years: 1 to 10.

I’ve recently received many direct messages asking for help with a meme coin or crypto project. Is it only me? It is annoying. I thought the crypto hype had gone.