Programming Leftovers

posted by Roy Schestowitz on May 21, 2023

• Philip Chimento: December of Rust Project, Part 2: The Assembler Macro

  Welcome back! This is the second post of a series which turned out to be more occasional than I thought it would be. You might remember that I originally called it December of Rust 2021. Look how that worked out! Not only is it not December 2021 anymore, but also it is not December 2022 anymore.

• Funny Programming Pictures Part XXXIII

  I feel like mocking CSS and Agile today...

• Mastering File Manipulation with R’s list.files() Function

  Introduction
  When it comes to working with files in R, having a powerful tool at your disposal can make a world of difference.

• [Older] Software Development Ethics

  Computers can do great things for people, but like any other tool, they can also be used for evil.

  So we, as software developers, need an ethical code.

  Basically, it is a commitment that we will not build evil things for evil people. That is, when we sit down to build some software, we always do so with ethical standards. If someone asks us to violate those standards, we refuse or we walk away.

  For this to work, the ethics have to be simple and clear.

  First, no matter how many instructions are executed for any type of automation, the code must always be triggered by humans. Not someone, or anyone, but the actual people involved.

• [Older] Read Every Single Error

  At Pulumi we read every single error message that our API produces. This is the primary mechanism that led to a 17x YoY reduction in our error rate. You’re probably wondering how reading error messages make them go away.

• [Older] On trust in software development

  On the surface, the trust framing seems to be about belonging, or its opposite, exclusion. It implies that if you don't trust your co-workers, you suspect them of malign intent. Organisational dysfunction, it follows, is a Hobbesian state of nature where everyone is out for themselves: Expect your colleague to be a back-stabbing liar out to get you.

• [Older] "Boring" is just one strategy

  With all that said, I think we should challenge these from time to time. I sincerely like "boring": these are prudent approaches to risks many tech companies, especially in the late aughts, run into. My main challenge to this is that these are about risk management and avoiding the floor, rather than reaching for (or breaking) a ceiling. "Boring" is a good strategy if you think the bigger existential risk for your company is that Product & Engineering will flop around, enamored with their cleverness, and fail to ship a reliable product on a reliable schedule. But if you're more afraid of the business risks of shipping average product, at an average cadence, over the course of years, you should consider deviating, at least sometimes, from the playbook whose entire definition is "optimized for safety."

• Expand Contract for Databases and Services | Andy Dote

  I haven’t seen Expand-Contract written about in some years, and I think it is a great way of performing database schema migrations without the need for application downtime. I also realised that it also applies to microservices and service-to-service communication in general.

• You should be reading academic computer science papers - Stack Overflow Blog

  As working programmers, you need to keep learning all the time. You check out tutorials, documentation, Stack Overflow questions, anything you can find that will help you write code and keep your skills current. But how often do you find yourself digging into academic computer science papers to improve your programming chops?

  While the tutorials can help you write code right now, it’s the academic papers that can help you understand where programming came from and where it’s going. Every programming feature, from the null pointer (aka the billion dollar mistake) to objects (via Smalltalk) has been built on a foundation of research that stretches back to the 1960s (and earlier). Future innovations will be built on the research of today.

• Introducing DevPod - Codespaces but Open Source

  If you have used Codespaces before, you know how powerful an automated development environment can be. The downside of CodeSpaces is that you can’t control everything and run your development environment anywhere you want. Have you ever thought - what if I had complete control and could do this on my cloud provider or locally, and what if the tool was Open Source?