DEV Community: Carla Urrea Stabile

The Future of Coding is Communication, Not Just Code

Carla Urrea Stabile — Thu, 26 Mar 2026 14:31:00 +0000

We recently had a great conversation on the Making Software podcast with Bobby Tierney. Bobby is a Principal Architect at Okta and Auth0 who focuses on agentic security, AI governance, and the Model Context Protocol (MCP).
I have been feeling some "AI FOMO" lately because the industry is moving so quickly. Talking to Bobby helped me bridge the gap between the "vibes" of modern AI coding and the security standards we need as professional engineers.

Vibe Coding vs. Mission Critical Production: Bobby shared his perspective on where "vibe coding" fits into the software development life cycle and when it becomes a risky proposition for an enterprise. He explained why prototypes are a great way to explore a solution space even if you eventually throw them away.
Managing "YOLO Mode" with Sandboxing: We discussed the "YOLO mode" found in many AI tools and how engineers can use progressive security configurations to keep things under control. -** The Shift to Spec-Driven Development:** Bobby talked about moving away from probabilistic guesswork and toward "spec coding". He explained how to use tools like "skills" or "slash commands" to align an AI with your team's specific DNA and ways of working.
The "Confused Deputy" Problem: We touched on the security risks of AI agents and why you shouldn't just give them machine credentials to act on a user's behalf. Bobby highlighted the importance of finding the right intersection between what a user is allowed to do and what the AI is permitted to do.
The Changing Role of the Engineer: We explored how AI is shrinking the development life cycle and why communication might be the most valuable skill for a developer in the future. Bobby also shared how designers and PMs are starting to use these tools to contribute directly to codebases.

Final Thoughts

Bobby reminded me that while tools are changing, the core of engineering is still about requirements and making good decisions.

The age of AI is not about replacing engineers. It is about helping them. By being good communicators, teachers, and security-minded builders, we can use these amazing tools to make better, safer software.

What is your take on YOLO mode coding? Let me know in the comments! 🌱
If you want to hear more, check out the full episode: https://listen.casted.us/public/49/Making-Software-2b1cff7b

The four-year-old typo that nobody can fix 🧟 and more about building developer tools

Carla Urrea Stabile — Wed, 25 Feb 2026 14:30:00 +0000

As the host of Making Software I get to have some pretty real conversations about what it actually takes to build good software. And in my recent chat with Raghd Hamzeh (Senior Software Engineer at Okta and a core maintainer of OpenFGA) hit home for me.

We talked about a side of engineering that doesn’t get enough airtime: what happens when your users are other engineers? If you’ve ever built an API, an SDK, or even just a shared library, you know that developers are the most rewarding, but also the most "vocal" audience you can have.

Here are the three things from our conversation that have been living rent-free in my head:

1. The "Breaking Change" Itch is Real 😬

Raghd admitted something that I think a lot of us can relate to: when there’s a four-year-old typo in one of the products you're building, that drives you crazy. It could be just a small naming inconsistency, but when it’s there, it's staring back at you every time.

We got into that internal battle every maintainer knows: do you break everyone’s build just to satisfy the need for a clean API? Probably not. But it’s a powerful reminder that the decisions we make in Month 1, like how we pass a parameter, become the legacy we have to live with in Year 5.

2. Stop building "Alien" SDKs 👽

This one got personal! While coding on the Ruby SDK for OpenFGA, I ran into this head-on. Rubyists are opinionated (I should know, I’m one of them).

When you’re building multi-language tools, you’re constantly balancing two things:

Consistency: Making sure the Go SDK and the Python SDK behave the same way.
Idiom: Making sure a Ruby dev doesn't feel like they're writing Java code with extra steps.

Raghd’s take? You won't get it perfect 100% of the time. Sometimes, you have to prioritize the long-term health of the platform over a "perfectly idiomatic" implementation just so the project stays maintainable for the team behind it. That tension never fully goes away, you just get better at navigating it.

3. The "AI" file that’s actually for humans 🤖

With the rise of AI, everyone is adding agents.md files to their repos. Raghd had a spicy take: Write that file for your human contributors first.

If you want people to help you build your open-source dream, lay out your expectations clearly:

How should commits be structured?
What does the core architecture look like?
Should contributors open an issue before submitting a PR?

Documenting these "non-code" decisions up front saves an enormous amount of friction. It turns "This PR isn't what we wanted" into "Here is the blueprint we’re all following."

🎙️ Want the full story?

Check out the full episode of Making Software here: Link to episode

I’d love to hear from you in the comments, what’s the one tiny thing in your codebase that you’re dying to "breaking change" just to feel better? 😅

Why Your Demo Code Should Be Treated as Production Code (And Other DevRel Secrets) 🎸

Carla Urrea Stabile — Thu, 29 Jan 2026 10:38:56 +0000

Have you ever found a code snippet in a tutorial, spent an hour trying to make it work, only to realize it’s using a deprecated library from 2019?

We’ve all been there.

I recently sat down with Sam Bellen, Principal Developer Advocate at Auth0, for the first episode of the Making Software podcast. We talked about the "diplomatic" nature of Developer Relations, the controversy of "selling" to developers, and why we need to stop treating demo code like a second-class citizen.

Here are the key takeaways for every developer, whether you’re looking to break into DevRel or just want to build better software.

1. DevRel: Part Engineer, Part Diplomat 🤝

Sam and I agreed on a unique definition: DevRel is a mix of developer and diplomat.

As a developer, you’re used to talking to Product Teams to understand requirements. In DevRel, that flow often reverses. You are the "voice of the developer" inside the company.

"It’s building relationships with the product teams... at a certain point, they will start trusting that what you’re telling them is actually valuable feedback instead of just randomly pinging people on Slack." — Sam Bellen

The Lesson: If you want to influence a product's roadmap, don't just throw bugs over the fence. Build a relationship with the people making the product. Trust is the currency of influence.

2. Authenticity > Sales 🚫💰

Developers are notoriously skeptical of being "sold" to. We can smell a marketing pitch from a mile away. Sam’s approach? Lead with the problem, not the product.

Instead of saying, "Use our auth tool because it's great," talk about how hard it is to implement DPoP (Demonstrating Proof-of-Possession) or Passkeys manually.

When you illustrate the complexity of a problem, the solution (your product) becomes a natural part of the conversation rather than a forced advertisement.

3. Treat Demo Code as Production Code 🛠️

This was Sam’s biggest take: Any code you write (even a tiny sample for a blog post) should be treated as production code.

If a vulnerability is found in a framework, DevRel teams should be the first to update their samples. Why? Because that sample is often a developer's first "touchpoint" with your tech.

Why this matters:

Security: Developers often copy-paste samples directly into their projects.
Trust: If your "Quick Start" doesn't work out of the box, you've lost the user.
Maintenance: Technical debt exists in docs, too. Set aside time (Sam recommends monthly) to audit your repos for deprecated APIs.

4. Get Your Hands Dirty with the Spec 📖

Sam has a "superpower": he actually likes reading technical specifications. While most of us fall asleep reading an RFC, Sam uses them to build visual tools that explain what’s happening "under the hood."

"In order for me to explain something... I build it myself. Not a clone of the product, but a demo that implements the topic. I make loads of mistakes, get lots of errors, and eventually, I figure out what's happening."

The "Aha!" Moment: You don't truly understand a tool until you've tried to build the logic it simplifies.

Summary: Two Steps to Better Developer Experience

If you’re an engineer looking to improve the DX (Developer Experience) of your project today, start here:

Listen to your DevRel team: They aren't just "social developers." They have the technical baggage and the community feedback to tell you what’s actually broken.
Stop "dropping" code on GitHub: Don't just create a repo and ignore it. If it’s public, it’s "production" for someone else.

🎧 Listen to the Full Episode

Want to hear the full conversation about guitars, Passkeys, and the early days of DevRel?

Listen to the full episode here or in your platform of choice.

What’s your take? Should demo code be held to the same linting and security standards as the core product? Let’s talk in the comments! 👇

Giving a Three-Hour Workshop: Do's and Don'ts

Carla Urrea Stabile — Thu, 14 Dec 2023 17:51:24 +0000

Today I gave my first three hour-long and in-person workshop. I've delivered talks, made videos but never actually gave a full on workshop. In this blog post are my main learnings from it.

✅ Do - Install Software in Advance

If you can, provide attendees with a list of requirements or pre-requisites to make the workshop go smoother.

I thought of this a bit too late and some folks were not able to install the software or had some issues that made them lose some time and it's just not a nice feeling.

🚫 Don't - Use the Full Time Slot

If you have 1 hour and a half, estimate your workshop to last only 1 hour. Many things can happen along the way, lots of troubleshooting so give yourself and attendees some extra time.

✅ Do - Take Breaks

For a three hour workshop we had only one "big" break of 15 minutes. Unfortunately there was an event after the workshop and time was limited but in an ideal world I'd have done three breaks:

5 min bio-break after the first 40 minutes
10 min coffee break at 1h 20 minutes
5 min bio-break at 2h 10 minutes

🚫 Don't - Rush It

If folks came to a three hour workshop it means they are there willing to learn. Don't rush your words or the explanations you are giving. This aligns with using your time properly.

From Zero to Hero: Identity Edition

Carla Urrea Stabile — Thu, 14 Dec 2023 17:24:58 +0000

Identity is a broad topic, and many resources are available. This blog post gives you a curated list of some of the most relevant resources at Auth0 by Okta and relevant identity organizations.

Identity Fundamentals

A digital identity is a set of attributes that define a particular user in the context of a function that is delivered by a specific application.

Learn it from Vittorio

Identity Fundamentals Course brought to you by the one and only Vittorio Bertocci.

IAM, CIAM, Am I?

Identity and Access Management provides control over user validation and resource access and it's commonly known as IAM.
Customer Identity and Access Management (CIAM) how companies give their end users access to their digital properties as well as how they govern, collect, analyze, and securely store data for those users.

No Time? Learn Identity In a Minute

Identity In a Minute Series is an ongoing series of 60-second shorts that describe key concepts in modern identity management, authentication and authorization.

More Time? Learn Directly from Identity Experts

Identity Unlocked Podcast: "Identity, Unlocked" is the podcast that discusses identity specs and trends from a developer perspective.
Authorization in Software Podcast: "Authorization in Software" features chats with industry subject matter experts in authorization.

Authentication

In authentication, a user or application proves that they are who they say they are by providing valid credentials.

There are many ways of authentication, though. 🤔 Learn about the most common ones:

Authorization

Authorization is the process of giving someone the ability to access a resource.

People usually mix up Authentication and Authorization because usually authentication leads to authorization, but authorization does not always lead to authentication.

Learn more about authorization and the different types: 👇

2FA, MFA all-the-FA

There are many options you can use to prove your digital identity. These are called authentication factors, and there are three main types:

knowledge or something that you know like a password,
possession or something that you have like a device
inherence which is something that you are or is inherent to you.

Usually, your application requires only one authentication factor to authenticate a user, typically a password. In some contexts, you may want more assurance about the user's identity. In that case, you can require two or more authentication factors. That's what two-factor authentication (2FA) and multi-factor authentication (MFA) are all about.

Learn more about 2FA and MFA 👇:

OAuth2, OIDC, Oh-what?

There are many standards used for identity. Some of the most relevant are OAuth2 and OIDC. OAuth 2.0, which stands for "Open Authorization", is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. At the same time, Open ID Connect (OIDC) is an authentication protocol that utilizes the authorization and authentication mechanisms of OAuth 2.0.

But what else is out there? Learn more here 👇

OAuth 2.0 Simplified
OAuth 2.0 and OpenID Connect (in plain English)
OAuth in Five Minutes
An Illustrated Guide to OAuth and OpenID Connect
OIDC Playground
SAML Authentication: you can also use samltool.io's playground to learn more

Tokens, tokens, and more tokens!

A token is a piece of data that has no meaning or use on its own, but combined with the correct tokenization system, becomes a vital player in securing your application. There are different tokens, but what does each one do? how do you use them?

WebAuthn

WebAuthn is a W3C recommendation for defining an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications to authenticate users strongly. Here are some great resources to learn more:

Passkeys

Passkeys are password replacements that provide a faster, easier, and more secure user login experience that leverages WebAuthn under the hood. Learn more about passkeys:

3 Learnings After 1 Month As A Developer Advocate

Carla Urrea Stabile — Tue, 05 Dec 2023 11:05:38 +0000

A month ago, I joined Auth0 as a Senior Developer Advocate. Before that, I worked as a backend engineer in a product team. I’m learning a lot in this new role, and I wanted to summarize the 3 main things I’ve learned so far.

✍🏼 With flexibility comes responsibility.

I’m part of the Content Team at Auth0, so my main task is to create content. This comes with a lot of flexibility and a bit more responsibility.

Content creation is a creative process; as such, the inspiration and ideas don’t necessarily come up when we sit down and tell ourselves, “time to be creative!”. There is a lot of flexibility in deciding what I want to talk about and when to deliver it. You might think this sounds great, a “no deadlines” situation, but it’s not true. One of my team’s goals is to create a certain amount of content. I can manage my tasks and decide when the piece I’m working on will be ready. Still, I can’t just overestimate and give myself more time because otherwise, we won’t meet the team’s expectations.

📚 You are the master of your learning, the captain of your knowledge.

This one caught me off guard, and I feel silly because it makes total sense. As mentioned, my role comes with a lot of autonomy, and it’s crucial to dedicate time to learning. When writing a piece of content, you must research, build demos, and learn new things. Apart from that is critical to set time to grow in the other areas that are important to you. In my case, I want to keep learning about software architecture, and so I try to think of ways to integrate this into my learning path.

🤪 No more breaking production

I’ve broke production multiple times in my career. The most recent one, not only did I break it, but it was reported by the VP of Technology of the Business Unit I was part of. I didn’t get in trouble because I was lucky to be in a company where failure isn’t punished; I know what it is like to feel the pressure of these incidents. In my new role, “going live” means publishing content or presenting a talk. There will still be something facing our customers, but nothing that will make their user experience bad.

Conclusion

After 1 month as a developer advocate, I’ve learned that even though you have the flexibility to manage your tasks and time, you still need to be responsible and deliver. Also, you need to have a learning plan and include the things you want to learn about. Finally, unlike being a software engineer, there’s no breaking production, only publishing new content for more developers.

Thanks for reading! 👋

Why you shouldn’t stick to one programming language or paradigm

Carla Urrea Stabile — Tue, 05 Dec 2023 11:04:37 +0000

If I wanted to summarise all the programming languages and paradigms that I’ve used throughout my entire student life and professional career I don’t think I’ll be able to write them all down, but I’m gonna give it a try to see how many I can actually remember, not to show off but to show you, my dear reader, why you should continuously learn even after becoming an expert in some language or paradigm.

GaCeLa — imperative: A GCL implementation by Dijkstra used in my university. My first programming language, imperative and easy to write.
Modula-2 — imperative/modular: we use to call it “the child” of Pascal because it was kind of similar. The idea was to introduce data abstraction and OOP. If you think C’s pointers are annoying, do yourself a favour and forget I even mentioned this language here.
Java — imperative: Aha! finally a programming language you all probably know. We used it to get a better understanding of OOP and data structures, I remember doing a lot of Graphs implementations with Java.
Assembly — imperative: fuck, yes. Probably the lowest level I’ve ever programmed, but actually quite fun in the end. One assignment was to implement the game pong.
R — functional: This was my first encounter with a functional language and I remember it being so weird but also so straight forward when it comes to data analysis and ETL.
Haskell — functional: My experience is only academic, and if I’m honest at the time I struggled so much to understand it. Recursive programs were never my favourite thing and well, let’s say there’s a lot of it in functional languages.
C — imperative: Also only academic, but quite useful to teach pointers and memory managing.
SQL — declarative: At this point
Python — imperative: I got tired of
Ruby — imperative: describing what I did
Elixir — functional-ish: with each one
Kotlin — functional-ish: of these languages.

Of course, there are many more, HTML, CSS, JavaScript, C++, C#, etc, but they all fit into the paradigms I’ve used in the past already so I’m just gonna stop here.

For me, it is very exciting to learn a new language/paradigm. You always get to compare the similarities and differences between them or to understand why things are done in one way for one language and differently for the other.

I’ve learned something new from each of the languages I’ve used, and each paradigm teaches you to improve and activate problem-solving skills in different ways. At the same time, being familiar with several paradigms makes you not afraid to go for a new job that uses X language that you’ve never used before. I doubt I’d go for a job that uses Modula-3 in 2021 but you get the point.

Of course, at the beginning of your professional career, it’s important to learn at least one language and paradigm and really master it to land a job, but my advice is: do not stop here. Just because you are an expert in JavaScript doesn't mean this is all you’re gonna do for the rest of your programming life, the tech world moves way too fast and what is being widely used today might not be as popular tomorrow.

Also, being flexible in terms of what are you going to program on it’s a very appealing skill for companies. Yes, they want to have experts, but at some point, they might also need someone who can handle doing a little this and that in some other app they own before hiring someone new and your extra knowledge might come in handy.

I hope I gave you some reasons to go learn more programming languages and paradigms once you’ve felt you master at least one 😬. If these reasons weren't enough well, at least you got to read what weird programming languages I’ve used and maybe learned that they actually exist 😅

Thanks for reading 🤩

/r/explainmelikeimfive — talking about programming to kids

Carla Urrea Stabile — Tue, 05 Dec 2023 11:01:29 +0000

If you are someone that regularly uses the internet, you have probably come across Reddit and the subreddit called /r/explainmelikeimfive. Here, people ask questions and others can answer them in very simple words, like there are explaining to a 5-year-old.

As part of the Women’s International Day initiatives @ XING, led by the amazing
lauragrau
, we, a group of female software engineers went to a school to talk with kids about what it's like to be a programmer and what we do in our day to day life. This is even challenging to explain to adults that are not in the tech area, so I was very nervous about how this was going to turn out.

Ages ranged from 4 to 12 years old and they had amazing questions and comments that really make you think how smart these kids are.

The first day we started with the younger ones, the 4–6-year-olds, in the beginning, we wanted to talk about what a computer is and its components and later on what we can do with them.

4-6 year olds wanted to know if I was a hacker and if I used the cloud to store my photos. Also, they didn’t like computer viruses because they are bad like coronavirus, and concluded that facemasks where the equivalent to an anti-virus.

Most of them already knew what I was talking about, but they were excited about asking me questions. We did an activity to show how an if-then-else works, kind of like Simon says so they had to define a condition and perform an action based on it. Simply, as the programmer one of them would touch their nose, and the computers (the rest of the class) would have to raise their hands in the air, but only if the nose was touched by the programmer. They immediately understood they didn’t have to do anything if the programmer didn’t touch their nose.

On the second day, we moved to 7–9-year-olds who were definitely more aware of programming. They were very excited to know they could use programming to build robots and solve problems but most importantly: make videogames like among us and Fortnite.

7–9-year-olds already knew programming was about doing stuff with computers and videogames so they wanted to know how they can build GTA6. They also learnt the words algorithm and prototyping.

For them we did a Design Thinking activity, based on the Design Thinking Challenge for Kids, consisting of them trying to put themselves in the shoes of someone else, brainstorm with ideas, offer a creative solution, prototype it and test it. They really enjoyed the activity, and we did the same for 10–12-year-olds. Most of them chose to offer a creative solution to a friend and their ideas were awesome. I asked them in the end what they liked about this exercise and their answers were in the lines of “solving problems in a creative way”, “using our brains to understand what someone else’s needs are” and so on…and then before I left them I asked them if they had any other questions for me

10–12-year-olds wanted to know what motivated me to become a software engineer, what the deep web was, what was the meaning of the “https://” part in the websites and if the salary was good. They were also disappointed they were not going to learn how to make a website in this 20 minute talk with me.

In general, they all blew my mind.

I know I’m not the first one to realise this, but given that my contact with kids is almost nonexistent, I realised how incredibly creative they are, how they have no filter whatsoever and most importantly how you should not underestimate them and not try to explain things to them like they are five. 😅

My journey becoming a Senior Software Engineer

Carla Urrea Stabile — Tue, 05 Dec 2023 10:56:55 +0000

I’ve been working as a Software Engineer for a little over 6 years already and I have come along away to actually consider myself a “senior” software engineer (I still don’t, to be honest. There is so much out there to learn). Battling imposter syndrome, moving countries, and finally accepting that I didn’t have enough experience yet to be called a senior engineer, here I tell you my story.

My journey began with my first job at Akdemia, I was required to do an internship in order to get my CS degree so I started as an intern for building their android app from scratch. At the time I was the only android developer so my learning was mainly from online courses and Youtube. During this time I also had the opportunity to get into Ruby On Rails and work on building and maintaining REST APIs. We used SCRUM and had most of the ceremonies. I was also in close contact with one of our clients so I learnt a lot about how to communicate with stakeholders.

After 2 years in Akdemia, I decided to move to Spain to study for a Masters in Data Science. Even though I had already 2 years of working experience, coming to a new country meant almost starting from zero. At the time you had to gain some “trust” from local companies, and landing on your first job was challenging.

Thanks to my masters I was able to find an internship as a Data Scientist at Jeff (former Mr Jeff), where I was working with python generating reports for their KPIs and even building a very simple product recommender. I learned a lot from my colleagues there, some of them had 10+ years of experience and really helped me understand how things worked in Spain, at the same time they advised me what I could learn so I paid close attention to what they were doing: Docker, Kubernetes, micro-services, etc and started to learn them on my own.

Once my internship was over I switch to another job where the team was very small, and by small I mean it was only me. They needed to build an android app, a full backend, define the deployment process and apply some agile methodology, I had to do this on my own and it was a great challenge. I managed to build the backend with Ruby On Rails, PostgreSQL, Docker, and an android app that was initially built in Java and later on migrated to Kotlin, which needed to connect via Bluetooth to some hardware to control it. I introduced Slack as a communication tool and PivotalTracker for project management. I also worked closely with the CEO, the designer and the content creator which helped me improve my communication skills.

Later on, I joined a new company that did projects for third parties and I was involved in multiple projects. I learnt Django and improved my python skills. Unit testing was mandatory (as it should) and we would always try to deliver to the next level. I also had the opportunity to manage our AWS and after a while, I could deploy new apps in minutes using Route53, RDS, S3, EC2, LoadBalancer, Lamba functions, etc (I must admit AWS docs are probably the best I’ve ever read). Another project I was also involved in was built in Ruby and Grape Framework, I also learned a little about elasticsearch and React.

Finally, I joined XING, where I can say I’ve learned the most. Not only I’ve put into practice everything that I learned in the previous years (Ruby, Rails, testing, Agile methodologies, Docker, Kubernetes, etc) but I had to put everything into a bigger scale. With millions of users and even more requests per day, I have learnt how things work in a big company. At XING, we use AMQP messages to communicate between services, Docker and Kubernetes as part of the architecture, and Rails for most of the apps, but we also have services written in Java, Kotlin, Elixir, GraphQL, etc.

I’ve learned how the communication process works in such a big company, how to communicate with the Product Manager and other stakeholders. I even started participating in conferences and doing public speaking.

I wrote most of this article a few months back when my manager told me she proposed me for a promotion, only today I received the letter confirming it.

Back in my early years of work I thought becoming a senior was a matter of how many years you’ve worked as a developer but I learned this is not entirely true. Seniority comes with meaningful experiences, and while time probably contributes to finding these experiences, they’re not necessarily linked. Today I’m happy to have taken the risk to find myself those experiences and get the most out of them.

This is definitely the beginning of a new journey, new learnings and of course many more experiences.

How to start creating content as a software developer

Carla Urrea Stabile — Tue, 05 Dec 2023 10:54:22 +0000

I’m an active Twitter user and I follow a lot of tech people there. Most of them create great content that I really enjoy reading and I believe this is what makes our tech community great.

For the past year, I’ve been thinking about creating content myself, mainly because I’ve noticed a lack in the content I’d like to consume. There are a lot of great resources about frontend development, JavaScript, Node, etc which I read out of curiosity, but it’s not all of the content I’m most interested in.

I’m a backend engineer who also enjoys team collaboration, being involved in product decisions, time management, productivity hacks, and I’ve decided I want to get started on sharing personal experiences and learnings about those topics.

Next, you will find my personal process into content creation, everyone has their own so maybe you can take a few things out of this post.

Find inspiration ✨

As I said, I follow a lot of tech people on Twitter and I get most of my inspiration from them. I look closely at how they share their content, what they talk about, on which channel, etc. Never to copy them!, but I strongly believe that looking at other people’s work to find inspiration is very useful.

These are some of the people I follow and who have inspired me to create content:

Emma Bostian — she’s a software engineer at Spotify. She’s a part of the LadyBug Podcast, she’s the author of the book De-Coding The Technical Interview Process, she writes on her blog, creates Youtube content, and in general, I just love the way she communicates.
Ali Spittel — she’s a Senior Developer Advocate at AWSAmplify and also a part of the LadyBugPodcast. Ali teaches programming, writes on her blog We Learn Code, she has tutorials, beginner guides, and also creates content for her Youtube channel.
Sara Vieira — she’s a developer at CodeSandbox, has written a book “Opinionated Guide To React”. She’s always programming new and fun stuff and sharing it on her Twitter account and it’s a really fun person to follow. You can check out all the things she has built on her Github account There are many others as well, but these are my favorite software development content creators at the moment.

Define your channel 📹 📃

All of the people who inspire me have different channels to share their content. Perhaps you want to start a blog because you are good at writing, or maybe start a Youtube channel because you are a good communicator and you like editing videos. In my particular case, I enjoy writing and conference speaking. Since in 2020 I wasn’t able to participate physically in any conference, I’ve decided to migrate to a video format (still a WIP but you get the point). I’m also going to be more active in my blog posting 🤞

I’d recommend starting where you feel more comfortable. If writing feels good, start there. You might even find a hidden talent.

Despite the channel you chose, you also need to keep in mind who are you addressing and pick the channel that suits your audience the most.

Define your audience 🗣️

Are you targeting already experienced software engineers? beginners? both? completely up to you! but it’s important to know who you will be talking to.

In my personal case, I’ve noticed most of my ideas are targeted to beginners so at least from now on this will be my target. I believe starting with beginners' content is a good thing, they are just getting to know the community and the majority of the content they might consume will be new information.

Write down your ideas 💡

photo by https://www.pexels.com/@steve

I literally have 5–10 notes in my Google Keep account dedicated to random ideas for potential content, also in my medium account, I probably have 10 possible blog posts that are completely empty but just contain the main idea I’d like to share someday. In fact, this very blog post is one of them and it’s been a WIP since 2021 started (yikes!).

Even if you think the idea is not worth sharing, write it down, and keep it there for later. I’ve noticed that depending on my mood, the day I’ve had, etc, when I re-read my notes after a while I’m sometimes able to tweak them or improve them and also discard them. 😅

Start creating 🤩

Don’t be like me thinking about doing this for months, if you found an idea that resonates with you and you think is worth sharing just go for it!. We are part of a community that appreciates content creation a lot and even if you don’t reach millions of people, at least you were able to create something out of your own mind.

After you’ve defined your audience and channel the only thing left is the content, for a video, for example, you could write a script to really have a clear idea of the story you are sharing, although some people prefer to improvise, it’s up to you. For blog posts, you could start with drafts and improve them every time you re-visit them.

Lastly, make it public! For me, the hardest part because I’m never 100% happy with the content (thanks imposter syndrome). This blog post is also an opportunity for me to improve on this and just go for it.

Ali Spittel posted this tweet a few days ago and it really pushed me to finally publish this story (thanks for that!):

and let me tell you, did I benefit from this blog post… hell yes!. I’m no content creator expert, I’m literally just starting, but since I’ve been overthinking this for too long I thought it was worth sharing it with you so you won’t do the same as me.

Hope to read/watch/hear something from your creation soon. 💪

My Experiencie Giving My First Lightning Talk ⚡️

Carla Urrea Stabile — Tue, 05 Dec 2023 10:50:26 +0000

A couple of weeks ago I attended to the FullStackFest in Sitges, it was great to get to know people with the same interests as me and also a fantastic opportunity to present my first lightning talk ever.

The conference lasted 3 days, and in between coffee breaks I was helping my colleagues in the stand of the company I work for, so I could talk to many of the attendees, this made me realise how smart everyone was and how we were all there to learn from each other. At the same time, talking to people made me see how empathetic the dev community is and how it was worth to give it a try and present a lightning talk.
This year I also met great people at the RubyUnconf who I think are great presenters and I could take some tips from them as well. My intention is to share some of those tips and some of my own.

So, first things first:

What to talk about? 🤔

So, I'm a Software Engineer, currently working with Ruby On Rails apps, but I've also worked several years as an Android Developer and Backend Developer using Django, so when thinking about a topic my first thought is: it must be something about programming.

Turned out, I talked about how we currently handle pull requests from GitHub in our team, so not really about programming but kind of related. The main reason I choose this topic is, well… I had very short time to prepare and even though I program almost every day of my week, a programming talk deserves way more preparation than that. Talk about a process we repeat almost everyday seemed definitely easier.

How to make it last less than 5 minutes? ⌛️

Challenging enough, not only the first time talking in front of ~600 people but to get to the point in less than 5 minutes. I believe the most important part is to KISS (Keep It Simple, Stupid), yes! I tried my best to keep it simple but give enough details. Even when I felt I couldn't give more details I tried my best to point people into researching more about a certain tool or process.
One thing that really helped me was to plan the talk to actually be 4 minutes long, just in case I felt like giving more details in the moment.

How to overcome nervousness? 😥

My friends and colleagues say I didn't look nervous but I was freaking the f out. My heart was beating super fast and I had to make an effort to speak and breathe at the same time.
So how did I deal with that? same way I try to deal with awkward situations in my day to day: making jokes or making people laugh. One good thing was, when you were on that huge stage you couldn't really see the audience, but you could hear them perfectly. So when I felt nervous and made a silly joke, I could hear them laugh a little bit and that would give me a little more confidence make me more relaxed.
Another good thing to do is to think the people sitting there are as willing to learn as you! 🥰

Take tips from more experienced people 🤓

We are always beginners at some point, take your time to see other people's presentations and take tips from them. Take a look on how they organize their slides, how they tell their story and then make your own way to tell your own story.

Final thoughts… 💭

Thankfully I had a great experience, people were super nice and hopefully they enjoyed as much as I did.

Hope this helps you to find the courage to present your own talk! 💪