/Thought Piece

On Tech Debt: My Rust Library Is Now A CDO

- Armin Ronacher tl;dr: The author describes how they dealt with tech debt in their Rust library caused by a dependency. When the dependency was flagged as insecure by RUSTSEC, users demanded action. Alternatives were unappealing, so the author merged the dependency's code into their own library, effectively "collateralizing" the tech debt and upgrading it from "junk" to "AAA" status. 

featured in #501

The Demise Of Coding Is Greatly Exaggerated

- Murat Demirbas tl;dr: “Natural language is ambiguous and not suitable for programming. LLMs still need to generate code to get things done. If not inspected carefully, this incurs tech debt at monumental speed of the computers. The natural language prompts are not repeatable/deterministic, they are subject to breaking any time. This makes "natural language programming" unsuitable for even small sized projects, let alone medium to large projects.” Murat also believes that certain tasks require too much expertise to be completed by an LLMs as they stand. 

featured in #498

Strings Do Too Many Things

- Hillel Wayne tl;dr: Hillel describes strings as “the most powerful and terrible of all basis types... When you see a string in code, you want to know what kind of string it is. We use these strings for different purposes and we want to do different things to them. We might want to upcase or downcase identifiers for normalization purposes, but we don't split or find substrings in them. But you can do those operations anyway because all operations are available to all strings. It's like how if you store user ids as integers, you can take the average of two ids. The burden of using strings properly is on the developer.” 

featured in #488

Why We Can't Have Nice Software

- Andrew Kelley tl;dr: “The problem with software is that it's too powerful. It creates so much wealth so fast that it's virtually impossible to not distribute it. Think about it: sure, it takes a while to make useful software. But then you make it, and then it's done. It keeps working with no maintenance whatsoever, and just a trickle of electricity to run it.” Andrew discusses the problem this poses on software development. 

featured in #487

Estimates Are About Time, So Let's Cut To The Chase

- Nicole Tietz-Sokolskaya tl;dr: Nicole argues that software engineers, who often estimate tasks using abstract points, should instead estimate directly in units of time. "When we look at large pieces of a product roadmap, we typically need a ballpark understanding of the time and cost." Estimating in time offers clarity and avoids the indirectness of using points as a proxy for time. However, Nicole acknowledges potential pitfalls, such as misuse of time estimates by external parties.

featured in #458

A Student Asked How I Keep Us Innovative. I Don't.

- Nicole Tietz-Sokolskaya tl;dr: Nicole discusses the balance between innovation and using proven technology. The central argument is that while innovation is enticing, it's often more practical and efficient to use established technologies. The author notes, "Most of the time, the problems you run into while doing your work are mundane." Proven technologies offer benefits like robust documentation, established ecosystems, and familiar concepts. However, Nicole also acknowledges situations where innovative tech is necessary, stating, "With the bleeding edge, you are going to get cut, but sometimes that's necessary."

featured in #456

Exponential Value At Linear Cost

- Marc Brooker tl;dr: “Binary search is kind a of a magical thing. With each additional search step, the size of the haystack we can search doubles. In other words, the value of a search is exponential in the amount of effort. That's a great deal. There are a few similar deals like that in computing, but not many. How often, in life, do you get exponential value at linear cost? Here's another important one: redundancy,” which Marc discusses here.

featured in #453

Death By A Thousand Microservices

tl;dr: “It’s a simple question - what problem are you solving? Is it scale? How do you know how to break it all up for scale and performance? Do you have enough data to show what needs to be a separate service and why? Distributed systems are built for size and resilience. Can your system scale and be resilient at the same time? What happens if one of the services goes down or comes to a crawl? Just scale it up? What about the other services that are going to get hit with traffic? Did you war-game the endless permutations of things that can and will go wrong? Is there back pressure? Circuit breakers? Queues? Jitter? Sensible timeouts on every endpoint? Are there fool-proof guards to make sure a simple change does not bring everything down? The knobs you need to be aware of and tune are endless, and they are all specific to your system’s particular signature of usage and load.“

featured in #449

Build And Keep Your Context Window

- Vicki Boykis tl;dr: “When humans have no external context as guardrails, we end up recreating what’s already been done or, on the other hand, throwing away things that work and glomming onto hype without substance. This is a real problem in production data systems. In order to do this, we need to understand how to build one.” Vicki believes that we must understand the historical context of our engineering decisions if we are to be successful in this brave new LLM world.

featured in #448

The Source Of Readability

- Loup Vaillant tl;dr: The post emphasizes the importance of "code locality" in programming, arguing that readability is not merely subjective but is constrained by human limitations such as short-term memory and screen size. The author outlines principles derived from the concept of code locality, including maintaining high cohesion and low coupling, writing less code, avoiding repetition and global variables, preferring composition over inheritance, defining variables close to use, conserving vertical space, and considering inlining variables and functions used only once. Code locality, by aligning with human cognitive constraints, is a fundamental criterion for effective programming.

featured in #439