Learning Python and Leading Engineers: A Conversation with Fabrizio Romano

An development manager, longtime developer, and teacher explores Python’s strengths, its real-world use cases, and the mindset shifts required to lead engineering teams.

In this conversation, we speak with Fabrizio Romano—author of Learn Python Programming, Fourth Edition—about what initially drew him to Python, how its design supports clarity and learning, and what developers should understand about its strengths, limitations, and evolving tooling. We also explore how his experience as a software developer shaped his transition into engineering leadership, and why he believes non-technical challenges—like communication, stress, and emotional awareness—are often the real barriers to building great software.

Romano is the development manager of the Sohonet product development team. He has worked as a professional software developer since 1999 and has used Python extensively since 2007. He holds a master’s degree in computer science engineering from the University of Padova and has spoken at EuroPython (Berlin 2014, Bilbao 2015) and ProgSCon 2016, with talks covering topics like test-driven development and Python training at scale. In 2022, he taught Python to software engineers and data science students through a collaboration with Oxford University. Outside of work, he enjoys playing the guitar and teaching Python, mathematics, and meditation.

His 2024 book, Learn Python Programming, Fourth Edition, provides a comprehensive, up-to-date introduction to the language—covering everything from core syntax and data structures to real-world projects involving APIs, automation, and packaging. This edition includes updates for Python 3.9 through 3.12, new content on type hinting and CLI applications, and hands-on examples designed to help readers build confidence and independence as Python developers.

You can watch the full interview below—or read on for the complete transcript (reorganized to enable a smoother reading experience.

---

Getting Started with Python

1. You've spent some years now working with Python. What's your journey with the language been like, and what originally drew you to it?

Fabrizio Romano:
Back in the early 2000s, I was mostly coding in C#, building software for Windows machines. I was also coding in Java, PHP, and ASP.NET for websites. But in my spare time—when I had more of it—I really liked playing on programming challenge websites and doing competitive programming.

On one of these forums where you discuss your solutions, I saw another Italian guy, Marco Berry, who eventually became a friend. He was using Python, and I noticed his solutions were conceptually the same as mine in C#, but much, much shorter. That caught my attention—his code was so concise.

We started talking, and he’s a great enthusiast of Python. Eventually, I decided to give it a try. I started learning just by playing on those websites and solving challenges, which was a great way to get into it. You learn about the various data structures Python offers, since you're doing algorithms—you get to understand what’s fast, what’s not, which data types to use.

That’s when I started considering switching to Python for work. But the original inspiration was really that it looked different and concise. It’s indented, and you don’t use curly braces to define scope—that made it stand out to me.

2. Do you remember the names of any of these websites where you started out just playing around with Python?

Fabrizio Romano:
Yes, one of them is called Project Euler. I think it’s .net. I used to be one of the admins there, creating problems. It’s mostly math-oriented, and the problems look simple—but if you try a brute force algorithm, it would never finish. So it teaches you to think more efficiently.

3. For someone looking to learn Python today, why would you say it's a good choice? What makes Python particularly well-suited for certain types of programming?

Fabrizio Romano:
First of all, the learning curve isn’t steep. Python is practically English—it's very readable and easy to learn the fundamentals. It runs everywhere, so it’s portable. It’s extremely coherent, logical, and elegant.

Guido van Rossum, who designed it, has a degree in math and computer science, and you can really see that in how Python is designed. For example, in other languages, if you want to know how many items are in a collection, you might use .size or .length or .items, depending on the type. In Python, you just use the len() function—it doesn’t matter what kind of collection it is. So it's consistent and intuitive.

Often, even if you don’t know the exact function you need, it’s easy to guess. That really helps—you don’t have to remember 7,000 different exceptions.

It’s also concise. On average, a Python program is about a quarter the size of an equivalent Java or C++ program. There’s an amazing community around the world, and Python has an extensive standard library as well as countless third-party libraries available on PyPI. Most of the time, if you need to do something, someone else has already written a library for it. You can just leverage that instead of reinventing the wheel.

It also integrates well with other languages, so you can extend it. Google, for many years, used Python as glue code to connect components written in other languages—and now it’s even more prominent there. It’s also become the de facto standard for data science.

For me, one of Python’s most beautiful aspects is how it uses protocols like the generator and iterator protocols, the way it does polymorphism, and the flexibility you have with multiple inheritance. There’s a lot of freedom and power in how Python is designed. It’s often called a language for adults because it doesn’t constrain you too much. When I write Java, I sometimes feel claustrophobic—probably because I’m so used to Python.

When Not to Use Python

4. On the flip side, are there any situations where Python isn't a perfect fit—cases where you'd recommend using another language?

Fabrizio Romano:
Sure. The elephant in the room is usually speed. Although to be fair, Python’s speed today is rarely a problem. But if you really need maximum performance, you're usually better off writing in C or using something like Rust.

For example, data science libraries like NumPy and pandas are compiled and use C under the hood. That’s why they’re so fast. But if speed is crucial for your use case, then you might want a compiled language.

That said, in all the years I’ve been using Python, speed has never been an issue for me—probably because I haven’t worked in domains where performance is the top priority.

Another area is mobile app development. Python is still not great for that. You’re probably better off using Swift or something like Dart with Flutter. Java’s been around longer and is more mature in that space.

The language is evolving, though. For example, in Python 3.14, I was reading that they’re going to address some of these limitations—so who knows, maybe in the future we won’t even think of these as limitations anymore.

Evolving Language and Tools

5. Python 3.13 introduced a revamped interactive interpreter and an experimental free-threaded mode. How do you see these impacting day-to-day development, particularly for teams working on large-scale applications?

Fabrizio Romano:
Personally, I almost never use the interactive interpreter because I use Jupyter Notebook. It’s like a better-looking version of the interpreter—you run things in cells, and you don’t deal with the issues the classic Python shell had. For instance, changing a function you’ve already defined used to be a nightmare. That’s now been addressed in the new shell, which is more powerful and user-friendly.

It’s especially helpful when you're not on your local development environment—like if you’re SSH-ed into a server and don’t have the luxury of tools like Jupyter. In those situations, having a shell with multiline editing, coloring, syntax highlighting—that’s a big plus. It just makes your job easier when your toolset is limited.

As for the free-threaded mode, which we touched on earlier—it’s about removing the Global Interpreter Lock (GIL), something that's been discussed forever. There’s potential for performance gains, especially on multi-core systems. But as of Python 3.13, it's still experimental, so we don’t know exactly how it’ll play out.

That said, even with the GIL in place, developers have always had workarounds—like older libraries such as greenlet or eventlet, which let you write code that behaves a bit like multithreaded code. That’s useful when your threads are I/O-bound—like when your app is waiting for an HTTP response. In those moments, you can yield and let the CPU do something else.

Nowadays, we have asyncio, and Python also has a threading library. If you really want to leverage multiple cores, you can use the multiprocessing module—it’s a bit more complex, but it works well. And as I mentioned before, libraries like NumPy or TensorFlow already bypass the GIL internally for performance-critical operations.

So it’s not like Python developers are constantly frustrated by the GIL—but it is a thing. Removing it, if done right, will definitely help.

6. Looking back at all the different versions, what would you say have been the most pivotal moments that transformed your personal workflow?

Fabrizio Romano:
Great question. I think there are two aspects: one is how Python itself evolved, and the other is how all the tools in the Python ecosystem evolved around it.

A few years ago, we moved from Python 2 to Python 3—and those years were painful. You wanted to use Python 3, but then you’d realize that the library you needed hadn’t been ported yet. So you couldn’t.

Thankfully, that’s over now. Python 2 is legacy. It’s rare to find a Python 2 project these days. I haven’t worked with Python 2 in maybe nine or ten years.

Python 3 brought things like full Unicode support. Over time, more features came in—like type annotations, asyncio, data classes, structured pattern matching, and virtual environments built right into the standard library. Libraries like mock were also integrated into the standard library—now it's unittest.mock.

So Python is faster, richer, and more modern now. But I wouldn’t say any one feature was dramatically transformative. They’ve all been meaningful improvements, and I really appreciate all the effort the community and core developers have put into making the language better.

When I think about my day-to-day workflow, though, what’s really transformed things are the tools.

I use an IDE—these days it’s VS Code. I’ve used others before: Komodo, IntelliJ IDEA, NetBeans, Sublime. But VS Code suits me best now.

Then there are the frameworks that rose in the last 10 to 15 years—Django, FastAPI. They became widely adopted and brought strong communities with them.

Jupyter Notebook was another game changer. When I was teaching on behalf of Oxford University, I never used slides. All my materials were in notebooks. If a student said, “I don’t understand,” I could immediately run an example and help them see what’s happening. A slide can’t do that. A notebook is alive—you can play with it.

Testing tools improved too. Libraries like pytest make testing a much more pleasant experience. Tools like Celery made background tasks easier.

And then of course, the whole deployment landscape changed. Ten or fifteen years ago, we were deploying to physical servers. Then we moved to virtual machines. Now it’s all containers—Docker, Kubernetes, Ansible, AWS, Terraform. That was a complete revolution.

For instance, today I’m writing a library that interacts with RabbitMQ. I just spin up a RabbitMQ container—no need to clutter my laptop with installations that might conflict with each other. Containers made everything easier.

Then you have formatting and linting tools like Black, Flake8, Ruff, isort. I’m old enough to still know PEP 8 by heart—it’s the Python Enhancement Proposal that defines the language’s style guide. But these days, I rarely format my code manually. I just hit a shortcut, Black takes care of it. I use other tools to check for unused imports or issues. It saves a ton of time.

There's also a newer tool called UV, written in Rust. It used to be called Puffin. It’s trying to unify the experience around tools like pip, pip-tools, poetry, virtualenv, and twine. UV is blazing fast. I still use it alongside other tools, but it’s great to see a move toward standardizing Python tooling—especially for beginners.

Because one of the biggest hurdles for new developers is setting up their environment: managing different Python versions, setting up virtual environments. That’s hard. And it’s not something you want to cover in Chapter 1 of a beginner’s book.

In Learn Python Programming, we try to guide readers to helpful resources so they can learn that part too. But yes, simplifying setup is one of the most valuable directions Python tooling is heading in—and UV is a big part of that.

The Book: Learn Python Programming

7. Let’s talk about your book now. What kind of problems does Learn Python Programming help readers solve? And what sort of professional would benefit most from it?

Fabrizio Romano:
The book is called Learn Python Programming, so the title already hints that it’s for beginners. Anyone starting their career with Python will probably benefit from reading it.

By the fourth edition, I think we’ve really found a good balance between theory and practice, especially in the later chapters. It took four editions to get there, but I’m happy with where we are now.

We provide all the foundational knowledge a developer needs in the first part of the book. Then, we move into practical projects—like how to build an API, how to build a CLI application, how to package your Python projects.

One of my goals for this book, in every edition, was to write it in a way that would age well. Technology books can become outdated quickly, so I tried to infuse each chapter with lessons about programming and being a developer that aren’t tied exclusively to Python. I’ve included a bit of my personal experience in each chapter.

So even if you’re a seasoned developer, there might still be something interesting in the book for you. I’d say it’s suitable for beginners, but also for mid-level and senior developers.

I get messages every now and then from people on LinkedIn saying, “I’ve been developing for years, but I’m starting with Python and picked up your book—I learned this or that.” That’s always nice to hear.

8. What are the minimum prerequisites for someone to benefit from the book? What should they already know?

Fabrizio Romano:
Ideally, you have some experience with another language, or at least an idea of what programming is about. But even if you haven’t coded before, the book can still be useful—it’ll just take a bit more effort in the beginning.

If you’ve dabbled in another language or understand basic programming concepts, then you’re equipped to start the journey. We begin with a bird’s-eye view of Python—how to install it, then we dive into the basics: data types, functions, objects, and so on. It’s all in there.

The book also offers suggestions on where to go deeper. That’s something I care about a lot. When I mentor people on my team, I try to mentor them in a way that eventually they don’t depend on me, or on a book, or on anything. I help them develop a method they can use to unblock themselves when they get stuck—which happens a lot when you’re a developer. The book tries to teach this kind of mindset too.

We put a lot of effort into helping readers learn that methodology—something they can rely on whenever they need it.

AI in Software Development

9. From a team management perspective, how do you see these tools affecting how developers collaborate and write code?

Fabrizio Romano:
It’s undeniable—that's the direction developers are going. We have to use AI. I think a developer who refuses to embrace AI today is probably going to be obsolete very soon. That’s just the reality of our world.

At Sohonet, in my role, I got everyone on my team set up with GitHub Copilot. I wanted them to start using it, get familiar with it, and understand how to leverage what it can offer.

It might not affect how people collaborate as much, but it definitely changes the way you write code. It can be very helpful. We also have people trying out Cursor. We’re always testing things—there’s the Windsurf editor from the Code team, and the new Try editor from the TikTok company.

I try to stay up to date with what’s new and see if anything’s worth exploring. But at the end of the day, most of my developers use Copilot.

Copilot is especially helpful for menial or repetitive tasks—like hardcoding different test cases. It’s really good at predicting what the next test case might be. It’s also good at giving you a structural starting point for what you’re trying to write. Sometimes it misses, but most of the time it’s helpful.

Even when it's just acting like a better IntelliSense, it’s still useful. When you're editing or refactoring code, it often guesses quite nicely what you're going to do next. So instead of rewriting a line yourself, you just hit Tab and it’s done. For those aspects, I’d definitely recommend it. Everyone should at least try it, see what it can do for them, and then decide.

10. Are there any red flags—areas where developers should be cautious about over-relying on these tools?

Fabrizio Romano:
Yes, absolutely. This is just my opinion, but I think part of the job—especially when I was a full-time software developer—was to smash my brain against a problem now and then. That’s really beneficial for your thinking. It forces you to explore different perspectives, to be creative, to problem-solve, to recall things you’ve learned. It keeps your mental muscles in shape.

Relying too much on AI to unlock you, to figure out the next step, or to tell you how to solve a problem—that’s risky. I still want to “go to the gym” up here. I want to make that effort. I want to learn and know things.

So I think the best approach is for each developer to find the right balance—using AI as a tool, but still keeping their minds fit and challenged. That way, you continue to learn and grow.

Tool Agnosticism and Pragmatism

11. In an earlier conversation, you mentioned that you're not strongly opinionated about tools and languages. How has adopting a more pragmatic, tool-agnostic mindset benefited you and your team?

Fabrizio Romano:
This is a really good question—and something I think is very important. You’ve probably heard the saying: “When the only tool you have is a hammer, everything looks like a nail.” The same applies to programming. If your vocabulary is limited, you can’t fully articulate your ideas.

If I only know Python, or one framework, then whenever a problem arises, I’ll try to make that problem fit the tools I already know. But maybe there’s another tool that’s better suited to solve it. If you're strongly opinionated, you may not even see that tool as an option. You’ll be too focused on making your preferred solution work.

So in my team, I try to help everyone aim for the best idea—not my idea, but the best idea. Usually, the best idea comes out of conversation. And conversations involve different people, different perspectives, different experiences. One person might prefer FastAPI, another might say Flask, another Django. We talk about it, weigh the options, and go from there.

Developers who want to be great developers should steer clear of having too many fixed opinions. Strong opinions cloud your judgment and give you tunnel vision.

Non-Technical Challenges in Software Teams

12. You have said in the past that technical challenges are rarely the biggest problem in software development. What did you mean by that? What are some of the more critical non-technical challenges that teams face today?

Fabrizio Romano:
That’s a really good question.

At Sohonet, we work with cutting-edge technology for the media industry. Sometimes we’re building things no one else is doing, so yes—there are technical difficulties. But that’s a small part of the job. The rest of the product still has a front end, a back end, a platform or API, and it stores data. Those aren’t particularly hard to build. They require skill, sure, but a senior developer won’t be overwhelmed by something like “how do I make a request to an API?” We know how to do those things.

Most of what we do is fairly routine. You’re not constantly solving deep technical puzzles. The real challenges lie in everything around the code: working in a team, following a process, collaborating with departments that don’t share your workflow, or aligning with people who don’t fully understand what you're doing.

For example, one big challenge is process alignment. Say you have 11 people on a team—and not all of them share the same understanding of how your process works. That creates friction. You do something a certain way, someone else doesn’t get why, and suddenly they’re asking, “Why is Fab doing that?” Maybe I’ve disrupted their flow. Now we have to have a conversation. Whose way wins—mine or theirs?

That’s why process is so important. Everyone needs to be on the same page, so my actions are predictable to others. We shouldn’t have to talk about why I moved a task from one column to another—we should all just know, because it’s our shared process.

Some teams solve this by having a very strict process—lots of rules and constraints. That might work for them. But not for my team. I’ve set up a flexible process that’s based on values and guidelines, not hard rules.

When your values are things like openness, focus, commitment, respect, and courage—then whatever decision you make, you can measure it against those values. Is it aligned with our principles?

It’s the same with certain spiritual disciplines. Take the Japanese lineage of the Reiki system—it’s based on five principles: don’t be angry, don’t worry, be grateful, be compassionate, and so on. Whenever you do something, you can ask: “Will this make me more angry or more grateful? Is it compassionate?” And from there, you judge whether the action is right.

At work, I see it similarly. We use Agile, so we value individuals and interactions over processes and tools. That means instead of a long pull request thread with 15 comments, you just sit down and talk. When you type things out, you lose tone, facial expression, and body language. A quick conversation can resolve things much faster and with less misunderstanding.

So our process is flexible, but it requires everyone to stay mentally engaged. You have to think about how you work. Just like with AI—I don’t want people to become robots following rigid steps. I want them to stay creative, to own their work, to think independently, and still be predictable to others.

That’s just one non-technical challenge. Another big one is stress.

We’re all under pressure to deliver—often for yesterday. That’s just how things are. It’s not unique to Sohonet; it’s everywhere. And stress creates negative emotions: frustration, anger, anxiety.

I’m lucky—my team is great. Eleven people who really get along. But sometimes, interactions with other departments cause friction. Maybe they don’t understand the way we work. I’ve seen this at other companies too—it’s not uncommon.

So I need to tend to that. I have to pay attention. In meetings, I watch body language. I listen to tone of voice. I notice how people type on Slack, how quickly they respond, how they phrase things. If something feels off, I talk to the person and try to understand what’s going on.

Sometimes that means helping them manage stress directly. For example, I’ve had sessions with about half my team where I’ve taught them simple meditation techniques—just enough so they can re-center themselves when something throws them off.

We also do a lot of one-on-ones. I try to teach the basics of emotional intelligence—how to cope with difficult emotions. Because when you're upset, frustrated, or angry—those are all different shades of the same thing—it triggers a chemical change in your body. Your sympathetic nervous system kicks in. That’s your fight-or-flight response.

And that means tunnel vision. Your body starts consuming more than it needs. Natural functions slow down. You’re in emergency mode, and if you keep stimulating that state without learning how to manage it, it becomes a health risk.

So we work on identifying the root cause of stress. Usually, it’s not “that guy did something I don’t like.” The deeper issue is: “I’m not willing to accept that he did that.”

The tricky part is that most people confuse acceptance with passivity. If I say, “accept this situation,” it doesn’t mean you put up with it and do nothing. It means: recognize that this is reality. And once you’re calm and grounded in that reality, your mind is in the best position to find a solution.

This is something you learn in martial arts too. If you want to react quickly and effectively, you need to be fully relaxed. A relaxed mind is a creative mind. It can solve problems. It also keeps you healthier.

So that’s a big part of what I do—mentoring my team on how to stay calm and centered, even when things are tough. We acknowledge problems and try to solve them while keeping our minds clear and steady.

Becoming a Development Manager

13. You’ve transitioned into a development manager position over the past few years. What has that shift been like for you? What’s been the biggest challenge in leading developers?

Fabrizio Romano:
I’ve been a developer for a long, long time. I started coding when I was 16. But at some point—for me, at least—writing code wasn’t giving me the same satisfaction it used to. I found myself more drawn to helping people—developing people, not just code.

Of course, I still love writing code. But I get more enthusiastic about helping others grow. For maybe the past 11 years, I’ve been in some kind of leadership role—leading teams, being a line manager. So when I joined Sohonet, I came in as a team lead, and then three years ago I moved into the development manager role. It felt completely natural.

The skills we learn as developers aren’t confined to software. They transfer to life. Like: approach a problem from different angles, break it down into smaller parts, choose the right tool for the job. Those aren’t just programming lessons—they’re life lessons.

So for me, that transition into management came naturally. And a big reason for that goes back to an experience I had teaching math maybe 25 or 30 years ago.

To this day, I think it’s the memory I cherish most from being a teacher.

There was a little girl—maybe 11 or 12 years old—who couldn’t understand how to work with fractions. Everyone had tried to teach her: her dad, her mom, her teacher, a family friend who knew math. But they all came to the same conclusion—that she just wasn’t smart enough to understand mathematics.

One day, her mother spoke with my neighbor, who happened to know that I was giving private math lessons. Eventually, the girl came to my house for a session. I was trying to help her add 1/3 and 1/5. Of course, you have to find the least common denominator—in this case, 15. But she didn’t grasp why we were doing that.

She knew the textbook by heart. She had memorized the rules. But she didn’t make the connection—why we do those things. So I tried a different approach.

I asked her, “What is one banana plus one banana?” She said, “Two bananas.” Then I asked, “What’s one apple plus one apple?” She said, “Two apples.” Then I asked, “What’s one banana plus one apple?” She paused. It didn’t make sense to her at first. But then she said, “Two fruits.” And I said, “Exactly.”

That’s what we do with fractions. One-third and one-fifth are like bananas and apples—you can’t add them directly. You have to find a different way to represent them so they can be added up. For us, that means finding a common denominator.

Her face changed completely—she said, “I understand.” And I think, in that moment, she also realized, “I’m not stupid. I just needed someone to explain it differently.”

For me, that’s the gift. As a teacher, you don’t just insist on your way of explaining things. If one road doesn’t work, you find another. You keep trying until you discover a path that works for that particular person’s mind.

That’s something I’ve carried with me ever since. And I try to apply that same approach with my team at Sohonet. It comes very naturally to me, and I’m very passionate about it.

14. If someone wants to become a development manager like you, what kind of skills should they start building early in their career to make that transition?

Fabrizio Romano:
That’s a really good question. Have you ever heard the saying, “People don’t leave companies—they leave managers”?

For many developers, the natural progression seems to be moving into a lead or manager role. But not everyone is suited for that. Some people are amazing developers, but they don’t have the people skills—or the passion—for managing others.

I’ve seen that a lot. I’ve also been lucky to work with some really good managers, so I’ve seen both sides.

The thing is, in our industry, we often promote people into management roles just because they’re technically strong. But managing people is a completely different skill set. If you’re someone who’s drawn to logic, machines, and technical problems—and you’re not interested in helping people grow—then you probably shouldn’t go down the management path.

For me, it’s not just about acquiring a skill set, although training can help. You can train as a coach, mentor, teacher. But underneath all of that, you need something foundational—a genuine desire to care for people.

That’s what this job is really about: doing your best to help the people you manage become healthier, happier, more skilled professionals—and hopefully better human beings too. Because a lot of these skills are transferable to life.

If you’re only doing it because it’s your next step, or because someone handed you the role, it can be tough. People aren’t logical like machines. Managing them requires effort, empathy, and patience.

You have to listen. You have to figure out how each person communicates, what motivates them, what makes them tick. Everyone is unique. That’s the real work. And you have to want to do it.

For me, helping people grow is a worthwhile use of my time. More than career progression, more than money or recognition, I care about planting those seeds—helping someone move forward in their life and career. If that’s something that excites you, then yes, becoming a development manager is a great option.

And I do think it’s important to have a solid foundation in software development before stepping into this role. If you’ve written code, if you’ve been under deadline pressure, if you’ve lost a whole afternoon going down a rabbit hole because your ego wouldn’t let you ask for help—then you’ll understand what the people you manage are going through.

That empathy makes you more effective as a manager.

But no, I don’t think it’s a natural progression for everyone. Some people just aren’t interested in that kind of career—and that’s completely fine.

15. What advice would you give someone navigating their early career and figuring out what kind of developer they want to be?

For me, it happened quite naturally. When I started using Python as my main language, I used it for everything—websites, apps, experiments with different frameworks. I just loved writing Python code.

Back in 2013 or 2014, I was in Manila teaching Python and a bit of data science with pandas. At the time, Jupyter Notebook was still called IPython Notebook. I was using that instead of slides—it made it easier to show code live and help people understand what was happening. I was working for a social media advertising company, and we had a department of analysts there. I went for two weeks to train them.

So curiosity drove me. I wanted to explore all the aspects of the language.

If someone’s starting out today, they’ll probably need to specialize. Computer science and software engineering are such vast fields now—it’s hard to know everything. So I’d recommend you take a step back and assess your personal interests. What excites you most?

Do you love websites? Are you a front-end person? A back-end person? Do you enjoy DevOps—managing the infrastructure behind a product rather than building the product itself?

It’s important to appreciate the different domains and figure out what pulls you in. That’s probably your best path forward.

To do that, you need a holistic understanding of all the disciplines involved in software engineering. Explore different areas—otherwise, you might think you’re choosing from the only two options you know, when actually there are ten, and the right one for you is in the other eight.

Of course, we also need to be pragmatic. Look at the market and see what job opportunities are available. You still have to pay rent, buy a house. But at the end of the day, you want your job to feel like something you’re passionate about—not just a paycheck.

Find where your strengths lie and where you see yourself succeeding. Learn as much as you can. Contribute to open source. Join Discord communities. Check GitHub projects. It’s so easy to find information today—people starting now are very lucky. When I started, we had libraries. With actual books.

We didn’t use ChatGPT to do research.

There are so many fields—web development, data science, machine learning, AI, automation, DevOps, game development. Python is even used in game development now, which is super interesting.

---

To dive deeper into the ideas discussed in this conversation—including Python’s core syntax, its application in scripting, automation, and API development, and how to build real-world projects with modern tooling—check out Learn Python Programming, Fourth Edition by Fabrizio Romano and Heinrich Kruger, available from Packt.

This comprehensive guide has been fully updated for Python 3.9 through 3.12 and includes new chapters on type hinting, command-line application development, and updated examples reflecting current best practices in Python web development. Whether you're learning Python for the first time or looking to deepen your fluency with current features and workflows, this edition offers a clear, practical path to becoming a confident and independent Python developer.

Here is what some readers have said: