I disagree with almost everything in this article, especially the premise. Technical debt is just an added cost of maintenance and development over time, like an "interest" paid in terms of work hours. It doesn't matter if the developers have knowledge about it - a company with lower technical debt will develop the same feature faster, because they're not fighting the existing code base as much.

Most of the technical debt I've been forced to create has been with the knowledge of better ways from the get-go. We just chose a worse design for short-term gains (time to market / ran out of money) and realize we have to pay with a higher development cost in the long term. It's very much like taking out a loan to deliver faster.

I hate it, but in economics a company is not considered to leverage all its potential unless it takes on some debt - a debt free company moves too slowly to be competitive. The same applies to technical debt. You can have too much of it but you can also have too little. It's a strategic choice.

Really strange. What industry have you seen this in.

In big tech, enterprise, biotech, every team I've been on has uniformly understood that technical debt is just a concept of future work that is intentionally put off to focus speed, exploration or some other reason. It's used in strategic planning to determine the cadence of output.

Aside from new grads this has never been a concept I've had to explain to an engineer or pm. Not like a sometimes thing. Literally never. Just very strange.

It is only ever a negative. It's just that sometimes some other factor is worse, maybe time-to-market is far more important in some case.

I am curious who speaks of technical debt as only a negative. I've never worked on an engineering or product team that didn't understand the meaning of the term.

Modern software is built on towers of abstractions, each one making development "easier" while adding overhead:

Today’s real chain: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. Each layer adds “only 20–30%.” Compound a handful and you’re at 2–6× overhead for the same behavior.

That's how a Calculator ends up leaking 32GB. Not because someone wanted it to—but because nobody noticed the cumulative cost until users started complaining.

Man, this is so true. What sucks even more is that so many devs now don't know how to build anything BUT this stack.

Accept that quality matters more than velocity.

Tell that to the VC money you got to fund everyone's paychecks. It's a race to get traction before you run out of money. Velocity will always trump quality if a startup wants to survive.

I had recently tried one such app. It was so poorly written, and had the type of UI scaling issues you would believe to be written by a toddler. The app would've been cool if it worked but seeing the state of the app I deleted it not to risk my personal data even though it was offline.

Thanks, I'll have a look at quilt. There's also a git command called quiltimport which may be helpful if I want to stay on git.

If you're using linux then check if quilt is available for your distro, it's made specifically to maintain patches on top of a codbase you don't control: https://wiki.debian.org/UsingQuilt

Real time is a privacy risk.

check the API rules

That was what I was wondering about above. For Bgpview I can't find much.

Theoretically, you could do it in real-time and cache it.

I think it would be important to check the API rules of w/e service you're using.

https://www.enjen.net/asn-blocklist/readme.php#api

Some CDNs I believe can already do it like cloudflare. But I havn't tested it myself, but I have seen ASN block pages through them in the past.

So is it only me, or wouldn't it be possible to write a script that 1. gets the ASN list from some place like here https://bgpview.io/reports/countries/GB and then 2. queries the list of IP ranges from here https://www.enjen.net/asn-blocklist/index.php?asn=&type=iplist and 3. commits that to a repository on Github or such, and the script could be rerun every two weeks or so? It seems like there are no terms of use attached to any of these two services that forbid this, but does anybody know?

Should be easier to block them by ASN instead of IP. That way you can control ipv6 connections too.

But if you don't do business with the UK, I wonder if you are allowed to ignore them?

Have you considered asking OFCOM?

If there responsible for enforcement, they may offer resources or information. Otherwise they should get informed of the need.

It’s refreshing to have a nice reply online! Thank you, too. :)

Yes you're probably right, I definitely have bias and the time spent tryna fix the bug influenced this..

Thanks

To add to my own comment, I want to remind you that JavaScript was designed to power websites, and having an entire website break because an array didn’t have anything in it yet is probably worse than the alternative.

A lot of JS’ decisions actually make sense when you understand its history. That doesn’t mean it’s a great language, but it’s undeniably good at fulfilling its original purpose, making websites interactive in myriad different browser implementations.

I’m sorry but your problem here is solely with JavaScript, not TypeScript. TS is right to assign that type to the value, because that is perfectly valid JS, and that is the type you should expect.

It’s not hard to check for undefined and there are absolutely times you wouldn’t want an error to be thrown, so this is just you having a preference, and judging an entire language based on your preference.

There are actual reasons to dislike how JS works, out of bounds array access returning undefined is not one of them.

You have two options depending on how you set your Typescript config.

Option 1, the default:

declare const xs: number[]
const x = xs[4] // inferred type is `number`

Option 2, using the noUncheckedIndexedAccess setting:

declare const xs: number[]
const x = xs[4] // inferred type is `number | undefined`

Your AI assistant appears to assume option 2. Maybe you have that option enabled in your project?

I'm sorry you had to spend a lot of time and frustration on this problem. But fundamentally Rust and Typescript have the same limitation: neither will catch out-of-bounds access errors on variable-length collections at type-checking time. They don't have the necessary information to do that.

Rust can catch out-of-bounds access on a fixed-length array if you use a literal number for the index access. But Typescript can do the same thing if you use a fixed-length tuple type (e.g. [number, number] instead of number[]).

I don't really get what you're saying. JS doesn't throw on out-of-bounds array access and instead returns undefined, even in Strict mode. Obviously TypeScript needs to match the actual behavior with the typing.

const arr = [];
arr[5]; // undefined

I'm having trouble following the example the LLM generated for you in your screenshot...I'm not terribly familiar with TypeScript but MyUnionType should be a union of types and instead it seems to be a union of...1 or 2?

maybe you can share some example code of the unexpected behavior that you wrote, rather than something the fancy random number generator wrote?

You might like Purescript (purescript.org) though I thing it may have slowed down since Typescript took over.

Could be that I misread but I think you're misunderstanding types in Typescript.

You have an array of 1 or 2 values of unbounded size. You put two values in but could have put 1000 in, your type doesn't say anything about that. You can only put ones or twos in there though.

I think your first line is equivalent to saying:

type MyStringType = string[];

I haven't checked though so I might be wrong..