This newsletter is a place of no judgment. The title says February, my calendar says February, let’s just conveniently ignore the 27th part. There’s still plenty of time for a buzzer-beater collection of links. After this, I might as well start working on March right away. Sometimes, life gets busy. Let’s dive into some links.
1. Perl’s decline was cultural (26 minutes)
A longer read, but if you enjoy getting a behind-the-scenes perspective, I highly recommend it. Colin Strickland talks about Perl’s cultural conservatism and how it drove internal fractures within the community. A culture that encouraged telling newcomers to “RTFM” or tolerated abrasive behaviours that were “technically right”. If you’ve spent a significant amount of time in tech, you’ve no doubt come across these attitudes before. Reading this makes me more thankful than ever for Python’s approach to community.
2. Giving University Exams in the Age of Chatbots (16 minutes)
What happens when you give students full access to chatbots during an exam? In Lionel Dricot’s case, many opt not to use an LLM at all, which was not what I would have expected. Another interesting tidbit is Lionel getting students to record their Stream of Consciousness in an empty text file, similar to rubber ducking. I enjoyed the insights into A.I. usage in an academic setting. I’ve often wondered how the next generations see this emerging technology. Also, I fully agree with Lionel’s take that Microsoft’s Outlook is truly a poor user experience.
3. From Python 3.3 to today: ending 15 years of subprocess polling (8 minutes)
A fun technical deep dive into psutil and CPython, ending its use of polling while waiting for processes to terminate. Giampaolo Rodola, author of psutil, walks us through how Linux’s introduction of pidfd_open opens the door for event-driven waiting. How? By returning a file descriptor instead of an integer for identifying a process. The file descriptor can then be used with existing system calls such as select, poll, epoll and kqueue. Every time I build a new piece of software and think, “Is polling good enough?”, I’ll remind myself of this example.
4. Things UNIX can do atomically (6 minutes)
This was another technical post I came across while doing some research. Building multi-threaded software can be tricky when it comes to lock mechanisms. Why not rely on the operating system instead? Richard Crowley put together this list of Unix operations that work atomically. While many language have their own built-in locking mechanisms, maybe you enjoy going full mad scientist with your bash scripts. Like the post mentions:
I trust the kernel developers more than a trust myself.
5. Most Technical Problems Are Really People Problems (5 minutes)
For all the craftsmen out there, another great reminder that not everything can be solved with code. Joe Schrag talks about the limitations of a pure technical paradigm to problems. The article mentions these are good lessons to prep for senior positions. I’d argue further that they’re critical for staff-level endeavours. You can’t shy away completely from the spotlight; your ideas need to bring business value. I also enjoyed the recursive set of links near the bottom on others who’ve also come to similar conclusions.
6. Well Being in Times of Algorithms (15 minutes)
It’s no secret that the algorithms of the web are designed to suck up your time and attention. Phones help fuel the fire by allowing us access 24/7. I’ve written about my journey in making my phone less distracting before. Simon Späti touches on personal connection, quality time, and the importance of an open web. The AT Protocol itself is an interesting read as well, something I’ve been interested in setting up myself. I really do hope we see a revival of Personal Blogs in the near future.