Strange thing is that photo albums re relatively new. Imgur was the go-to host for Reddit, and then they made their own uploader a looong time later. The "albums" functionality only came out in July of 2020, according to a Google search.

Seems this was less likely a "someone else will deal with it" problem, and more of a development / QA testing problem.

For some reason most stuff still defaults to i32 and a lot of people use them for new code. At this point I'd not be against linters warning against using 32 bit ints unless you have a good reason.

My alma maters vending machines used an unsigned integer for understanding school debt card balance. However the school debt card used a signed integer to allow for small negative balances.

Well students uncovered the flaw and had their cards be at negative 1 dollar, which the vending machine read as a very large balance.

What I don't get is why you'd want a signed int for an id.

They're still a good choice for most perf critical code due to the reduced memory use.

I’m pretty sure the table in question stores image metadata for all user uploaded images. As well as images scraped from posted links which goes back way before images in posts

A new feature but it wasn’t built on a new codebase. Reddit is a monolith and a lot of things users think of as different “entities” live in the same set of tables.

Someone probably joked they would never reach that scale when they wrote that code

Thinking "if that ever gets anywhere close to a problem we'll have vast resources and plenty of time to fix it" and then, I'm guessing, that person left a few months later and nobody owned that part of the code because it worked.

Then 10 or so years went by...

Whenever I write code like that which may break in say, 5 years, I'll sign it in the comments and put my personal email and phone number inviting future people to call me and I'll fix it for free (cause I take responsibilities for my code pretty seriously). Nobody has ever taken me up on it though...

To people reading this: please never ever do that, unless it was agreed upon with your client/employer beforehand (and compensated accordingly).

If you know the code may break in 5 years, why don't you fix it now? Because your employer doesn't want to pay you to do that (probably for good reason, surely there's higher priorities).

Then why would you do it for free years later?

I'm fairly certain most managers would argue that I'm wasting my time if I spend it chasing bugs that won't happen for several years.

Sometimes it's because they don't know it will break in 5 years. They weren't anticipating exponential growth and when they started, the i32 range was a thousand times more than they needed. Ten more doublings later ...

No.

You can say, anticipate breaking changes that is calendared to happen as an eventually rollover or deprecation

Essentially things have to work one way now and there's solid reason to think it will no longer work that way later and there's no valid path to fix because exogenous conditions change.

This alternatively, can be done in bad faith to guarantee a future paycheck by intentionally placing timebombs in and then charging high rates to come back. There's incentives for abuse.

I'm making it clear and acting in good faith. I can give them 2 hours for free in 5 years, whatever. I'm a competent and responsible person and I get paid well by not being so cheap.

We're not talking about working in bad faith, that's bad obviously. But there's no reason for most people to give away even 2 hours of their time for free. If you're working as a freelancer and it's your way of building a portfolio of clients, that's a good reason to give away those two hours. But I'd rather not have someone with little work experience read that, think it's reasonable, and apply it themselves.

In my first year of university I was working for a very small web company. I got paid per website an amount that was enough for my student needs, nothing much. I wasn't a very good developer in my 1st year, so I often received emails about bugs in past projects. The bugs were my fault, so naturally I fixed them in my own free time.

It took me 2 years to see how badly I was getting owned by the company. If they wanted less bugs, they should have asked someone with experience and a much higher salary.

The employer also shouldn't take you up on the offer because now you are engaging in work without a contract, which opens up contract issues, probably breaks things like SOC compliance, etc.

I like your accountability, but it's sufficient to document the issue in code, open a jira (or equivalent) and move on.

Oh god, bad memories. You reminded me of a guy I worked with who wrote absolutely terrible, unsafe code and when called out said they are 'caviar problems.'

When I asked what in the hell a caviar problem was, he said it meant by the time we had to worry about those things, we'd all be so rich we'd be eating caviar.

The reality is that some other person brought in later that is not rich will have to fix it. What a jerk.

Good practice would be leaving a comment with a TODO, an explanation of the problem, and some basic instructions as to a possible fix.

Leaving your email and phone number is absurd and should not be promoted as good practice. No sane company would take you up on the offer anyway.

And they weren't even wrong! The challenge is addressing the tech-debt, not the choice to incur it.

That's maybe a reasonable thing to do if you're an independent business selling the code, but it's a scab move if you're doing that as an employee. Never work for free.

Probably sufficient to write a test that will break in 5 years - X [days|months] with notes in the test about the problem and how to fix

Hm. I wonder why no one ever called you.

Because there's a dumb culture of treating people who left like they're from beyond the grave where you have to divine their intentions like some programming ouija board.

I broke that unspoken rule and got a really intractable problem that held us up for days finally fixed by making a short phone call early in my career and told myself if I was ever causing what we were going through I'd want to make it clear that I'm open to that rule being broken as well.

Apparently even suggesting such a rule should be questioned and to try human solutions to human problems is met with mockery and disdain. Alright, cool.

It's bold. I'm sure if one of those time bombs went off, the call might not be to ask for help, but to impolitely complain.

Why would you write something that might break in 5 years? Why not just use a 64 bit integer in any situation like this an be done with it?

So you migrate to int64 and one day someone will wonder why the hell did we ever think no one would reach 2^64 rows in a database table. Or that 2^128 IP addresses would be enough for everyone.

“32-bit IPv4 addresses to 128-bit IPv6 addresses means going from 4.3 billion to 340,282,366,920,938,463,463,374,607,431,768,211,456”

Yes 128 bits is only 4x times the bit length, but the address space is exponentially bigger.

Some predict if we do run out, it might take ~100 years.

> Some predict if we do run out, it might take ~100 years.

You think we can use 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses in 100 years? Thats ... ahem, ambitious!

In practical terms, IPv6 is arranged as a 64 bit subnet ID and 64 bit device ID.

And the subnets are in a hierarchy that helps with routing but limits the packing efficiency.

We could feasibly "run out" to the point that we can't keep doing things this way.

The truth is that the address space is extremely sparse. Every ipv6 subnet is a /64 by default, yet I’m sure most of us have vastly fewer than 2^64 machines in our networks … at least for now

In my experience, you first do an emergency re-seed to use the negative half of the int32 space.

Been through it twice in my career…

Those numbers are much, much larger than 2^32.

No process that touches the real world gets into 2^64. No process at all gets into 2^128, at lwast not while we live around a single star.