Depending how you compile Python, you can get significant differences in performance—and that is reflected in performance differences in real-world versions of Python, like Ubuntu and the official Docker images.
Benchmarking is often not done in CI because it’s so hard to get consistent results; there’s a lot of noise in cloud VMs, so you ideally want dedicated hardware. But, it turns out you can use a tool called Cachegrind to get consistent benchmarks results across different computers, allowing you to run benchmarks in GitHub Actions, GitLab CI, etc. and still get consistent results.
How do you ship a product on schedule? One useful mental tool is the You Ain’t Gonna Need It heuristic: leave out all the things that seem nice-to-have, but you have no proof you actually need. And when there’s things you do need, consider the follow-up heuristic: You Don’t Need It Yet.
There are a whole range of ways to package your Python software: Wheels, Pex, RPM/DEB, Conda, executables, Docker images, and more. Which ones should you use? In this overview you’ll learn why they all exist, the pros/cons of each method, and how it deals with things like code distribution and support for multiple applications.
I knew I was going to nod my head in approval before I even landed on Itamar’s website:
Imagine you’re training to become a chef. You will need to learn how to use a knife correctly, to chop and dice safely and quickly.
And yes, you need a sharp knife. But when you’re starting out, it doesn’t matter which knife you use: just pick something sharp and good enough, and move on. After all, the knife is just a tool.
The people eating the food you cook don’t care about which knife you used: they care how the food tastes and looks.
After six months in the kitchen, you’ll start understanding how you personally use a knife, what cuisines you want to pursue, what techniques you want to vary. And then you’ll have the knowledge to pick a specific knife or knives exactly suited to your needs.
But remember: the people eating your food still won’t care which knife you used.
I’ll just leave this right here.
Even if you job is secure now, who knows what the future holds? Especially these days, it helps to be prepared. Learn some quick techniques to help make your future job search easier: knowing more people, upgrading your skills, getting public evidence of your skills, plus fallback planning for peace of mind.
If you’re using Docker, the next natural step seems to be Kubernetes, aka K8s. Or is it? If you’re part of a small team, Kubernetes probably isn’t for you: it’s a lot of pain with very little benefits.
If you’re processing large amounts of data in memory, copying data uses up RAM, but mutating data leads to bugs. Learn the design pattern that gives you safety while still reducing memory usage: interior mutability.
Docker builds can be slow, so you want to use Docker’s layer caching, reusing previous builds to speed up the current one. But there’s a down-side: caching can lead to insecure images. Read on to learn why, and what you can do about it.
If you’re not careful your manager and teammates will expect you to be available at all hours, on weekends, and when you’re on vacation. Here are some suggestions on setting boundaries so you don’t set those bad expectations.
Don’t put off slow tests as an annoyance: do the math on how much time your team is wasting, and then spend a commensurate amount of time speeding it up. A week’s worth of developer time this month will save you a whole lot more over the course of a year.
There’s always new technologies coming out, and learning them in-depth would take an impossible amount of time. But you can most of the benefit, and more efficiently, by focusing on learning just enough about a broad range of tools to know when they’re useful.
You know I’ve been preaching breadth-first over depth-first for years now. In this post, Itamar breaks down why that’s a smart strategy for learning new technologies and lays out a few ways you can gain breadth of knowledge.
Unfortunately, he omitted one of the best ways of gaining (and maintaining) breadth: listen to podcasts!
Testing code that talks to the database can be slow. Fakes are fast but unrealistic. What to do? With a little help from Docker, you can write tests that run fast, use the real database, are easy to write and run.
I tried Itamar’s technique on changelog.com’s test suite and the 679 tests complete in ~17 seconds. The same tests run directly against Postgres complete in ~12 seconds.
A net loss for me, but that may have something to do with how Docker for Mac works? I’d love to hear other people’s experiences.
How do you get a programming job with work/life balance when it seems like everyone else is willing to work long hours? By realizing that long hours are the opposite of productive, and that employment is a negotiated relationship.
Automated tests are immensely useful, but passing tests don’t mean your software is correct. Correctness requires applying human judgement before, during, and after coding, which is why you need additional development techniques beyond just tests.
Tests are 💯 a tool in your tool belt, not a silver bullet.
When you’re looking for a programming job, there are dysfunctional companies you’ll want to avoid. This article will help you recognize one warning sign: a particularly problematic phrase.
Do you love programming for its own sake, or do you just program for the outcomes it enables? Depending on which describes you best you will face different problems in your career as a software developer.
Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love.
Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build.
Which is your camp and why?
How do you balance delivering on time and the frustration of seeing messy, out-of-date code? In this article you’ll learn a set of heuristics to help you decide when—and why—to cleanup to your code.
This is a must-read for any software engineer wondering how they can move up the ladder without falling pray to the Peter Principle.
Career progress for programmers doesn’t require giving up coding to become a manager. You can get more autonomy—and stronger negotiation leverage—by going from implementer, to problem solver, to problem finder.
I really dig Itamar’s writing style:
It’s time for another deep-dive into Python brokenness and the pain that is POSIX system programming, this time with exciting and not very convincing shark-themed metaphors!
There’s a lot to learn here, and it’s not all Python specific. Hop in, the water’s warm (but filled with sharks)!