Posts Tagged career

Tool-Agnostic, Problem-Centric: The Real Developer’s Advantage

When I first moved from Brazil to the U.S., I faced a significant language barrier—not just English, but also a shift in programming languages. Transitioning from FoxPro to .NET felt daunting. Would I still be valuable as a developer? Would I keep up with emerging technologies? Fast forward 30 years from starting my professional journey, and I’ve navigated multiple language changes and now, AI-driven development. My recent talk at the Code4Y’all user group, Code Fluent: Thriving Through Language Shifts, explored how to adapt and grow despite constant technological shifts.

Here are five key takeaways from that session:

1. Focus on Problem Solving

Languages, frameworks, tools—they’re just tools. Your real value comes from your ability to solve genuine problems for real people. Are you listening to stakeholders and understanding their challenges firsthand? That’s your core value—not any single language proficiency.

2. Communicate for Clarity

Learning to clearly express your intent—both in plain English and in code—is essential. Clear thinking leads to clean code, enabling better collaboration with humans and AI alike. Adopt practices like the Given-When-Then format. Write self-explanatory code, clearly stating what and why before jumping into how.

3. Leverage Modern Tools

Writing code isn’t enough—use tools that improve your coding process. IDEs and AI assistants can refactor, clarify, and optimize your work. During the talk, I demonstrated how Rider AI summarized features of an event-sourced class, illustrating how effective naming and structure enhance tool support.

4. Learn from the Community

Throughout my transitions—from FoxPro to .NET, Ruby, and back—communities have consistently helped me grow. Seek out peers slightly ahead of you. Share your insights and experiences, join meetups, and engage in open-source projects. Teaching others, even from a beginner’s perspective, significantly accelerates your own growth.

5. Grow Strategically

Whether you’re starting your journey or considering another tech shift, always question the reason behind learning something new. Does it align with your personal goals, your clients’ needs, or industry demand? Don’t chase fleeting trends—pursue relevance. Embrace AI as an ally, not as a competitor.

Final Thought

Thriving through language shifts isn’t merely about job security in a rapidly changing tech world. It’s about cultivating trust, solving impactful problems, and making a meaningful contribution. True code fluency goes beyond syntax—it’s about clarity, empathy, and the lifelong pursuit of learning.

Watch the full talk here:

, , , ,

Leave a comment

Coaching from the IDE: Real-World Leadership Practice with AI

In my previous post, Leveling Up with AI: Practicing Leadership Before You Have the Title, I shared how developers can use AI to practice leadership before they ever get the title. But that was just scratching the surface.

In this follow-up, I want to go deeper. Let’s talk about what it really looks like to lead from the IDE—how to rehearse both technical and team leadership, using AI not just as a tool, but as a collaborator.

From Giving Orders to Practicing Influence

One of the biggest shifts for any senior developer stepping into a leadership role is moving from doing the work to guiding the work. That doesn’t mean you stop coding. It means you start thinking in terms of setting direction, clarifying expectations, and building shared understanding.

AI tools give you the perfect environment to rehearse that shift. Why? Because the way you prompt an AI mirrors the way you coach a teammate:

  • Are your instructions clear and context-aware?
  • Do you know what good looks like—and can you explain it?
  • Can you review work constructively and communicate what needs to change?

If not, AI will show you. Fast.

Simulated Mentorship

Here’s a practice I’ve been using: I treat AI like a new team member. I give it a task, but before it gets started, I:

  1. Share the why behind the work.
  2. Point to our documented expectations.
  3. Ask it to summarize the plan before diving in.

Then I let it do the work, and I review it like I would a junior dev’s pull request:

  • Does the code follow our style and naming conventions?
  • Are the tests meaningful?
  • Are the behaviors clear?

Instead of just fixing things, I use the opportunity to explain, document, and evolve our standards. The AI updates its own docs. Next time, it improves.

That feedback loop is leadership. And it’s one you can practice every day.

Practicing the Team Lead Role

But it’s not just about code quality. Team leads help their teams connect the dots between business goals and technical solutions. That’s where AI shines again.

I’ve started using AI to:

  • Turn stakeholder conversations into user stories.
  • Generate Given-When-Then examples based on acceptance criteria.
  • Draft implementation plans from stories.
  • Ask clarifying questions I didn’t think to ask.

These aren’t just productivity hacks. They’re reps. Each one builds my ability to:

  • Translate vague requests into executable plans.
  • Spot ambiguity and get ahead of confusion.
  • Communicate clearly across technical and non-technical audiences.

That’s real leadership work.

What You Practice, You Get Better At

You don’t need to wait for a promotion to start acting like a lead. And you don’t need to wait for the perfect team to practice coaching. With AI, you have an always-available assistant who will mirror your communication—for better or worse.

Use that.

Try leading through conversation and documentation, coaching through prompts, and learning through review. You’ll build the muscle of leadership—starting right now, from your IDE.

And when your next opportunity comes? You’ll be ready.


🎥 Want to see this in action? I gave a live demo of everything I describe here during my talk last week at the Houston .NET User Group.

If you want the slides and extra resources, let me know.

Stay tuned for more.

, , , ,

Leave a comment

Leveling Up with AI: Practicing Leadership Before You Have the Title

Most senior developers don’t get formal training to become leads—they’re expected to step up when the time comes. But how do you practice leadership before you’re officially in charge? This post explores the challenge and how AI can help fill the gap.

After sharing these thoughts with Improvers, I wanted to share the core ideas with a broader audience. Whether you’re on the path to becoming a team lead, technical lead, or both, AI can become a powerful practice partner—if you learn to use it well.


The Leadership Gap No One Talks About

You’re a strong senior developer. You can implement features, fix bugs, and review code. But suddenly you’re expected to lead:

  • Set standards
  • Clarify expectations
  • Help others level up
  • Communicate with stakeholders

And often, you’re given no time, training, or space to practice those skills before being thrust into that role. That’s where AI can step in.


Simulating Technical Leadership

As a technical lead, your job includes activities such as:

  • Setting clear technical expectations
  • Defining coding standards and architectural decisions
  • Guiding others through precise instructions

AI can simulate junior team members:

  1. Write clear expectations and standards in markdown.
  2. Ask AI to implement a small feature using those docs.
  3. Review its output, refactor, and give feedback.
  4. Ask AI to update the docs with what it learned from your edits.

This loop simulates onboarding a new developer, guiding their growth, and reinforcing shared standards, before you have to lead a real team.


Practicing Team Leadership

Team leads focus less on code and more on context:

  • Translating stakeholder needs into user stories
  • Clarifying the “why” behind features
  • Helping the team stay aligned and focused

If you think “writing stories is not my job”, let me offer you some food for thought: user stories are for everybody.

You can use AI to simulate this, too:

  • Start with transcripts or raw notes from a stakeholder meeting
  • Ask AI to summarize and extract user stories
  • Share your own story-writing guidelines (like “cinematic user stories” or Gherkin format)
  • Ask AI to refine the stories and propose implementation steps
  • Review its questions for stakeholders, adjust the plan, and iterate

In doing so, you’re practicing:

  • Clear written communication
  • Understanding business needs
  • Prioritizing value over output

Don’t Fire and Forget—Coach Like a Leader

AI isn’t a magical replacement for your thinking. It’s a mirror for your clarity. When you:

  • Write unclear instructions, AI gets confused (just like a new team member would).
  • Skip review steps, AI goes off track (again, just like people).
  • Provide thoughtful feedback and checkpoints, AI improves—and so do you.

You’re not just getting better results from AI. You’re developing the habits that make great leads: asking better questions, making decisions visible, and clarifying expectations.


Start Practicing Now

You don’t need a title to lead. You don’t need permission to start practicing. And you don’t need a team to begin coaching—AI can help you rehearse today.

Get intentional. Try it. Reflect. Iterate. And when your opportunity to lead comes, you’ll already be ahead.

🎥 If you’re interested, here’s a full talk covering this topic:

, , ,

1 Comment

How Senior Devs Level Up (with a Little Help from AI)

When does a senior developer become a leader?

It doesn’t happen when someone gives you a title. It starts long before that—with how you show up, communicate, and guide others. In my upcoming talk, I’ll show how you can use AI to practice the skills of a team or technical lead, even before you officially step into the role.

Let’s walk through seven mindset shifts that signal you’re ready to level up—and how AI can help you get there.

1. You Don’t Need the Title to Lead

Leadership starts with trust, not authority. Think of the teammates you naturally go to for guidance—they didn’t wait for a role change to lead. One of the simplest ways to grow your leadership? Improve how you give updates and ask questions. AI can help you practice being clearer and more intentional.

2. Team Lead? Tech Lead? Try Both

Some leads focus on systems, architecture, and elegant code. Others focus on people, process, and alignment. Which path suits you? With AI, you can simulate both—and get a feel for where your strengths (and blind spots) lie.

3. Better User Stories, Faster

Translating messy input into clean, testable stories is a superpower. AI can take a vague stakeholder note and help you shape it into a well-formed user story with acceptance criteria. The more you do it, the sharper your instincts become.

4. Give Instructions That Actually Land

Ever handed off a task that came back completely wrong? You might not be as clear as you think. Try this: give AI your instructions and see what it produces. The gaps it finds will help you build clearer, more useful guidance for your real team.

5. From Reactive to Proactive

Great developers solve problems. Great leads anticipate them. You can use AI to map out sprints, spot blockers, and scan patterns before they escalate. That shift from reacting to initiating is the core of the leadership mindset.

6. Translate Stakeholder Speak

Stakeholders don’t think in JIRA tickets. They talk in emotions, goals, and gut feelings. Want to become indispensable? Practice turning that fuzziness into clarity. AI can help you turn phrases like “this feels slow” into actionable specs your team can use.

7. Start Practicing Now

You don’t need permission to grow. You just need the right habits—and a place to safely practice them. That’s what this talk is about: using AI as your practice partner to grow into the leader you’re becoming.

📅 Join me live on June 11, 12–1PM CDT:
Register here

#SeniorDev #TechLeadership #AI #LevelUp #ImprovingThoughts

, , , ,

Leave a comment

Certifications, Beliefs, and Underachievements

I got an Azure certification. It’s the first one for me in 20 years. The last was the defunct MCSD.NET, back in the .NET 1.0 days. In 2007, I studied for the new certifications for the .NET 2.0 update, but I never took the exams.

So why revisit certifications?

Here are the main reasons, in order of importance:

  • To adjust to recent changes to my team, I need to brush up on my Azure skills
  • Having certified professionals helps the company
  • It’s an addition to my resume

But beyond that, I like setting goals that allow me to practice other things. I also wanted to practice challenging my beliefs and strategic underachievement this time.

Challenging my own beliefs

Mark Mason has a good video on challenging one’s beliefs. I took note and made a point to myself to revise my beliefs.

In 2011, I posted my thoughts about certifications. Since then, anytime the topic of certification came up, those were the thoughts I’d immediately say out loud, without even asking myself if they were still true.

It was time to challenge my own beliefs.

So, I re-read my posts on the subject and others I wrote around the same time, which helped me remember where I was in my professional life.

I then decided to study and take an exam to see how it is nowadays.

In summary:

  • The quality of both the questions and the software we use to take the exam has improved
  • It’s a good way to focus on learning or reviewing something, even though not all of it applies to what I do.
  • I still recommend that study groups to learn the content from different perspectives while helping others achieve their goals.

Another thought I had while going through the course material is that a lot of the content gets me bored, and it reminded me of a decision I made 30 years ago about what aspects of IT I wanted to focus on (namely, software development with a focus on solving people’s problems). Some elements of that content reminded me that for each thing that either gets me bored or uninterested, there are professionals out there who are passionate about it, so I need to know who they are when I need help with it.

Strategic Underachievement

Reading Four Thousand Weeks: Time Management for Mortals reminded me that sometimes good enough is good enough. I can’t excel at everything. I should consciously decide what I want to excel at and then define what supporting goals can be set up for strategic underachievement.

That’s how I’ve set my goal for this certification.

To execute it in alignment with that expectation:

  • I watched a preparatory course on Udemy at 2x speed
  • Whenever needed, I either slowed down or paused the video, paid attention, and took notes
  • If a topic applied to my current project, I tagged my notes with the project
  • I took the practice test 3 times to make sure I had a decent score, as well as knowledge of a good number of potential questions asked in the actual exam
  • When I hit a decent score on the 2nd practice test, I scheduled the actual exam for the following week
  • I practiced the exam software sandbox to become familiar with it
  • I took the exam in person instead of online to eliminate the 30 minutes necessary to prepare the environment and validate with the proctor

I (barely) passed the exam. It is good enough. The entire process and results met the expectations I set.

Celebrate the win. Reflect. Move on. Revisit it in the future as needed.

, , ,

1 Comment

User Stories are for Everybody

Not happy with the user stories your product owners or business analysts are writing? Speak up.

I don’t mean that in a rebellious way. I mean it collaboratively.

Let them know where you’re having trouble understanding to produce and deliver results.

Think a different choice of words would clear things up? Consider writing them yourself. Put it down in your own words.

Share it with the team and see if it brings clarity for everybody. It may or may not resonate with others. Pay attention.

The people writing the stories may be fighting their battles and are thankful to see better deliverables, regardless of reworded stories that facilitated communication and collaboration.

User stories aren’t requirements. They’re placeholders for conversation. You’ve heard that before.

With good conversations, stories don’t have to be fully spelled out. Some details can be left out. Too much detail may leave too much room for (mis)interpretation.

Don’t understand the meaning of a word within the context? Ask for clarification.

Don’t understand the context? Ask.

Need different perspectives to understand the context? Ask.

A coder might be able to offer solutions to the problem a story means to solve. So can a UX designer. Or a QA team member. In the context of a scrum team, they’re all developers. Let’s develop great stories.

Great stories are told and retold.
Great stories yield great products.
Great products are talked about, over and over.

, , ,

1 Comment

Do your values overlap with your employer’s?

Not happy with your job? Find an employer whose values align with your own.

Are you clear on what your values are? I had clues about my own, but it wasn’t until last year when I narrowed them down. How? By actively participating in a book club with my co-workers (something encouraged by Improving’s values).

We covered Brene Brown’s Dare to Lead. In a certain section of the book, there’s an activity for the readers to identify their values. It presents a long list of common values. We’re supposed to identify the top 2. Not easy, so we may start with our top 10, and then narrow it down. I found mine. I call the top 2 my core values, and the remaining 8 my supporting values. As I look at Improving’s values and philosophy, I see how the company makes it easy for me to live my own values.

Here are a few practical examples:

  • I’m an avid book reader. Having great people to have conversations about the content enhances the experience a lot. We put the word out in our internal technical communities, and book clubs are formed.
  • I identify a need for a space where I can gather motorcycle track riders who want to discuss their experiences, analyze their learnings, share their tips. I create the community and I get the space at Improving to have our meetings.
  • My co-workers show interest in the practices I have to organize life, set and execute goals, pick up hobbies, learn languages. I put together my notes, create classes, and offer them as internal training. Many people join in, we deepen our relationships and have a great time.
  • I’ve been practicing meditation, financial health, physical activities. Improving comes up with an internal, year-long initiative focusing the month of January on wellness. Tons of people join in, experiences are shared, good times are had, great results are achieved.

I could keep going on and on. In fact, the subject comes up in my mourning journalling very frequently. Sometimes, I make those words surface in this blog. Other times, I keep them to myself, as I introspect and look for ways to increase and/or leverage the overlap there is between my values and Improving’s.

, , , ,

Leave a comment

Virtual Brown Bag: February 2021 Summary

Time flies, but the weekly Virtual Brown Bag meetings stay strong. Many great conversations have been had in February.

  1. February 25th, 2021

    Troy Hunt’s “Everything you ever wanted to know” post about password reset feature, authentication systems and identity frameworks, JamStackAttack.com, Python

  2. February 18th, 2021

    Rocketbook, ReMarkable, writing cover letters for resume, working for free, junior vs senior devs, using LinkedIn.

  3. February 11th, 2021

    TypeScript: Why?, React Admin

  4. February 4th, 2021

    Form builders, TypeScript

, , , ,

Leave a comment

Use Your Voice

Quite often, we give up on writing a blog post, an article, a new talk, because we think “it’s already been done, why should I bother?”. For example, we might have finally grasped one of the SOLID principles. Hooray! Success. We have to tell others of our epiphany. But then, why not tell others to simply go listen to uncle Bob?

I believe that, like most people, you follow some sort of news…

  • How do you decide what type of news to follow (technology, politics, entertainment, sports…)? I’d guess you pick the ones you’re particularly interested in, as it applies to your life, your work, your current situation…
  • How do you decide which news channel to follow? I’d guess you choose those better aligned with your own views. Maybe you look for those with your favorite sense of humor, or thoughtfulness, or… there’s a reason (or many) why you choose one news channels over another

Every day, the same news are delivered through several channels and types of media. But why? Couldn’t there be just one?

Different people will find different information through different paths. I find information I’m looking for or authors through my research on software development, on music, or motorcycle riding, on productivity, on lifestyle.

There are news sources I’ll never consume at a given moment in my life because of a number of reasons:

  • maybe I can’t relate to the way they deliver their message
  • maybe I don’t agree with them in that moment (opinions can always change)
  • maybe I’m not educated to the level the news are being delivered…

I don’t mind sharing things I have just learned, regardless of how basic it might be. If I don’t share it, there’s always a chance some people would have never known about it. I can’t count how many times I’ve shared something and heard “oh, I didn’t know that”, even though it was something taken from granted by many.

An example that always come to mind for me takes us back to the first paragraph in this post: SOLID principles. After a couple of years of having heard of the Liskov Substitution Principle (LSP), I’ve run into a situation where it finally made sense to me, and I felt like I could articulate that as an example to explain it to others. I sat down, wrote about my experience, took some screenshots showing the code, published the post, and moved on.

Ten years later, that post is my top most-viewed one (31k versus 8k of the post in 2nd place), and it’s been the most viewed every month. I keep getting visits to that post coming from sources I can’t even read the language, which makes me believe those people learned the topic through my words, through my voice. Maybe they’ve all heard of LSP through Uncle Bob, but couldn’t quite grasp it (which was my case). Maybe after reading my post, they went back to Uncle Bob’s writings and were able to understand it better from the newly-gained perspective.

Use your voice. Get your word out. There is always someone listening.

It may be the tone of your voice, you’re accent, your background, your style, your mannerisms, the things that either frustrate or motivate you… those are all things that can possibly draw people to you.

, , ,

Leave a comment

The Importance of Technical Communities

Technical Communities may be the single most important factor I’ve had (and continue to have) in building my professional career. Yes, that’s how important I believe they are.

I first got involved with communities back in the late ’90s. I got a job where I got to work with FoxPro, which I knew nothing about other than that it looked similar to what I knew at the time: Clipper and dBase. That was also around the time the internet was becoming a thing in Brazil in the days of dial-up connections.

In order to get up and running on the required tech stack, I found online forums in Portuguese.

There were many resources in English for FoxPro, but not a lot in Portuguese. I knew some English at the time. Many Brazilian developers didn’t. So here’s what I did: I’d see people’s questions in the online forums, look up the answers in English on the web, and reply to the posts in Portuguese. Why did I get from doing that?

  • I learned a lot of FoxPro in a short period of time
  • I learned a lot of English
  • I helped other fellow developers

A member of the community invited me for lunch one day and gave me a couple of FoxPro books. I asked the reason for the gift, and he said: “If I help 100 people, maybe one of them will give me a hand in a moment when I could really use some help”. I have taken that lesson to heart and applied it to my life deliberately ever since.

Because I was answering so many questions, people thought I was an expert.

When a new version of FoxPro was about to come out, members of the community reached out to the Microsoft office in Sao Paulo to ask if there was going to be an official launch event. The MS manager said they could do that, but there were no MS employees in Brazil who were well-versed in FoxPro. The community member said, “well, problem solved: I know a guy”. Next thing I know, I’m presenting two full-day, soldout launch events. Attendance included people flying from other states (if you don’t know how big Brazil is, please pick up a map…)!

So that’s how I broke into technical public speaking. Next, I got into writing articles, creating a magazine, organizing conferences in a few different States, organizing study groups, creating training videos…

So much came out of the common need to learn a new tech stack, followed by the simple action of helping others along the way, with however little I knew of anything.

The fact that I’ve been living in the US since 2002 is directly related to this involvement with technical communities.

See why I have a cute fox as part of my office decor? Never forget where you come from!

Also, when some youngsters make smartass comments about the mention of FoxPro on my business card, I may just say: “sit down, kid, let me tell you a story…” 😉

, , , ,

Leave a comment