For my presentation “Visual Studio Code: One Tool to Rule Them All?” I created two fictional characters: Ryan and Eric. Both are software developers, but they take very different approaches to their work.

A colleague of mine suggested I write a blog post to introduce them properly. Everyone who heard my story about them immediately recognized these two archetypes. Even presenters who spoke after my session started using Ryan and Eric in their talks. So let’s give them the spotlight they deserve, right?

Meet Ryan

Have you met Ryan? Ryan is a young developer, fresh out of college. He has a couple of core qualities: he learns fast, is curious and loves new technologies. Ryan probably has more unfinished projects on his laptop than finished ones.

🤖 The images of Ryan and Eric are AI-generated using Sora, by providing my own image as input and describing the character traits.

Ryan - fast, experimental, shortcut-obsessed

Ryan - fast, experimental, shortcut-obsessed

Ryan is the kind of person who uses hip IDEs like Visual Studio Code, because it is lightweight and fast. Ideally Ryan would like to use his phone to code on the go, while watching his favorite series on Netflix.

“Move fast and fix things later.” - Ryan

When you have a Ryan on your team, you will notice that he will run before thinking his actions through. He will push fast to production, only to find out later that something is broken. But hey, at least he tried, right? And if he is just as fast to fix it again, everything is fine.

Meet Eric

Eric is a seasoned developer with years of experience. He is pragmatic, values stability and prefers to stick to tried-and-true tools. Eric will start Notepad++ to quickly format his XML or JSON or compare files. He has been using and running projects in Visual Studio for years. He jokes that you cannot write any good code in Visual Studio Code, because where is the “Play” button to start the project? Not to mention how do you debug without it?

Eric - stable, cautious, prefers proven tools

Eric - stable, cautious, prefers proven tools

When you have an Eric on your team, you will notice that he will take his time to think things through. He will criticize decisions beforehand knowing that changing things later will be costly. Why change when you have worked this way for years?

“If it ain’t broke, don’t fix it.” - Eric

A conversation between Ryan and Eric

If Ryan and Eric were to have a conversation, it might go something like this:

Having multiple PR’s open

Context: Eric leans back.

Eric
We’re going to make some rules. Ready?
Ryan
Is “no” an acceptable answer?
Eric
No.
Rule 1: No more than two open PRs at a time.
Ryan
What if I have three great ideas?
Eric
Write them down. Ship two. The third can wait.

Writing an ADR

Context: A new framework is being discussed. Ryan is already prototyping.

Eric
Before we change the framework, we write an ADR.
Ryan
Can’t we just try it first and see what happens?
Eric
We can try it. But we still write an ADR.
Ryan
What do you even want in there? “Ryan had a feeling”?
Eric
No.
ADR Rule 1: Capture the problem, the options, and why we picked this one.
Ryan
That sounds like homework.
Eric
It’s future-you cheating on future-homework. You won’t remember why you did this in six months.
Ryan
Fine. I’ll write the ADR. Short one.
Eric
Short is okay. Undocumented is not.

Setting up SQL Server

Context: Eric is setting up his new development machine and needs SQL Server.

Eric
I’m downloading the SQL Server installer. This should take about an hour to set up properly.
Ryan
An hour? Just run docker run -d -p 1433:1433 mcr.microsoft.com/mssql/server
Eric
I don’t trust containers for database work. What if something goes wrong?
Ryan
types command Done. SQL Server is running. Took 30 seconds.
Eric
Wait, my installer failed. Compatibility issues with my Windows version.
Ryan
That’s why I use containers. Same environment everywhere.
Eric
Fine. But what happens when I need to upgrade? Or backup? Or configure security?
Ryan
Docker Compose file. Version control your entire database setup.
Ryan
Plus, you can automate the whole thing in your CI/CD pipeline. Database provisioning becomes part of your deployment process.
Eric
sighs Show me this Docker thing. But I’m keeping the installer just in case.

Ryan and Eric

These two fictional characters represent two very different behavior patterns in software development teams. Ryan pushes for speed and experimentation; Eric optimizes for stability and predictability. Most of us have both inside us, and the trick is to know when to lean into which.

Let’s introduce an example I myself encounter often: My colleague acts like Eric. He locks his computer using Ctrl+Alt+Del and selects ‘Lock’ from the menu. I think he should use Ryan to optimize his workflow. I, on the other hand, use Windows+L to lock my computer instantly. The same pattern shows up in formatting code, switching screens, or running builds: you can click your way through, or you can invest in shortcuts and automation. Ryan would use Windows+P to extend his screen while Eric would right click on his desktop and select ‘Display settings’ to do the same.

The tension between Ryan and Eric is useful. Ryan pulls the team toward new tools and faster workflows; Eric stops us from breaking production every week. Healthy teams make space for both.

Conclusion and discussion

Ryan and Eric are two fictional characters that represent two extremely different behavior patterns in software development teams. You can act like Ryan or Eric, but you should use both to balance innovation and stability. I hope Ryan and Eric will return in future blog posts as well. If you want to refer to them, you are welcome to do so. Please link back to this post.

Let’s set the mode accordingly:

1
var mode = DeadlineIsToday ? Ryan : Eric;

What about you? Are you more like Ryan or Eric? Or do you have another archetype in mind? Let me know in the comments!

Further reading

I wrote an Ryan-like article before read it here: Mart’s Cheatsheet