I talked with Annie Sexton about developer education, AI, UX, and what it means to keep growing as an engineer when the shape of the job is changing so quickly.
Annie is a developer educator at ngrok, and before that she made a lot of the technical videos people know from Fly.io. What I appreciate about her work is that she is not just explaining tools. She is paying attention to how people learn, what makes them curious, and where they get stuck.
That matters a lot right now. AI can help us produce code faster, but it does not automatically make us more curious, more thoughtful, or more aware of the person using what we build.
Trick people into learning
One of Annie's phrases that stuck with me was that her goal is to "trick people into learning things."
That sounds sneaky, but it is really about care. If you want to teach something complex, you cannot simply dump all the information on someone and hope they absorb it. You need to create curiosity. You need to pace the story. You need to show why the topic matters before asking someone to follow you into the details.
That is product thinking applied to education. The learner has a job to be done. They have a current level of understanding, a set of assumptions, and a limited amount of attention. Good education respects all of that.
Curiosity keeps you from becoming a button pusher
We also talked about AI agents and the way they have changed the feeling of software development.
Annie was honest about something I think a lot of engineers feel: coding with agents can be powerful and useful, but it can also make the old hands-on joy of problem solving feel different. We are all being pushed up a level. More of the work is product, architecture, direction, review, and taste.
That makes curiosity even more important. If you ask Claude what to do and then accept the answer without caring how or why it works, you are not really engineering. You are pushing buttons.
The durable skill is not memorizing every low-level detail forever. It is knowing how to ask better questions, notice when something feels off, and keep pulling on the thread until you understand the system well enough to make good decisions.
UX is harder to ignore now
Annie also made a point I loved: there is less excuse than ever to ignore UX.
When implementation gets cheaper, the differentiator is not merely the tech stack. It is the experience. What should the product do? How should the flow feel? Where are people confused? What does the user become capable of because your product exists?
That is where her homework landed. Read Badass: Making Users Awesome, and then practice looking closely at a product you almost used but did not. Go through the flow again and write down every specific thing that got in your way.
"It was awkward" is not useful enough. What was awkward? Was the error message hidden? Was the field label unclear? Did the custom select break your expectations? Did your eyes glaze over because two pieces of information looked duplicated?
That kind of noticing is a product engineering muscle. And like most muscles, it gets stronger when you practice deliberately.
