/Thought Piece

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

Monitoring Is A Pain

- Mat Duggan tl;dr: “I have a confession. Despite having been hired multiple times in part due to my experience with monitoring platforms, I have come to hate monitoring. Monitoring and observability tools commit the cardinal sin of tricking people into thinking this is an easy problem. It is very simple to monitor a small application or service. Almost none of those approaches scale.” The article suggests several recommendations for improving the monitoring process.

featured in #430

Generating Code Without Generating Technical Debt?

- Reka Horvath tl;dr: GPT and other large language models can produce huge volumes of code quickly. This allows for faster prototyping and iterative development, trying out multiple solutions. But it can also leave us with a bigger amount of mess code to maintain… This article explores several ways how to improve the code generated by these powerful tools and how to fit it into your project.

featured in #429

The Rise Of The AI Engineer

tl;dr: “Every startup I know of has some kind of discuss-ai Slack channel. Those channels will turn from informal groups into formal teams, as Amplitude, Replit and Notion have done. The thousands of Software Engineers working on productionizing AI APIs and OSS models, whether on company time or on nights and weekends, in corporate Slacks or indie Discords, will professionalize and converge on a title - the AI Engineer. This will be the highest-demand eng job of the decade.”

featured in #428

Plain Text Journaling

tl;dr: “I cobbled together a journaling system with {neo,}vim, coreutils and dateutils. This system is loosely based on Ryder Caroll’s Bullet Journal method.” The author gives us a demo.

featured in #424

Tech Debt Metaphor Maximalism

- Avery Pennarun tl;dr: Tech debt is compared to financial debt in a blog post, highlighting the distinction between high-interest shortcuts and low-interest strategic decisions, while emphasizing the importance of managing debt within defined limits and evaluating its impact on the project's sustainability.

featured in #421