If I have a set of requirements that don’t mention any type of restriction, then I won’t arbitrarily add one - as far as I know, I could be breaking intended functionality. If I’m invested in this, I’ll add it to the list of stuff that needs clarification, otherwise it’s gonna ship as specified, and eventually someone’s gonna file a change request.
Sincere question, are you not expected to clarify questionable business rules? I’ve never worked somewhere that leaving such an obvious issue like “unrestricted fields in a public-facing application” without getting it explicitly stated that that’s intended functionality wouldn’t have gotten me fired instantly.
Look around you, you’ll find “unrestricted fields in a public-facing app” (from a practical perspective) everywhere. Shrek’s script has what, less than 50k characters? That’s nothing, you can fit that in a Facebook post and still have more than enough to write a full movie review.
Where this would likely raise flags is when somebody decided that it needs to be printed, but that could be a different team, maybe outsourced, maybe after the main app was developed, maybe it’s just some “plug-and-play” system that also handles bulk printing jobs, who knows.
I wasn’t really referring to this post with that question - though it is relevant that leaving even an effectively unconstrained field like one that allows for the shrek script to be submitted would have seen me fired (if it had somehow passed QC, field sizes are one of the first things checked).
I was more curious about how different our experiences seem to be: you seem to imply a background where you’re expected to take the requirements as gospel with what you write based solely off that unless you’re personally invested, whereas in my experience engaging critically with the project is the single most important aspect of the development process, and not questioning potentially unwanted behavior leaves you open to firing (or criminal neglect if you’re dealing with medical PII, criminal records, etc…)
I’m quite genuinely interested in the different approach to development philosophy you present here.
Yeah, sleepy and wasn’t thinking about file sizes. That 1Gb limit (or, the Tsql 65,536 * [something] limit) was what I was referring to, but rather obviously the plaintext script for the movie is a just a little tiny bit smaller than that (51kb).
It’s still a good deal larger than what in my experience can be fit into a receipt printer, but I can forgive their phrasing even if it was only a small part of the whole script. And aside from that, it does look to be a pretty modern device so it’s very possible that the stupid stupid 20kb file size limit that was so common has since been expanded (Last time I had to deal with a receipt printer the file was streamed over a serial connection into the printer cache before being run off G-code style. Incredibly charming piece of tech…)
Meh, not that hard to default things to “string”, or similar. For example, the “text” type in PostgreSQL explicitly says “unlimited”, though it seems it’s up to 1Gb. See https://www.postgresql.org/docs/current/datatype-character.html
Similarly, it’s not like text fields on web pages automagically apply limits.
It’s not unimaginable that some dumbass could vibe-code themselves up an easily exploited form.
100% accurate, though vibe coding is optional.
If I have a set of requirements that don’t mention any type of restriction, then I won’t arbitrarily add one - as far as I know, I could be breaking intended functionality. If I’m invested in this, I’ll add it to the list of stuff that needs clarification, otherwise it’s gonna ship as specified, and eventually someone’s gonna file a change request.
Sincere question, are you not expected to clarify questionable business rules? I’ve never worked somewhere that leaving such an obvious issue like “unrestricted fields in a public-facing application” without getting it explicitly stated that that’s intended functionality wouldn’t have gotten me fired instantly.
Look around you, you’ll find “unrestricted fields in a public-facing app” (from a practical perspective) everywhere. Shrek’s script has what, less than 50k characters? That’s nothing, you can fit that in a Facebook post and still have more than enough to write a full movie review.
Where this would likely raise flags is when somebody decided that it needs to be printed, but that could be a different team, maybe outsourced, maybe after the main app was developed, maybe it’s just some “plug-and-play” system that also handles bulk printing jobs, who knows.
I wasn’t really referring to this post with that question - though it is relevant that leaving even an effectively unconstrained field like one that allows for the shrek script to be submitted would have seen me fired (if it had somehow passed QC, field sizes are one of the first things checked).
I was more curious about how different our experiences seem to be: you seem to imply a background where you’re expected to take the requirements as gospel with what you write based solely off that unless you’re personally invested, whereas in my experience engaging critically with the project is the single most important aspect of the development process, and not questioning potentially unwanted behavior leaves you open to firing (or criminal neglect if you’re dealing with medical PII, criminal records, etc…)
I’m quite genuinely interested in the different approach to development philosophy you present here.
These ‘unlimited’ scams are getting out of hand. All I wanted was to store the library of alexandria in plain text.
Yeah, sleepy and wasn’t thinking about file sizes. That 1Gb limit (or, the Tsql 65,536 * [something] limit) was what I was referring to, but rather obviously the plaintext script for the movie is a just a little tiny bit smaller than that (51kb).
It’s still a good deal larger than what in my experience can be fit into a receipt printer, but I can forgive their phrasing even if it was only a small part of the whole script. And aside from that, it does look to be a pretty modern device so it’s very possible that the stupid stupid 20kb file size limit that was so common has since been expanded (Last time I had to deal with a receipt printer the file was streamed over a serial connection into the printer cache before being run off G-code style. Incredibly charming piece of tech…)