Python 3.8 (2019) added “assignment expressions”, aka the “walrus operator”.
I generally like things that make Python more expression-oriented, like list comprehensions, but I’m ambivalent about these. It’s pretty easy to impair readability by using them overzealously. Is saving one line of code worth making it harder to notice that an assignment is happening?
However, I’ve found a use case I like a lot. I use them in the Django Python shell when doing exploratory ORM queries.
I enjoy writing tests because I love what they give me.
I love knowing that I’m adding defense against breakage from future changes. I love thinking through how a feature is really supposed to work, and having the test capture that understanding. I love thinking about edge cases that the code should handle, and writing tests for them — especially if it turns out that the code under test didn’t yet handle them correctly, because that means I’ve just saved us from a bug.
I can be kind of a stickler about leveraging the ticket/issue tracker in software projects (which always seems to be Jira these days, but nevermind that). I write tickets carefully; I link to related issues; I add comments to note the status of work in progress, or to record info that’s important to the work to be done.
I’ve been a full-time remote worker since 2010.
The COVID-19 pandemic has brought big changes to things involving face-to-face contact – like going to an office for work. Since this sea change has gotten more engineers (and employers) to think about remote work, I thought I’d share some tips on how to find and keep remote gigs.
This was written with junior-level engineers in mind, and is more about full-time employment than freelancing.
A couple weeks ago I accidentally replaced our live, production database with a 17-hour old snapshot.
I had intended to target a test server, not production. I didn’t realize what I had done for an hour or so, and by that time I had already left work. (I was actually out walking my dog. Not a good setting for managing a production crisis.)
Here’s how my team and I handled it.
Non-engineers want to know: what happens when a big bug is found in your software, and the bug is causing real users real problems, and you’re the one who wrote the code?
Engineers do sometimes write bad code, and sometimes it makes it into production, it’s true.
But shipping production software involves a lot more than writing code. It goes beyond that one engineer. That engineer is not the only person who saw or ran that code.
When we were growing our team of Python devs at CMG, I was involved in a lot of interviews. I really enjoyed it, meeting and hiring interesting and talented engineers.
I’m not a big fan of quizzing people on technical minutiae in interviews. I do think that asking some questions about technical likes and dislikes can be very illuminating though.
For example, “What’s your favorite standard library module?” (My favorite answers are itertools or functools, but anything that shows they have hands-on appreciation for the depth of the standard library is good.
