Knowledge Work Isn't an Assembly-Line
[I]f I hire a programmer, how fast should I expect him/her to work? How much work should I expect he/she does in a day or week?
This is always the wrong set of questions, because it is based on the outdated notion that knowledge work is similar to assembly line production. It isn't.
Instead, you should be evaluating people based on their ability to deliver business value and meet objectives within their own skill envelope. You can do this with target-based assessments, individualized assessments, or a combination of the two.
The only real way to evaluate knowledge workers is outcome-based measurements. In my experience, there are two types of outcome-based metrics:
For this usage, a (management) target is a goal or deadline set by fiat. If you have three months to deliver a product or feature, then you should staff your project with people who are confident they can deliver within your target time-frame, and who you believe can get the job done when you need it. Both sides need to maintain transparency for this to work.
Of course, that means that you can't hire mediocre people to meet aggressive time frames. It also means you need to remain aware of the distinction between "confidence" and a guaranteed outcome. In knowledge work you will never have the latter, even if it's contractually stipulated. Ask a separate question if you're not clear on why this is true.
Target-based assessments and estimates also require exceptional communications, clear specifications, well-delineated scope, effective work breakdowns, and deep domain expertise. This costs time and money. In my experience, the more target-driven a project, the more it will cost you; however, your mileage may vary.
Rather than comparing people to other people, you measure people against their own skills and experience. A job that might take a domain expert 30 days might take a novice or journeyman months, so you have to rely on the trend lines for each person rather than estimating based on someone else's knowledge and experience.
You get what you pay for, so you can't necessarily hire the cheapest labor pool possible and expect a stellar outcome. While price doesn't guarantee results, there is certainly a correlation between skills/experience and labor costs, so your budget must reflect the level of abilities that you want to staff for on your project.
With individualized assessments, you need to get the estimates directly from the task performers. No one else can estimate how long it will take that person to do a task, because it is based on their knowledge and experience. Your management levers are limited to holding task performers accountable for their estimates, and choosing staff (or replacing them) based on whether or not reasonable results can be obtained from a given skill set.
Continuous feedback and open communications are not levers, but they can certainly optimize the process. For this model, think "planning effectiveness" rather than delivery speed. That will deliver the best possible results from the resources you have, and is often a more sustainable approach from a cost perspective.
In more pragmatic terms, you can either staff your project to meet pre-set deadlines, or schedule your project to deliver based on the skills and abilities of the people you have. Both can work, but the latter is generally more reliable over time.
Management Owns the Risk
In all cases, management owns the risk. If a plan is created without input from the task performers, there is inherent risk that the project will be mis-estimated. Alternatively, if targets are unreasonable or sufficient budget/skill is not brought to bear on the objectives, management owns that risk too.
In other words, you can set expectations through effective two-way communication (or by diktat, if you're so inclined), but you can't flog the programmers to work faster. If you don't currently have the skill set in-house to accurately estimate the project's scope and schedule, then you will have to hire resources you trust to deliver at their best possible speed.