Why should a one-function code request name the language version and framework you are on?

## The gap you leave is filled, not flagged A code request is a specification with most of its clauses missing, and the missing clauses still get values. Ask for **one function that parses a fixed-width bank-statement line into a record** and you have said what the function does; you have said nothing about what it has to run inside. That second half is not optional — the answer has to be written in *some* language, on *some* version of it, against *some* framework — so the clauses you leave out tend to be supplied rather than queried. It is supplied from what is most common in code that resembles the request: usually a current major line of the language, the most widely used framework for the job, and whatever third-party helper most people reach for. **Nothing about that guess is unreasonable — it is a guess about a typical project rather than a fact about yours.** A request can come back with a clarifying question instead, and sometimes does; a small, confidently-answerable one more often comes back answered. ## What an unstated environment costs, by how loudly it fails | What you left unsaid | What tends to get assumed | How you find out | |---|---|---| | The language version | A current major line | The build rejects a construct — **loud, cheap** | | The framework | The most popular one for the job | Imports that resolve to nothing — **loud, cheap** | | The framework's major line | Its current shape | A call that exists on another line — loud, or quiet if the name survived and the behaviour changed | | Whether new dependencies are allowed | That they are | An unresolved import with an obvious one-line fix — **quiet in effect**, because taking it is reflexive | | Where the code has to run | An ordinary local process | Production, later — **quiet and late** | The pattern in that last column is the point. **A loud failure costs you one turn**: you read the error, add the missing clause, and ask again. A quiet one costs you a review, and sometimes more than a review, because it arrives as working code that nobody has any reason to look at twice. ## What to put in the request 1. **The language and the version line you are on.** Not the newest one you know of — the one your build actually accepts. 2. **The framework, and its major line**, when the answer will touch it at all. 3. **The dependency constraint**, stated as a closure: this must work with what the project already has, do not introduce anything new. This is the clause people leave out most often and it is the one with the longest tail. 4. **Where it has to run**, if that constrains anything — a background importer and an interactive request are not the same environment even in the same project. That is one or two sentences, written once, at the top of the request. It is the cheapest part of a code request to get right. ## When the request does not have to say it If you are attaching real code — the calling function, the type the result has to match, a neighbouring file — that code often fixes the environment on its own: the syntax dates the language line, the imports name the framework, the style shows the house conventions. The practical rule is not *always state it*; it is **state it, or attach code that proves it**. A bare request with nothing attached proves nothing, so it needs the sentence. The corollary matters too: attached code asserts an environment whether or not you meant it to. An old file from a corner nobody has touched in years tells the request that the old shape is the house shape. ## What naming the environment does not buy you It narrows the answer; it does not guarantee it. - A stated target is an **instruction, not a fence** — the answer can still use something your line does not have. - It can be confidently wrong about what a particular version contains, and most wrong about whatever is most recent. - What the sentence actually buys is **a smaller and more checkable failure**: an answer aimed at a line you named is one you can check against your own build. - It also makes an admission possible. A request with no stated target gives nothing to be unsure about, so uncertainty has no way to show up in the answer. It also buys little on a request where the environment was not the risk. Asking for a pure parsing routine with no framework in sight, from a project with one obvious language, mostly does not need the clause — and the reason to write it anyway is that it costs a sentence and you do not reliably know in advance which requests are the ones that needed it. ## Answering this in an interview Say what gets filled in, and by what. The strong answer is mechanism-first: *the request under-specifies the environment, the gap is filled from what is most common rather than from my project, and the expensive version is the mismatch that compiles.* Then give the rule with its exception — state it, unless the attached code already proves it — and say what you still do afterwards, which is read what the answer assumed rather than only whether it ran.