/Thought Piece

If Inheritance Is So Bad, Why Does Everyone Use It?

- Hillel Wayne tl;dr: Hillel refers to an essay that says that inheritance is harmful and if possible you should "ban inheritance completely... “A lot of these arguments argue that in practice inheritance has problems. But they don't preclude inheritance working in another context, maybe with a better language syntax. And it doesn't explain why inheritance became so popular in the first place. I want to explore what's fundamentally challenging about inheritance and why we all use it anyway.”

featured in #506

My List Of Challenging Software Projects Some Programmers Should Try

- Andrei Ciobanu tl;dr: “The project ideas I am about to suggest are mainly intended for those who are interested in exploring new areas of knowledge. However, it’s important to note that most of these ideas may not be relevant to today’s job market.” List includes lesser known data structures, distributed hash table, scientific calculator, and more. 

featured in #503

Design Engineering

- David Hoang tl;dr: David discusses the emerging role of Design Engineers in software development, drawing parallels to how Data Scientists became a crucial role in the past decades. Design Engineering is a blend of two conventional roles combining deep knowledge of technological systems with the ability to scale interface quality. The three core areas where Design Engineers can lead are: (1) Product architecture (2) Design infrastructure (3) R&D. 

featured in #502

My List Of Challenging Software Projects Some Programmers Should Try

- Andrei Ciobanu tl;dr: “The project ideas I am about to suggest are mainly intended for those who are interested in exploring new areas of knowledge. However, it’s important to note that most of these ideas may not be relevant to today’s job market.” List includes lesser known data structures, distributed hash table, scientific calculator, and more. 

featured in #502

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