I’ve been working with Python for nearly 10 years, including college. I’m 4 years into my career writing, deploying, and maintaining code for NOAA’s National Weather Service mission-critical satellite data processing applications.

During these 10 years, I’ve hit a lot of walls, had a lot of breakthroughs, lots of scratching my head wondering why I wrote code a certain way, and lots of growth. There’s been times where I’ve wanted to throw my computer from the roof of the building (still do, but for a different reason).

I wanted to share a few things that I’ve learned over the years that are both Python-specific, but also in general with software engineering.

The quicker you see that Python as a toolkit and not a language that gives you the ability to write applications is the moment that software engineering, as a whole, becomes more approachable.

If you look at other languages, you have similar functionality to be able to express logic:

At the same time, other languages offer things Python doesn’t:

I’m not saying Python is a bad language, because it isn’t. It’s an extremely versatile language that attracts both beginners and professionals for various reasons. It’s a language that allows you to write one-off scripts or build distributed systems at scale.

But understanding that programming languages, in general, boils down to the fact that they’re toolkits that allows you to craft solutions to solve problems.

This is true especially with the adoption and integration of language models in modern applications. Every day it seems like there’s something new: Python releases, package updates, developer tool launches; you name it, someone’s probably created it yesterday.

Newsletters are a fantastic way to get the latest and greatest news from the industry. I’m not trying to plug Python Snacks because generally I don’t send out news, but there’s some really good news-based newsletters out there - subscribe to some, see if you like them, and let them do the research on your behalf.

It’ll take some time to figure out which ones you like/don’t like, but once you settle on one or two you’ll be ahead of like 90% of software engineers.

I’m a supporter of leveraging language models (ChatGPT, Claude, etc) for both coding and learning, but know where to draw the line.

When you’re going back and forth with the language model and it’s structuring logic and explaining the concept so well that you don’t have to deeply think about it, you’re “borrowing” the knowledge.

A good way to test to see if you’ve borrowed the knowledge or not is by eliminating the language model entirely. Can you explain the why rather than the how? Can you re-build it from scratch? Would you be comfortable with a coworker drilling you on the topic because want to pick your brain?

Messing up is part of the learning process. We’re human - we’re not perfect by any means. But part of growth journey on becoming a better software engineer is messing up.

In the context of software, maybe you make an architectural decision that ends up as overkill for the application. When you’re able to take a step back and understand why it’s not working, you’ll be able to continue iterating, simplifying the application, and most importantly, avoid making the same mistake twice.

Keep in mind, this extends well outside of software - this applies to a lot of day-to-day life like relationships, health and fitness, and career.

I was recently talking to a senior manager who manages 6 teams at their organization, and I had asked him “what behaviors do you see in your highest-performing engineers?”.

He had multiple answers to this: truly understanding customer usage, taking initiative on tasks, and influencing others. These were answers I fully anticipated with this kind of question, but one answer really stuck out to me:

“They let go of the past.”

What he was referring to was taking a technology you’re comfortable with or certain leadership skills and not being afraid of chucking it out the window to adopt a new technology or skill.

I never thought of this being a skill to begin with. Those who are willing to pick up something new and allowing themselves to let go will be able to move further in their career because, in part, they’re not tying their identity to a single tool. This alone compounds over the years and gets noticed by management.

If you’ve made it this far, I’m very curious to hear about things you’ve learned while working with software, whether if you’re new to Python or are a seasoned engineer. Reply to this email and tell me one thing you’ve learned in your career that you wish you told yourself when you were younger.

I read all emails and am excited to respond to yours!

Happy coding!

Want even more Python-related content that’s useful? Here’s 3 reasons why you should subscribe the Python Snacks newsletter:

You can unsubscribe at any time.

Do you have a wealth of knowledge and insights to share with the world? Starting your own newsletter or blog is an excellent way to establish yourself as an authority in your field, connect with a like-minded community, and open up new opportunities.

If TikTok, Twitter, Facebook, or other social media platforms were to get banned, you’d lose all your followers. This is why you should start a newsletter: you own your audience.

» Use this link to get 20% off for 3 months your newsletter! «

This article may contain affiliate links. Affiliate links come at no cost to you and support the costs of this blog. Should you purchase a product/service from an affiliate link, it will come at no additional cost to you.