How often have people asked what language or technology you work in?
When you answer Python, they get a little confused and ask,
what can you actually build in Python? What type of apps?
Implication being that Python is just a notch above Bash scripts,
and that real things aren't built with Python, but rather with Java, C#, Objective-C, and so on.
Mahmoud Hashemi and I might be able to help put some real evidence behind your responses.
On episode 54, Talk Python to Me, I talk with Mahmoud about his new online course
he wrote for O'Reilly called Enterprise Software in Python.
You'll hear many real-world examples from his experience inside PayPal,
and many more throughout the industry.
This is episode 54 of Talk Python to Me, recorded April 4th, 2016.
It's about design patterns. Anyone can get the job done. It's the execution that matters.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,
and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm at,
mkennedy. Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by SnapCI and Hired. Thank them for supporting the show on Twitter via
at Snap underscore CI and at Hired underscore HQ.
The news this week is all about online courses. You'll want to be sure that you're a friend of the show
because we have two cool giveaways. Just drop by talkpython.fm and click on Friends of the Show
in the navbar to become eligible.
Mahmoud is giving away a copy of his online course which normally sells for $149.
I'll pick one lucky friend of the show later this week to receive a copy.
You can find the links to his course in the show notes for this episode.
Speaking of online courses, my Python jumpstart by building 10 apps is out and people are really loving it.
I thought I'd join Mahmoud and give away a copy or two this week as well.
You can see the details of my course at talkpython.fm/course.
Now let's talk about Enterprise Python.
Mahmoud, welcome to the show. Welcome back to the show.
It's great to be back.
Yeah, I really enjoyed the episodes we've done before and this is actually your third appearance.
You were on as the main guest in episode four where we talked about the myth of Enterprise Python
which was based on an article.
That was sort of when this was kicking all off. That's right.
Yeah, the 10 myths of Enterprise Python blog posts.
That's right. This is like the germ or the seed that generated this course that we're going to talk about, right?
It's been a wild and crazy ride. That's right.
I bet it has.
And then you gave some cool inside information on how you guys think about hiring and junior engineers back in episode 41.
And this is going to be episode 54.
So I'm instituting a new rule.
You're not allowed to come back on the show unless there's a four in the number.
That seems like a fine rule to me.
I can like, so at least 10 more episodes.
I can probably drum up something in that time.
Perfect, perfect.
All right, so people heard your story back on show four.
So we won't go sort of through how you got back into programming, even though that's the question I often ask people.
Instead, I'd like to hear how you got into enterprise programming.
And what was the step where you went from just, I'm doing programming, I'm doing Python,
to I'm now working at a company that has more employees than some small towns?
You know, that's actually something that recently I was forced to sort of ponder a lot on, you know,
like just had some really deep shower thoughts, as it were.
And so, yeah, I sort of fell into it, as I'm sure so many do.
Like you get an internship at a company and they assign you kind of, you know,
maybe the worst stuff that you can do within three months.
Like they want you to do something, but they don't want it to be like, you know, super, super glamorous.
They give that to their star engineers who already have full-time positions.
So, you know, as an intern, I was doing some really niche log analysis stuff.
And so, you know, I actually define enterprise software in my course.
And, you know, one of the main things that makes software enterprise isn't that it's high performance or something like that.
It's actually that it's very niche, you know, has a very constrained user base that's interested in certain things.
And so, you know, I just started out doing really niche applications because I love software introspectability so much.
You know, if you tell me, hey, go analyze these logs, go find out what's slowing this application down,
that's something that even now I can't really resist.
Yeah, that's really cool.
Those types of enterprise apps are pretty different.
I spent a long time working at a company, I guess probably six, seven years, one of my first jobs,
working at a company where I think there was maybe a maximum of 25 employees.
And we were writing internal software to do all sorts of cool stuff at this place where we did eye tracking.
And we'd write custom apps to sort of, you know, collect various specific studies that the scientists want to do with eye tracking and things like that.
And I think we wrote some really powerful and beautiful software, but it was for like 10 people.
You know, and so that's, it's not sort of the scalable sort of advertisement driven concept of like Pinterest and hockey curve growth and all that.
But it's the people who use that software, like their jobs, like the whole company depends on that software.
So it's pretty interesting to live in that space.
They don't really have a, they don't really have a choice, you know.
So like, I mean, that's kind of what makes a lot of things enterprise.
That's sort of the stuff that makes a lot of enterprise stuff kind of bad.
But we can probably go into that later.
Yeah.
The whole battleship gray, I don't need to know design, just because I'm a programmer, that kind of thing.
Yeah, that sort of thing.
You know, there's no, there's no alternative.
So you don't spend any time actually making stuff good.
That's one approach some people take.
You know, I'm not for that approach personally.
Yeah.
I think that used to fly, especially in the 90s when you write enterprise software, it could be seriously unusable.
But ever since the iPhone came out and people have gotten used to really beautiful, nice computing experiences,
they're like, why do I have to go to work and have this horrible computing experience, right?
That has, that has actually left its mark.
I agree.
I mean, there are pros to that and there are cons to that.
Now I see a lot of stuff getting polished a whole lot, but the underlying quality is still lacking.
So, you know, there are lots of ways to compromise quality.
And enterprise will always find a new way.
That's right.
Yeah.
So, you know, I have this, like, you know, hopefully we'll get to cover a little bit about, you know, how to sort of mitigate that with the power of Python.
Yeah, absolutely.
So, one concept I'd kind of like to introduce near the beginning before we get into the course is just that when you think of enterprise developers,
and you can maybe put Python to the side for just a moment and just say, like, across all technologies,
a lot of times there absolutely are super smart people writing amazing software, but maybe they're just going to work and they're just doing their job and they're not going and speaking at the conferences and they're not on Twitter constantly blogging and tweeting about, you know, whatever it is that they're doing.
They just go do their job and they go away.
And so I think that we probably underestimate the impact and the number of people that kind of live in this space because they're not necessarily as vocal.
Yeah.
And, I mean, I don't know.
I'm not really for the cult of personality, like, you know, rock star coder type stuff.
I think that, like, every developer has a rock star within them.
I know because, I mean, you know, they talk about 10x programmers, like, and some people say, hey, they don't exist.
And other people say, hey, they do exist.
And it's, like, a little bit like this big foot of developers.
And I don't know why it's so controversial, why it has to be like that.
Everyone has within them, like, a 10x developer.
If you're struck with the right idea, you know, you will work tirelessly and learn so much within the span of just a couple of weeks.
And, you know, the rest of the time, like you said, you have a normal work-life balance and you have a day job and that's totally fine.
But 10x developers do exist and they're within all of us.
That's what I choose to believe.
I totally agree with you.
I think if you were, like you said, struck with inspiration, you can do almost superhuman type of work.
So focused, so effective.
And on one hand, it'd be cool if we could always be that focused and effective.
But, you know, that's how inspiration works, right?
If you both have the time and the energy and the idea all coming together, you could be that 10x developer for that project or whatever.
Right.
I mean, you won't believe this, you know, looking at my GitHub or my Twitter or whatever, right?
But I do think that there is much more to life than just code.
So, yeah.
Yeah, same here.
But I try to keep it basically to technology on Twitter as well.
So it's hard to tell.
So let's talk about your course.
So it's called Enterprise Software with Python, right?
And you're distributing this through O'Reilly.
Is that right?
That's right.
So I think that basically because of the 10 minutes of Enterprise Python blog post, they actually contacted me a little bit before we did episode number four.
And they're like, hey, would you like to expand upon this and do a project on Enterprise Software?
And, you know, I really hemmed and hawed.
I'm sort of more of an engineer.
I'm a builder, you know.
And I have a lot of reservations around education.
Like I'm a firm believer in education, but it's very time consuming.
My dad, you know, he's a professor of virology, right?
I have really high standards.
And I know that if I get involved with something like this, I'm going to go all out.
And so I hemmed and I hawed.
But then I finally, like, you know, decided to make it happen in August of last year.
I started working on it.
And I chose the video format because of how successful I saw that it was inside the company here.
And so it's a video course.
In preparation for it, I actually taught over a dozen internal, like, training courses at PayPal.
And just covering all sorts of different topics, sort of honing in on the right, the best explanations for various topics in Enterprise Software.
And I ended up with this course that is about, I would say, like, it's half and half.
It's like half, you know, Enterprise Software, you know, and half, like, how to do it in Python.
Python just works really well as an example language.
And, you know, the ecosystem is very full-bodied.
So, you know, it really fit well.
But it has whole segments of it that are not at all Python significant.
It's almost like a case study of Enterprise Software.
But from, you know, choosing Python as a specific language.
That's really cool.
So one of the things that you ask in this class, and I guess your class is, like, in your blog post,
it was sort of a, people think these things are inappropriate in Python.
Let me show you all the ways, the 10 ways, where they've got some false conception, right?
Python is just a scripting language or something silly like this that gets in their way.
But this is more like, well, we'll talk about those, but let's actually study the whole thing in a more concrete way, right?
So one of the questions you sort of started out with, which I thought was interesting, is you said,
is Python suitable for the enterprise?
And when should you write Python code?
Right.
And that is, I mean, it's a valid question, right?
You're at a company, and, you know, as an engineer, Python, it's a language of choice, you know,
which means that, like, engineers are going to choose it.
Your boss isn't going to choose it for you.
Usually, like, C-level type people do not choose Python for their company.
And that's kind of something I'm trying to reverse here.
Python has been shown to be, like, tremendously successful for many very large-scale, you know, companies.
YouTube, Yelp, Dropbox, and, you know, I believe CERN uses it.
It's really all over the place.
So, I mean, it shouldn't be as controversial as it is.
And so I go down the list of when you, you know, when we've actually seen it used.
I'm not saying that, hey, here's where I think you should use it.
I'm like, no, here is where it has been used successfully.
And then I give a couple of areas where I don't think it's as common, you know, for enterprise development,
such as you don't really see it that often in web front end.
You know, that's pretty much all JavaScript and JavaScript derived.
You know, there's PyJamas.
That's not really quite there.
There's Brython.
And, like, for browser Python, that's not really quite there yet.
But, yeah, so, but, yeah,
Python is absolutely suitable for the enterprise.
And I don't think that it's just generic organizations that don't understand this.
Even when we go to conferences and speak with other Python developers,
they're kind of appalled to hear that we are, like, you know,
shooting for 100 microsecond response times.
You know, 100, 200 microsecond response times.
You know, as served from CPython.
You know, this isn't even PyPy.
And so, yeah, I mean, we can hit those enterprise performance type numbers very consistently with some good engineering.
And I think that this course lays the groundwork for making that sort of software possible in Python.
I totally agree.
I think, you know, you brought up CERN, right?
I talked to Kyle Kranmer.
Right.
I listened to that episode.
That was so excellent.
And I'm just thinking if Python is appropriate to help collect the data from the Large Hadron Collider
and win the Nobel Prize for fighting the Higgs boson,
it's probably not too bad to, like, monitor your log files or something.
The people think they have these amazing, amazing requirements,
but a lot of times there's just a bunch of little tools you got to build.
And, you know, you don't need, I don't know, some super specialized thing.
Yeah, since the last episode, the main project I've been working on is a sort of a key distribution system
for securing sensitive data inside of PayPal.
You know, trust and security is PayPal's, you know, number one, like, selling point.
That's what the brand is associated with.
It is the safest way to pay online, that sort of thing.
And to keep it that way, you know, we have to be innovating in that space.
And so that's basically as low-level a system as you will find inside of PayPal.
Like, everything depends on that.
And, you know, we expect billions of requests per day,
three, two, three billion requests per day.
We're already, like, seeing the adoption is happening,
but we've seen days of 500 million requests per day.
And, you know, the, you know, average median time that we're shooting for
is less than two milliseconds for the response.
So it's not just for logs or whatever.
It is for these critical systems.
And it's the main reason that we chose Python was because of its consistency,
our ability to measure how the software is performing,
and because we can maintain it with a very small team.
The security team is not a huge team at PayPal.
Application security, I should say.
InfoSec, that's a much larger team.
But application security is a much smaller team.
Wow.
That's really amazing that that app written in Python is at the foundation of all those things.
Like, billions of requests per day is,
that's a number that not so many people deal with.
That's really, really cool.
And that's written in Python.
Is it like an HTTP service, or what's the story there?
Oh, yeah.
So that's one of the great things.
So because of Python's easy, like, I mean, it's not just Python.
You know, we have a framework that we've built on top of that.
Most of that is open sourced on PayPal's GitHub.
It's called support.
It's sort of a reference framework.
So using a framework, you know, based on that, we have several protocols that we support.
HTTP is, like, if you're talking HTTP 1.1, 1.0, is kind of slow to parse.
So we go for lower overhead protocols.
We're fans of NetString.
That's a classic.
You know, it even has sort of roots in the crypto community,
because DJB, Daniel J. Bernstein, you know, defined it so many years ago.
It has a Wikipedia page.
It's extremely simple.
NetString.
And then we have something even lower level than that,
which is similar to NetString, but it's called TLV, tag length value.
And so you do have to go for, like, lower level protocols there.
But because it's Python, you know, we can maintain an HTTP interface
for development purposes so that people can mock things out.
without having to worry about the details of TLV.
I guess if you're going to get two millisecond response time,
you're more or less down raw sockets almost, right?
Yeah, yeah.
No, we don't shy away from raw sockets.
We have a little buffered socket that we've written on top of that.
But when you want to hit sub-millisecond, deep sub-millisecond times,
then you do have to basically be counting the, you know,
bytecode instructions that you're going to be, like, executing.
So every line does count.
You know, every line does have its cost.
But Python makes it easy to gauge that cost.
And because you can get your features done in time,
you can actually start down that performance path much sooner than other stacks.
And that's the big selling point for us.
Yeah, you can do the testing and experiment and find the right answer
probably before the first prototype would be even finished in C++, right?
Oh, yeah.
I mean, in fact, we have had literal, I mean, I wouldn't call them competitions, right?
We're inside a company.
We're all one team, right?
But, like, we've had cases where that exact stuff was happening.
Like, you know, we were done months ahead of time
and already, like, iterating on our performance.
By the time C++ came around with their stuff,
they couldn't even get within an order of magnitude of our scalability.
Wow, that's awesome.
So let's take it back to the beginning for a moment.
You talked about your first enterprise app,
and that was kind of that log file monitoring thing, I think, right?
Right, right.
And you said there was a couple of lessons you learned from it,
and I thought they were really good.
Maybe you could talk about those a bit.
Well, so that first version of that log analysis web front end was actually written in PHP.
You know, that was my last PHP project.
And, yeah, I got it done in time, but it had some problems.
Number one is that, like, it was written in PHP,
so, like, maintenance wasn't really, you know, on my side.
And then I actually had to keep fixing bugs and running the service.
And I basically was left with no time to actually do other projects.
And so I didn't want to be the guy that just maintains log analysis tool, you know,
so I shut it down after about a year.
But, you know, from then on in, I gave a lot more thought to,
what is the maintenance curve going to look like?
Is this something that I'm going to be able to sort of set aside and move on to new things
so I'll always have something new?
But that old stuff can keep, like, running.
I don't want to be, you know, one of those flash-in-the-pan project sort of guys.
You know, I like to build up a lot of different services that I run
that help people in real situations.
The exact lessons were basically, like, choose your dependencies
and avoid doing it all at once.
So you can, if you can rely on your organization,
I mean, you're working at a large organization.
Find ways to rely on the organization.
Offload some of that maintenance.
And finally, like, that longevity, it doesn't come easy.
It's the result of a lot of critical decisions.
And it's more than just regular software, I think.
Like, you could write...
Yeah, there's a lot of soft skills involved.
Oh, absolutely.
So you could write the software if you were kind of doing this little app on your own
and it could do its own little thing.
But if it's going to continue to live on and be used,
you have to know the sort of invisible connective tissue of the software of your company, right?
Like, this is the way things are done.
And this is the way it will actually be useful to people.
Yes, I should design it this way if it was from scratch.
But people don't do that.
They do this.
And so I'm going to do this other weird thing
because then it'll get used for a long time and so on, right?
Right, right.
Like, I mean, I'm all for going against the grain a little bit.
But, and actually innovating, changing things and so forth.
But if you try to do it all by yourself or all at once, you're setting yourself up for,
I mean, you know, let's be frank, you're going to burn yourself out, right?
And you're not going to be able to do those future projects.
And that's the whole point, you know, is to continue building things because there's a lot of things to be done.
Continuous delivery isn't just a buzzword.
It's a shift in productivity that will help your whole team become more efficient.
With SnapCI's continuous delivery tool, you can test, debug, and deploy your code quickly and reliably.
Get your product in the hands of your users faster and deploy from just about anywhere at any time.
And did you know that ThoughtWorks literally wrote the book on continuous integration and continuous delivery?
Connect Snap to your GitHub repo and they'll build and run your first pipeline automagically.
Thanks SnapCI for sponsoring this episode by trying them for free at snap.ci slash talkpython.
Yeah, and you had some really interesting statistics about the types of apps and the numbers of services and so on inside PayPal in your course.
And it just makes me kind of laugh thinking like, oh my gosh, this is crazy to think, you know,
So when I'm talking about like, how do people within the company work and how does software normally connect?
You had like a graph that was basically so dense it was illegible, but showing the interconnections between services.
Can you talk about that for a sec?
Sure.
So PayPal is a service oriented architecture company going back over a decade.
It started as a monolith.
And there's nothing wrong with that when you're starting something out.
Like a monolith is a really good way to get things done.
But as you are expanding both in terms of customer base, computers running your software, people working on that software, most importantly,
then you, it starts to become a burden.
And eventually that hit a technical wall for PayPal where that monolith called WebScr.
I think I can talk about that.
W-E-B-S-C-R.
If you look in some PayPal URLs, you'll still see it.
It's a C++ executable.
And it reached over a gigabyte and a half.
One program.
And I don't want to talk about that in the course.
It's C++, not Python.
So, but it hit like one and a half gigabytes.
You can't even put debug symbols in there in order to debug what live issues are going to be.
So, it became completely, it got completely out of hand.
And they, at that point, like they knew that they had to switch to something more distributed so that they could work on it with more engineers.
And so, you have these service-oriented architectures sort of for human reasons.
You know, you want to have a user team.
You want to have, you know, payments team.
You want to have a, you know, front-end team or whatever.
There's, you know, and so you have to start segmenting things by layers and domains.
And so, at PayPal, we've done this in the extreme.
We have one huge product.
You know, Google, they have Gmail.
They have Maps.
And even they have sort of monolithic development structure in a way.
But these are all separate products is what I'd like to emphasize.
At PayPal, there's not that many different products.
It's pretty much PayPal.com.
And so, just for PayPal.com, you have over 3,000 service, over 3,000 service endpoints, logical endpoints.
You know, there are tens of thousands of machines running the code.
And just within the mid-tier, over 3,000 endpoints.
And that's, like, you know, representing hundreds of code bases.
And so, this is all communicating with a variety of protocols.
I've listed off a few already.
But it's pretty much those ones.
HTTP, you know, RESTful, et cetera.
Then you have NetString for some of the lower level, older stuff.
That's pretty much, we have one, like, proprietary one that's really old and will never go away.
You know, I talk about that in the course, too.
There's a sort of design permanence.
It's indelible.
Yeah, absolutely.
But, so, yeah, we have these thousands and thousands endpoints.
And they, you know, rely on each other in really complicated ways.
And each individual team has to consider how those runtime dependencies and logical dependencies are going to affect the scalability and performance of their application.
That's a lot to keep in your mind and sort of juggle, right?
Like, if I call this service and that service and this one calls that one, like, what is the latency and scalability considerations I have to actually worry about?
Well, I mean, some people don't even get to the point where they're able to worry about that stuff.
That's kind of the problem.
You know, due to other decisions, you know, they end up, like, you know, constantly having to fix bugs or work around issues.
And they don't get to have those important spare cycles to build quality.
So, you did talk about scalability a bit in your course.
And I thought that was interesting that you said scalability is not itself a feature of software.
But it's actually, like, a composition of three or four bits or more sort of atomic units of, like, throughput and so on.
Yeah.
So, I thought about it a bunch.
And I couldn't really find an ontology of what makes up software.
What are the aspects of software that really applied to what I saw happening at PayPal?
And so, I sort of had to come up with one of my own.
So, yeah, we came up with this ontology, talking to coworkers and so forth, of six different software aspects.
And so, the first is, like, usability.
You know, that has to be first.
If your software is not usable, if it doesn't have features to use, then it's really nothing at all.
So, you have to have usability.
And then, you know, we have availability.
That's kind of the reliability.
We have the introspectability.
So, that's how good your logging is and other instrumentation.
Then, we have performance.
Everyone, when they think of enterprise software, they think about, like, they think I'm talking about performance.
And that's just one aspect here.
And within performance, I'm referring to, like, latency, throughput, and utilization.
There are many aspects within each of these aspects.
But fifth has to be security.
Security really makes everything so much harder.
I can tell you for a fact that one of the reasons why other companies can move, like, faster than how PayPal, like, moves is because they don't have to worry about locking down access to all these secure resources.
Our deploy process is primarily convoluted because of that security consideration.
Normal developers do not have access to where their code runs.
So, that, you know, brings me to my sixth aspect, which is the agility, right?
Your ability to deploy quickly, change things quickly.
Everyone talks about, like, oh, everyone on their first day should be able to change one line of code and deploy within one hour or something like that.
And I'm like, okay, man, like, you know, one line of HTML, you know, changing the styling of a button or something is very different than, like, one line that impacts everyone's, you know, security.
Yeah, that token, that security service you were talking about that does almost a billion requests per day.
Two, three billion, yeah.
Yeah, that one you don't want, like, the new guy to, or girl, to, like, modify necessarily on the first day.
Right, right.
And so, I mean, and these six aspects, they're all, like, interconnected, like, better introspectability, we find correlates and causes better performance.
And because you can actually see the effect that you can actually see the effect that your changes are having.
And so, these six things sort of create, like, software hexagon or whatever, kind of like the project management triangle, which, aka the pick any two, right?
Fast, good, and cheap.
Like, you can make something that is very usable and you can deploy it very quickly, but maybe its availability is not so great because you don't have a good throttling scheme.
It's like you have to choose a balance of these things.
And as a result of choosing a good balance of these six aspects, you can build scalable software.
Yeah.
Very interesting.
I think the good, fast, and cheap triad is a very effective mechanism for speaking to people who are not developers and developers as well, but it comes through really well.
Right.
But, I mean, good is just so nuanced.
Fast, that's just a certain amount of time.
Cheap, that's just a certain amount of money.
Those are easy to quantify.
But what does good mean?
You have to expand that, and that's where these six aspects come from.
So, you sort of set out to define a spectrum of enterprise software, if you will.
You said, okay, a thing is not either enterprise software or not enterprise software, but it might live somewhere along a continuum.
And you have, like, nine points that would push it one way or the other.
Do you want to talk about those?
I thought they were really on point.
Yeah.
Enterprise, it's either enterprise or it's not enterprise.
That black and white view is not actually really helpful in helping people find, you know, just corollaries and analogies to the work that they're doing.
You know, we want to make something that people can actually relate it to what they are working on.
I created a list of these.
And, you know, I'll probably release this as a blog post or something like that as well.
But I think that this one is one of the free clips that you can view.
But just to run down the list real quickly, you can have any number of these and it sort of defines how much, how enterprise your software is.
So number one is that it's used by business.
Number two is that it's sort of tailor made, like it's custom.
And number three is that you have a specific user base, like we talked about before, that it's a, you know, if there's just two or three people using your software, it's going to have a really different development feed and flow.
Then you have strict runtime requirements.
That's where the performance comes in.
You know, that I need this with an SLA 95 percentile of like, you know, two milliseconds, 200 milliseconds, whatever.
Then you have that your software is part of a larger system.
And so at PayPal, you know, if you have to, we have to integrate not just internally with thousands of service endpoints, but also externally with financial processors and, you know, all of these highly regulated, basically legacy systems.
And so that brings me to the next one, which is legacy integration.
If you have to integrate with legacy, you know, I just got to give that a special shout out.
That's enterprise.
That moves you far down the spectrum to the right, doesn't it?
Exactly.
And, you know, so and that feeds into kind of the design permanence.
And so people worry a lot about making the right decisions.
And we talk a lot about technical debt.
But one person's technical debt is another person's like, you know, just software longevity, you know, software that has to run on airplanes.
And satellites and so forth.
I mean, it's not technical debt.
It's just a different kind of investment.
And so design permanence is definitely a hallmark of enterprise software.
Because of all of the things involved when you're doing all these integrations, if there are a lot of negotiated timelines and promises being made about, like, you know, delivery dates and so forth.
You know, some people will just say, hey, that's just waterfall and that's bad.
But that's how a lot of systems have to work when you have these deep dependency trees of software.
Like, you know, dependency, I guess.
Reli.
People relying on you having something done at a certain time.
And finally, like, you know, when you are handing software off to another team to be run, you know, if you have a separate operations group, a separate site reliability engineering group, SRE, if you have a separate security group that's going to audit your stuff.
If there's all these specialized groups, that's another aspect of enterprise software.
And so if you look at these nine different, like, hallmarks, you can see that in consumer ecosystems, which consumer is the opposite of enterprise, these aren't really the case.
You know, for instance, specific user base.
Usually in consumer software, you're just putting an app on an app store and people will either like it or they won't like it.
There's a market.
There's choice.
You know, a user base that's going to be using my first Python project at PayPal, you know, changes the prices of PayPal.
There's a good reason why we don't want thousands of people using that.
It basically has 10 users or so who can actually modify the values in there.
And they're still using my code, you know.
And it's being maintained by a different group.
So I consider that enterprise software, even though it only gets hundreds of requests a day at most.
It has a specific user base.
It's part of a larger system.
Legacy integration.
Tailor-made.
Right.
It's tailor-made.
I mean, I use Django, of course, but at that time.
And but it had to integrate with a lot of these systems and a lot of these human processes in a way that, you know, is just different than consumer software.
So just defining something as enterprise based on its performance requirements excludes this other part of the spectrum.
And that's not really that great.
I'm not saying that that application is the most enterprise.
Probably the most enterprise software that can occur to me is the ADA code that runs, you know, on the 737, 747, whatever, you know, airplanes.
I mean, that's far more enterprise than I will ever write.
It's even more enterprise than like the security stuff, I think.
You know, there are lives at stake.
So medical software.
I consider that enterprise.
Yeah, I think I think that's an interesting sort of nine dimensional spectrum that your code can live in.
And I think it hits a lot of interesting points.
You know, one thing that sort of struck me when you're talking about that with the tailor-made specific user base and thinking about how it fits into a larger system.
You know, I think I've heard less of it lately.
I don't know why, but for quite a while and still to some degree, people make very strong comparisons to architecture as in a person who builds a bridge, an engineer, maybe a civil engineer who builds a bridge.
Sure.
And software.
And they're like, the civil engineer can build a bridge within 10% of time estimates, materials estimates, and so on.
And, you know, people say, well, why can't we do this with software?
Well, the reason is software is an immature discipline and we need to get more mature.
But I think actually what is totally that totally misses the point.
The thing is, it's the tailor-made part, right?
Like, right.
If the software existed and you could just plug it in, then bridges you can't copy.
If you have 100 bridges that are real similar, you got to have 100 times build it, 100 experiences it.
Right.
But if it's software you use, you just you sell it, you know?
Any web dev shop, any studio can give you a very accurate estimate how long it's going to take to set up your CMS if you do not have, like, really high, you know, customization requirements.
And, in fact, when people go further, I don't know who's sponsoring these days, right?
It's Squarespace or whatever, right?
Like, they've automated it.
And so the main thing that's different in, like, the real world versus the virtual is the construction aspect, right?
So, I mean, there's no, like, special construct – there's very little special construction setup, especially in these smaller applications.
If you go look at ERP integrations, I think those still take, like, you know, a decade.
I, you know, for better or worse.
For better or worse.
Yeah.
So that is as enterprise as it gets.
It's maybe more enterprise than it has to be.
But I'm not going to sit over here and, you know, judge about that.
Yeah.
I think what your sort of list here highlights is you might say these are the requirements we have.
But it has to fit into a very unique and largely invisible bigger structure.
Right.
And it's for a specific user base who's never had this piece of software before.
And so, like, there's just so many unknowns and sort of one-offs that these analogies between, well, why can't we build software like we build bridges?
Become more obvious when you think about all the stuff going on there.
Right.
And I think that we do need to think more about it.
Like, and we need to talk more about it.
I don't really like, you know – this is sort of my reservation about what you said about the iPhone, right?
Like, you know, you can't really reduce every aspect of design to whatever Apple is doing.
Right?
Like, Apple doesn't make very much enterprise software.
And, I mean, internally, I'm sure they have many enterprise systems.
Don't get me wrong.
It's not going to represent a whole industry.
It's just one company.
Yeah.
You know?
So, yeah.
There's a lot of – I'm all for more variability in designs.
Yeah, absolutely.
This episode is brought to you by Hired.
Hired is a two-sided, curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front, and you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers within the first week, and there are no obligations – ever.
Sounds awesome, doesn't it?
Well, did I mention the signing bonus?
Everyone who accepts a job from Hired gets a $1,000 signing bonus.
And, as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me, and Hired will double the signing bonus to $2,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the call.
One of the things you talked about in the class that I thought was surprising that you'd bring it up a little ways into it was you said, let's talk about what is Python.
You said that this actually has several answers, almost depending on who you're talking to, to some degree.
Yeah, it has to.
Yeah, pretty deep into the course, I talk about what is Python, and that's because this course is sort of targeted at people who are self-taught, you know.
And so maybe they learned programming from Python.
They've taken a beginner course.
This is an intermediate course.
So they've taken a beginner course, and they're looking to get into professional software development.
And at that point, you know, the Python that they learned as a beginner, we need to expand that definition, flesh out that definition to work in the professional setting.
And, of course, there are also people who are coming to this from an enterprise software perspective, and they are learning more Python from this, and they can use – I mean, I deal with a lot of those – I mean, not deal with.
I interact with a lot of those people at PayPal who – I mean, you know, they are expanding their skill set.
They know a lot of Java, C++, JavaScript, and they want to learn Python.
And so, you know, I give them my definition of Python.
And so there are three levels at which, you know, we say Python.
So number one is the language.
You know, it's the language of choice.
It's so clear.
You know, some people don't like the white space stuff, but that's part of the language.
For many years, that language that we all love, it was directly implemented by more or less just one runtime.
You know, like CPython, the reference implementation, was synonymous with Python.
I don't run CPython at my command line.
I run Python.
And so many of the benefits of Python are actually benefits of CPython.
When I talk about the consistency and, you know, rich runtime, those things are – many of those are runtime-specific from CPython, implementation from CPython that may be copied in other runtimes.
So other runtimes might include, like, Jython, IronPython, PyPy, you know, P-Y-P-Y, and PyPy.
And, you know, now there are some other ones, too, Pidgin and stuff.
And then, finally, there's the platform.
So executives and managers, when you talk about Python with them, they're not really, you know, that interested in what the language looks like.
Some of them might be, but that's, you know, kind of micromanager-y.
Anyways, they're more curious about how is Python going to help the organization.
And so that means Python as a platform, as a community.
And there are many benefits to Python there.
You know, you have a lot more education adoption, so you have a lot more sort of pre-training when you're doing your hiring.
Like, basically, people are coming in already knowing the language.
And then you have a big open-source ecosystem, you know, 70,000-plus packages on PyPy.
So there's language, runtime, and platform.
And when you're having a meeting, it will be most effective if you can be explicit, if you can be clear about which part you're referencing, you know.
So those three levels of Python.
Yeah, I think even for experienced developers, a lot of times, if you're talking, like, let's say you're talking to a Java person and maybe a Node.js person and a Python person,
and they're saying, you know, Python is really good in this way, right?
You've got – but there's a lot of comparisons that will be made.
And you have to say, are we comparing the language?
Are we comparing the implementation with the standard library?
Are we comparing the entire ecosystem, including PyPI?
Like, before you say this is this feature or it doesn't or whatever, right, like, we need to know what we're talking about.
So that was really interesting, I thought.
Yeah, with Java, I mean, you know, Java is a language.
Python is a language.
CPython is a runtime.
You know, you might be using an IBM JVM.
That's your runtime.
And people say – people do compare.
This is sort of why I brought it up.
They compare Python to Node.js.
I'm like, okay, you know, Python is a language.
JavaScript is a language of Node.js.
Node.js is the runtime.
CPython is the runtime.
Let's, like, you know, compare these things side by side.
So people say Python is slow.
I'm like, okay, man, a language can't be slow.
CPython is not jitted.
You can use PyPy.
You can get certain performance benefits.
You know, Node.js doesn't support threads.
That's, you know, another aspect of the runtime.
I think that you could probably make a thread-safe ECMAScript, like implementation or something like that.
But I haven't really looked too deeply into it, honestly.
I'm sure it's possible.
But also not done, right?
So one of the things I thought was – yeah, maybe it's been done.
One thing that's interesting is sort of the soft skills story here.
Like, when you go and talk to executives or managers, it's not just – you don't want to get too technical, right?
You want to say, like, we're talking about the ecosystem.
We're talking about – take it as a whole, right?
And the truth is that businesses are run by people.
And your sort of skills to work with these people and convince them and speak their language really matter still.
Yeah.
So what I usually tell them – and so this is all just expanding that 10 myths thing, just blowing it wide open and approaching it from a more positive aspect.
It's not just rejecting myths, right?
It's saying, okay, well, what do you talk about instead?
And, you know, Python created in 1991.
It's like it had a nice, long, slow bake all the way until it sort of hockey-sticked for a lot of web things between 2003 and 2006 or so.
And so as a result, you have this, like, really, like, you know, well-tested, well-understood core reference implementation.
And you have a huge open source library.
It's used in education a lot.
And one that I like the most is – I have to tell people, it's organizationally neutral.
So a lot of people still haven't heard of Python.
You would be surprised.
People paid far more than I am.
I mean, they haven't heard of it even.
And one of the reasons for this is that Python is organizationally neutral, where IBM and Sun and Oracle – or, you know, Sun used to, but IBM and Oracle, like, you know, sell and sold Java.
You know, there's no company that is selling Python.
You know, there's no joyance of Python.
I mean, there's Continuum Analytics.
I mean, they're great.
You know, there's InThought.
But these are, like, you know, pretty small companies.
Your company wouldn't have, like, an enterprise license agreement with Python as a thing, right?
There are probably some groups that do it.
But no, it's not like that.
It's not a sold thing.
Instead, engineers choose it, and they use it, and they succeed, you know?
And you can get support contracts for it, but that's not really the Python way.
The other thing that you kind of touched on in that whole section is the idea of a foundational technology.
This is – managers especially, but basically everyone has this to a certain degree.
Like, people get really anxious about doing things the right way.
Basically, everywhere you look in technology, people are telling you that things are changing, okay?
This changes it all.
This is new, and it's going to change it all.
And, you know, I think we all know this, but we don't really get to think about it.
It's like a year later, you just don't hear about it ever again.
We've been fed this line about software being ephemeral and, you know, tools not mattering, only delivery.
You know?
This whole ephemeral technology thing, I don't buy it.
Foundational technologies are real.
So, specifically, like, Linux, BSD, and in general, the POSIX standard.
There are people who, if they woke up one day and read the news and said, hey, Linux is over.
You know, Linux is gone.
They'd be like, well, yeah, what did you expect?
I mean, you know, open source.
And it's just things are crazy.
You know, it's like they could actually buy that sort of reality.
But these things are permanent.
There's, like, long traditions.
There are long histories.
We don't usually get time to read into them.
But these foundational technologies are real.
Another would be the C programming language.
And CPython is a really, I mean, Python and CPython are really natural extensions, you know, relying on the C programming language.
So, I feel confident, you know, grouping Python with these foundational technologies, largely because C is so foundational.
You know, C is not going away.
You know, you can take it even further.
There are people I know, I mean, highly paid people here at my work.
They'll come up to me.
They're like, oh, man, but you're like the Python guy.
You know, you like new programming languages and stuff.
You know what I think?
I've heard that this visual programming thing, this is going to be the next big thing.
And it's like they see one demo and they think that, you know, procedural programming is going to go away.
That, like, top to bottom execution of code is in the future at some point not going to be something viable within their lifetime, within their work span.
And it's just such a wasteful conversation to have.
I talk about it a little bit in the course, that sort of navel-gazing sort of thing.
Which language is the best language?
Instead, I try to refocus them.
You know, I tell them maintenance is real.
And, like, longevity is possible.
And the tools and methods matter.
You have to use stuff that has been baked.
So the underlying spirit of the course is that if you choose your architecture, dependencies, and practices wisely, you know, you can rest easy thanks to these foundational technologies.
Yeah, and I think you're more likely to experience or run into the deep history of them at enterprises, right?
Like, at a startup, all the code is, what, a year old or whatever, besides maybe the package you grab.
But if you go to a company that's been using a technology for a long time, you could go to source control.
And the last check-in or the first check-in you would see might be, like, 1995.
And that's because you switched version controls and couldn't carry the history over or something like that, right?
Right.
No, you hit it right on the head, man.
I mean, like, I was blown away when, I think it was 2012, beginning of 2013.
I was actually, like, curious.
This is when I first started getting into the security stuff.
I was curious how something was implemented.
We needed to re-implement it in Python to enable running on 64-bit.
You know, PayPal primarily runs on 32-bit stuff because they have old SOs that are just linked in.
They're checked into the repo and stuff.
So, I mean, 64-bit was not a thing when PayPal was written.
And so, you know, 80% of our, I should say, too, like, 80% of our revenue or something like that is still going through the, quote, unquote, legacy stack, right?
But, you know, when you're actually, like, there re-implementing and reverse engineering Max Levchin's code, you're like, wow, software really is actually a lot more permanent than I was taught.
So, you know, by the Internet or whatever.
Yeah, yeah, yeah.
By the person with the latest framework that's super excited about it.
Exactly.
And so you have to learn to distinguish between a press release and, you know, actual, like, neutral academic whatever, you know?
There's press releases and then there's real experience, real education.
Yeah.
So one of the things you talked about was sort of Greenfield versus Brownfield or, like, brand new software versus legacy software, if you will.
Yeah.
I think you sort of convinced me that there's more value in these Brownfield apps and people that work on them and can evolve them and really add features and understand them.
I deserve maybe more respect than the industry gives them.
Yeah, that is definitely the case.
It's just a culture thing within technology.
The new is always emphasized.
But the old stuff is what we're using right now.
That's what's working right now.
That's what's causing money to move.
And disrespecting it and, you know, being productivist about it doesn't actually get us any further in technology progress.
You know, we have a lot of people who come in and they try to, you know, plow the whole field under.
And, you know, their tractor, their plow, whatever, just, like, you know, hits one rock.
And then they declare victory with the small patch that they turned, you know, green.
And they, you know, move on.
But, you know, and then you end up with this patchwork environment, you know, where it's like, well, that was green.
That was greened by so-and-so that long ago.
And, you know, that part over there they never reached.
And so you just end up with this very untended wilderness.
It's interesting.
It's a really fun environment.
You know, this is why, you know, you can see I get carried away just daydreaming about, like, the complexity inherent in a system as complex as PayPal's.
So we don't have a lot of time left in the show.
We're sort of getting to the end.
But I wanted to maybe talk about some of the stuff farther down, like some of the best practices that you're talking about.
One of my thoughts was interesting.
It was sort of a pull request, designer view type of experience.
Right, right.
So the way that the course is structured, you know, is I got an intro and then I defined the basics.
I just do some definitions.
And then I have this dry segment in the middle about architecture and design.
And so those first three parts are, like, I mean, especially the architecture and design part, those are just, like, processes and soft skills that, you know, you can use in the enterprise world.
Then we get to, like, the real meat, which is this, like, 12 segment best practices.
And this is sort of, like, you know, adjustments to, you know, your knowledge and pointers to how to do things that should be generic for most organizations, most legacy environments, and how you can put Python in them and create new software.
So once you get past, like, you know, just, you know, editors, dev tools, issue tracking, you know, how to start a Python project and some design patterns.
You know, people always ask me about design patterns.
They're coming from, like, a Java and C++ background.
And so I threw a segment in there.
It's, like, well, design patterns in Python tend to be, like, so small you barely even see them.
So I said, here's how to, like, actually look and see Python design patterns.
But, you know, eventually, like, so the first half of best practices is building new code.
And the second half is maintaining that code and building quality.
And I think that the first one of those is code review.
And this is one of my favorite segments because, you know, I get to do a little bit of, like, black hat, white hat sort of role playing with myself one weekend.
And so one day I just wrote some really bad code that I tried to build in every anti-pattern that a, you know, budding developer will accidentally stumble upon.
And I put it up on GitHub.
And I just, like, had to sleep on it.
I just, like, went to sleep.
And the next day I came back and I just, like, tore into myself.
I just, I mean, well, that's not true, actually.
Like, I did a precise code review stating why there were problems, where there were problems.
And I did my best to be nice about it to promote the actual, like, you know, positive interactions you try to have.
And so all of that is available on the GitHub repo for the class where I sort of have this example project,
which is useful for about a quarter of the class, just as sort of a reference.
And so that's github.com forward slash Mahmood forward slash SP metrics, ESPY metrics.
Yeah.
And I'll link to the link to the show notes as well.
Great.
And so there's just a pull request in there that I will never merge because it does everything the wrong way.
And so I have a bad implementation, all the comments on it, and then a good implementation.
And you can, you know, sort of do an apples to apples comparison there.
And, you know, it was interesting.
Yeah.
I think that's something that a lot of enterprise developers who maybe haven't spent a lot of time in open source don't get to really experience a lot.
The sort of GitHub pull request style of work, right?
That is true.
When I started at PayPal, we were using, I think, something you've probably heard of.
We were using ClearCase.
ClearCase was maybe worse than I could ever imagine for a version control system.
You know, it was like every file, like it was a file by file thing.
You could get these evil twins.
And I just, you know, I know that some people still have to use it.
I run into them here in like the valley.
And, you know, it's kind of a shame.
But, yeah, so we did actually not too long ago get GitHub Enterprise.
And I think that it's a much, much healthier way to develop.
You know, you have a decent branching strategy to keep things like sane.
And then you, this like very useful UI.
And I'm sure that like Bitbucket has similar stuff.
Yeah, the code reviews is actually exactly what, this is exactly the sort of thing that we do at PayPal as well.
And that's one of the reasons I did it because we have an internal DL as part of the community.
We have an internal listserv where people can request code reviews from other teams.
You know, and so that's one of the services we provide as the Python infrastructure team at work
is that we'll code review any Python code you give us.
And I just did my best to export that in an organizationally neutral way.
Yeah, so you've had a chance to look at both good and bad examples.
And you brought them to the class, yeah?
Well, and yeah.
And so that is like actually one thing you just reminded me, right, is that a big part of the class is evaluating dependencies.
I think that that's a great way to learn Python.
That's a massive way that I learned Python.
Reading Django code.
Reading bottle PY code.
You know, when I was doing all this web development, actually digging a little bit deeper, you know,
Python ships with its source code and you can see your actual code, like what your dependencies are doing, what you're relying on.
And so, you know, don't constantly live in the sausage factory looking at how things are made.
But take your time to evaluate dependencies because it will help you avoid some really horrible architectural nightmares.
At PayPal, I mean, I think we all know about the left pad thing at this point.
So anyways, at PayPal, we have a typical Python team.
It's small and we always have like 10 things to do.
So we have to make choices that favor stability and to make sure that when we finish something, it stays off of our plate.
As such, like we're really big advocates of vendoring in libraries.
So that means that we copy dependency into the project.
This isn't something you'll see a lot in open source projects because there's the Python packaging index, PyPI.
But we view like copying in this library at a certain version as sort of the Python equivalent of static linking.
Yeah, we do that too with our C libraries.
But we build projects with the dependencies built in.
And this way, teams can just clone the repository and go.
And then when you package an RPM or DEB or whatever, there's no install time dependencies.
And so there are minimal side effects.
Basically, repeatable deploys are critically important in any environment.
And whether you achieve them via RPMs, DEBs, containers, whatever, as long as you have those repeatable deploys, you're going to be in a lot better spot.
Yeah, definitely.
Repeatable and automated are the key element, right?
Yeah, I talk about CI in here.
We definitely use Jenkins and so forth.
I don't know if I'd recommend Jenkins specifically, but another team is running the Jenkins.
That's the thing.
We have a group that manages Jenkins for us.
And so if that's one more thing we don't need to do, that's one more thing of our own that we can do.
Yeah, that's awesome.
All right.
So I think for the course, we'll just have to leave it there.
We're out of time.
Let me ask you.
Oh, wow.
Yeah.
Let me ask the questions I ask everyone.
So first of all, I know I asked you this way back, like a year ago, but maybe it's changed.
Favorite editor?
No, I mean, it hasn't changed.
Emacs.
I still use Emacs primarily in the console.
Yeah, because this is interesting because now there's going to be like Ubuntu on Windows, sort of a GNU NT thing.
So I've actually considered getting a Windows laptop and running Emacs natively in it because we have so many Windows users here at PayPal to help support them.
Yeah, you'll be able to live the life they have to live and sort of experience it.
Yeah.
That was just announced last this week or no, last week at Build.
So yeah.
Yeah, yeah.
Basically, Ubuntu running natively on Windows.
It's weird to be excited about Windows feature.
For me, it's weird to be excited about Windows feature.
I could only get more excited if they told me that they're going to build in Python.
Maybe they will.
That would be intense.
You know, when Windows 10 was under development, I was using the community preview or whatever they called it.
And they had a user voice set up for you could recommend features and get votes.
And I recommended that they install Python and ship Python 3 and Python 2 as built in to Windows.
And I got, I think, over a thousand votes from the community to say, yes, Microsoft, build this.
Absolutely.
And sadly, it went nowhere.
Nowhere.
I mean, maybe somebody heard it.
You know, that's one thing with the enterprise.
Like, you know, there are so many, like, moving parts inside of it.
You know, you can, just because you don't see anything happen on the surface doesn't mean that people aren't hearing it inside.
Yeah.
It doesn't mean it'll go anywhere.
I'm not, I can't make promises for Microsoft.
Right.
Yeah, just the show I just recorded before this one was Steve Dower.
And he works at Microsoft on doing a lot of really interesting stuff with Python and Visual Studio and Windows.
And so there's, there's, there's a chance someone will pick it up.
We'll see.
We'll keep putting the idea out there.
I'm hopeful.
Yeah, absolutely.
All right.
And favorite PyPI package?
What do you, what do you find recently?
That's awesome.
This was all, like, this was really, really tough.
I mean, I, I don't think I, I said this last time.
I mean, G event and Greenlit, we use it so much at work that, like, I just have to give it a shout out.
G event and Greenlit.
But, you know, we have Twisted users here.
Twisted is a very respectable code base as well.
And, you know, I'll give a little shout out.
I'm working on a, a stats post that, like, you know, statistics for engineers and whatnot.
And a lot of that is motivated by a new project I'm working on called Lithoxal, which is sort of next generation logging and instrumentation.
You know, it's not public yet, but I know that some people on the podcast are probably early adopters.
And, you know, it's good to get some feedback.
So, L-I-T-H-O-X-Y-L.
Awesome.
Weird name, good library.
That's awesome.
We're going to give away a copy of your class, right?
Absolutely.
Yeah.
All right.
So, if you're listening and you want to check out the course, it is on O'Reilly.
All you have to do to be eligible to win is be a friend of the show.
So, visit talkbythumb.fm.
Go to the nav bar, click friends of the show in your email address, and then we will randomly choose somebody later in the week and give you a free copy of the course.
If not, how do they find it?
Like, if people want to check out the course, where do they go?
So, there are several places to find it.
So, one major reason I went with O'Reilly is because so many large organizations have Safari.
And so, I waited until the course propagated to all of the Safari-like installations.
So, if you have TechBus or, let's see, I mean, you can just go to Safari Books Online and type in Enterprise Software with Python.
Otherwise, you can go to straight up O'Reilly.com, and it's called Enterprise Software with Python.
And so, you can just search it.
I think it may even be Google-able.
The one thing is it has a price, right?
If you're someone who can't afford it, just get in touch, right?
This is something that I'm passionate about.
And, you know, I want to make sure that everyone has a chance to get into the professional Python software development world.
Yeah.
It's a really great course.
I totally enjoyed going through it.
So, nice work.
You have a course as well.
I do.
I just released one a month ago, Python Jumpstart by Building 10 Apps.
And that's been really well received.
That was cool to do it on Kickstarter.
And I just announced this week, I think, yes, Monday, that I'm working on a new one called Python for Entrepreneurs.
And basically, you know, if you've ever built a business, it's only like 30% product.
It's only 30% technology.
And there's all this other stuff.
Like, how do I accept credit cards?
You know, speaking of PayPal and that sort of thing.
How do I gather emails and send newsletters?
And just all, how do I do deployments?
How do I do SSL?
All that kind of stuff.
Oh, yeah.
It can be intimidating.
Yeah.
When you think you've finished your app and whatnot, you know, you're like, okay, well, I'm almost ready to release it.
No, you're like 30% of what you're done.
So, I wanted to create a class that would help people close that gap.
Great.
Yeah.
No, I've already, I think, bought a copy.
And, you know, we're going to actually have a little powwow with the Python community here at PayPal.
Oh, awesome.
Well, thank you so much.
That's great.
Yeah, it's good stuff.
Cool.
Well, Mahmoud, this is fun as always.
Your original 10 Myths post was super inspirational.
I think to a lot of people, it certainly was to me.
And I was really glad to feature as one of the early shows.
And this is kind of like the rounding out of that story.
So, everyone go check out his course.
It's great.
Yeah.
Thanks, everyone, for all the support, frankly.
Yeah.
I don't think I could have done it without at least some of you.
That's awesome.
So, yeah, that's great.
All right.
See you later, Mahmoud.
Thanks.
Yeah.
Bye-bye-bye.
Bye-bye.
This has been another episode of Talk Python to Me.
Today's guest was Mahmoud Hashemi, and this episode has been sponsored by SnapCI and Hired.
Thank you guys for supporting the show.
SnapCI is modern continuous integration delivery.
Build, test, and deploy your code directly from GitHub, all in your browser with debugging,
Docker, and parallelism included.
Try them for free at snap.ci slash talkpython.
Hired wants to help you find your next big thing.
Visit hired.com slash talkpython to me to get five or more offers of a salary and equity
right up front and a special listener signing bonus of $2,000.
Are you or a colleague trying to learn Python?
Have you tried boring books and videos that just cover the topic point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at training.talkpython.fm.
You can find the links from today's show at talkpython.fm/episodes slash show slash 54.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python, which should be right at the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith.
It goes by Smix.
You can hear the entire song on talkpython.fm.
This is your host, Michael Kennedy.
I really appreciate you guys taking the time to listen.
Smix, let's get out of here.
Outro Music