31:T79a,Acemoglu and Johnson's *Power and Progress: Our Thousand-Year Struggle Over Technology and Prosperity* (2023), after some introductory remarks on how "technological progress" can have vastly differing consequences for different groups of people within a society, quickly "cracks open the can" on a concept used throughout the remainder of the book, and a concept that will become crucial in this class as well after the Midterm! Specifically, on page 16, the book points out how two ways of **measuring** worker productivity that may seem similar at first glance — _average_ productivity vs. _marginal_ productivity — are in fact worlds apart in terms of their relationship to progress: > *Contrary to popular belief, productivity growth need not translate into higher demand for workers. The standard definition of productivity is average output per worker — total output divided by total employment. Obviously, the hope is that as output per worker grows, so will the willingness of businesses to hire people. But employers do not have an incentive to increase hiring based on average output per worker. Rather, what matters to companies is **marginal productivity** — the additional contribution that one more worker brings by increasing production or by serving more customers. The notion of marginal productivity is distinct from output or revenue per worker: output per worker may increase while marginal productivity remains constant or even declines.* (Acemoglu and Johnson 2023, pg. 16) We'll draw on many parts of the remainder of the book going forward, so the goal of this notebook is to serve as a resource for quickly "reminding ourselves" of the difference between average and marginal productivity, and the importance of this difference for [as just one of many possible examples] understanding why even "perfect prediction" in hiring may not only involve but in fact **necessitate** gender discrimination in hiring...32:T5ea,### First Key Assumption: Profit Maximization The "pieces" of the hiring model in this notebook are in fact not so different from the framework we already used in our notebook exploring [confusion-matrix-based fairness definition](https://observablehq.com/@jpowerj/fairness-definitions): Here, in place of an algorithm (or a judge) predicting whether or not an individual is "high-risk" or "low-risk" with respect to committing a crime in the next two years, the "algorithm" is a **hiring manager** and the "prediction" they're trying to make is whether or not to hire someone. Phrasing this last part as "whether or not to hire someone" sweeps a lot (pretty much everything) under the rug, though! The reason why this notebook starts with a quote from two economists, and why we need a whole notebook to "sharpen" our common sense around this problem, is because we need to think of our model as embedded into a broader decision-constraining system which determines the factors a company can and cannot^\[1\] incorporate into their hiring decisions. In this case, since we're at a university in the US and thus "by default" interested in constraints on hiring decisions in the US setting, we can bring in the (**descriptive!**) notion of [shareholder primacy](https://corpgov.law.harvard.edu/2017/04/11/a-legal-theory-of-shareholder-primacy/) to buttress our assumption that **companies make hiring decisions to maximize the profits accruing to their shareholders**.33:Ta8f,### The Profit-Maximizing Hiring Decision With this "axiom" laid down as the antecedent for our model, we then ask: > **What hiring decisions maximize profits?** To derive an answer to this, we can use another basic "axiom"/definition from microeconomics, that ${tex.block` \text{Profit} = \text{Revenue} - \text{Cost} \tag{1} `} And we'll assume that the company is already (meaning, before launching the interviewing+hiring process) making some level of revenue per unit of time ${tex`r_0`}, at some cost required to generate that revenue ${tex`c_0`}, so that in making their hiring decision they're considering how this decision could impact their overall profit per unit of time ${tex`\pi_0 = r_0 - c_0`}. In this case, if we think of a given hiring decision for a candidate ${tex`i`} as the choice of a value for a Random Variable ${tex`D_i`}: ${tex.block` D_i = \begin{cases} 1 &\text{if }i\text{ is hired} \\ 0 &\text{if }i\text{ is not hired}, \end{cases} `} Then we can model the decision to hire (the choice of a value for ${tex`D_i`}) by analyzing the effect of this choice on each term in ${tex`(1)`}: * If the company chooses to **hire** ${tex`i`} (chooses ${tex`D_i = 1`}), they will receive some new level of revenue ${tex`r_1`} but will have to pay ${tex`i`} a wage ${tex`w`}, increasing their level of costs from ${tex`c_0`} to ${tex`c_0 + w`}. In this case, their overall profit level will be ${tex`\pi_1 = r_1 - (c_0 + w)`}. * If the company chooses **not** to hire ${tex`i`} (chooses ${tex`D_i = 0`}), they will continue receiving their current revenue ${tex`r_0`}, and won't have to pay the wage ${tex`w`} to ${tex`i`}. Thus their profit level will be the same as before they launched the hiring process, ${tex`\pi_0 = r_0 - c_0`}. Since these two quantities (revenue and cost) were assumed above to be the two determinants of the profit level ${tex`\pi`}, we can write out the profit-maximizing decision as a *function* of the choice ${tex`d`} for ${tex`D_i`}: ${tex.block` \begin{aligned} \text{Choosing }D_i = 1\text{ maximizes profits } &\iff \pi_1 - \pi_0 > 0 \\ &\iff r_1 - (c_0 + w) - (r_0 - c_0) > 0 \\ &\iff r_1 - c_0 - w - r_0 + c_0 > 0 \\ &\iff r_1 - r_0 - w > 0 \\ &\iff \underbrace{r_1 - r_0}_{\Delta\text{ revenue}} > w \end{aligned} `} In other words (as most intro econ textbooks just immediately jump to, but I like writing out explicitly in this way to make all the assumptions and calculations explicit), > **The decision to hire an individual ${tex`i`}, relative to not hiring them, is profit-maximizing if and only if the amount by which ${tex`i`} *increases* revenue is greater than the amount that will be paid to ${tex`i`} in wages, ${tex`w`}.**34:T448,### The Last (Modeling) Step: Multiple Candidates The remaining issue we care about is: the Acemoglu and Johnson quote discusses the difference between the **average** and **marginal** products of labor, but since we've only modeled one candidate above, thinking about the "average" contribution doesn't make much sense yet. The difference between these two quantities only becomes apparent once we model a company considering **multiple** candidates, and looking at what the above model implies in terms of choices made by the company with respect to ${tex`n`} hiring decisions. Consider an example where **three** candidates are interviewing for a **cashier** position which pays a wage of ${tex`w = \$15`} per hour^\[2\]: * Hiring Candidate 1 increases revenue by **$20 per hour**, * Hiring Candidate 2 increases revenue by **$5 per hour**, and * Hiring Candidate 3 increases revenue by **$50 per hour**. This means that, for example, we can imagine the hiring manager working with the following 3-row `.csv` file (boring, but it does the job!):35:T57a,resultForm = Inputs.form({ row0: columns({ c1: viewof hire1, c2: viewof hire2, c3: viewof hire3, }), row1: columns({ revCol: Inputs.form({ revCol0: md`Revenue before hiring was **\$${globs.baseRev}/hr**`, revCol1: hire1 ? md`Hiring Candidate 1 **added \$${candidateData[0].rev_increase}/hr** to revenues` : md``, revCol2: hire2 ? md`Hiring Candidate 2 **added \$${candidateData[1].rev_increase}/hr** to revenues` : md``, revCol3: hire3 ? md`Hiring Candidate 3 **added \$${candidateData[2].rev_increase}/hr** to revenues` : md``, revColTotal: centerCell({ orig_cell: md`**Total revenue: \$${totalRev}/hr**`, }), }), costCol: Inputs.form({ costCol0: md`Cost before hiring was **\$${globs.baseCost}/hr**`, costCol1: hire1 ? md`Hiring Candidate 1 **added \$${globs.wage}/hr** to costs` : md``, costCol2: hire2 ? md`Hiring Candidate 2 **added \$${globs.wage}/hr** to costs` : md``, costCol3: hire3 ? md`Hiring Candidate 3 **added \$${globs.wage}/hr** to costs` : md``, costColTotal: centerCell({ orig_cell: md`**Total cost: \$${totalCost}/hr**`, }), }), }), row2: centerCell({ orig_cell: Inputs.form({ profitRow: md`**Overall profit:** \$${totalRev}/hr - \$${totalCost}/hr = **\$${totalProfit}/hr** ${profitMessage}`, }), border: true, }), })36:T4b2,### The "Brute Force" Solution By checking each possible combination of boxes, you can discover all ${tex`2^3`} possible profit levels, which we'll outline here for completeness: **If no candidates are hired,** we have the original profit level of $5/hr: * ${tex`\small\pi(0,0,0) = 15 - 10 = 5`} **If one candidate is hired,** the possibilities are: * ${tex`\small\pi(1,0,0) = (15 + 50) - (10 + 15(1)) = 65 - 25 = \$40`} * ${tex`\small\pi(0,1,0) = (15 + 10) - (10 + 15(1)) = 25 - 25 = \$0`} * ${tex`\small\pi(0,0,1) = (15 + 20) - (10 + 15(1)) = 35 - 25 = \$10`} If **two candidates are hired,** the possibilities are: * ${tex`\small\pi(0,1,1) = (15 + 10 + 20) - (10 + 15(2)) = 45 - 40 = \$5`} * ${tex`\small\pi(1,0,1) = (15 + 50 + 20) - (10 + 15(2)) = 85 - 40 = \$45`} ✅ *(Maximized!)* * ${tex`\small\pi(1,1,0) = (15 + 50 + 10) - (10 + 15(2)) = 75 - 40 = \$35`} And if **all three candidates are hired**, the profit level is: * ${tex`\small\pi(1,1,1) = (15 + 50 + 10 + 20) - (10 + 15(3)) = 95 - 55 = \$40`} So, from among all these choices, we can see that **hiring Candidate 1 and Candidate 2, but not candidate 3**, is the profit-maximizing choice available to the firm.37:T763,### The "Optimal" Hiring *Algorithm* ...But hopefully you can see a pattern here, especially if you imagine expanding to more and more workers. The following "greedy" selection procedure will always lead the company to its profit-maximizing choice: 1. Rank all candidates by the **amount by which they will increase revenues**. If the candidates being considered are indexed by ${tex`i \in \{1, 2, \ldots, n\}`} (for example, if these are their row numbers in some `.csv` file of applicants available to the hiring manager), then let ${tex`\mathbf{w}`} be a vector containing these indices in descending order by this revenue-increase amount: The first element of ${tex`\mathbf{w}`} will be the index of the candidate who would increase revenue the most, the second element will be the index of the candidate who would increase revenue second-most, and so on. 2. Take the first candidate in ${tex`\mathbf{w}`}: If that candidate would increase revenue by **more than ${tex`w`}**, hire them and remove them from ${tex`\mathbf{w}`}, then repeat this step. Otherwise, terminate. You can see the workings of this procedure in the plot generated by the following cell: Once the candidates here are ordered based on how much they will increase revenue, you'll see that you can never "beat" this two-step procedure by any method besides **hiring the ordered candidates one-by-one until you reach a candidate for whom the cost of hiring would be greater than the increase in revenue...** The "manual" usage of the three checkboxes we provided above, therefore, was unnecessary: we can construct the following **static** plot, wherein the ${tex`x`}-axis represents exactly the optimal ordering of choices: the first "tick" corresponds to the values indicated by the legend after hiring the **first-ranked** candidate, the second corresponds to the **second-ranked** candidate, and so on.38:T672,Plot.plot({ height: 320, width: 600, x: { domain: [0,3], interval: 1, tickFormat: 'd', grid: true, }, y: { domain: [0, d3.max(combinedData, d => d.value)], // interval: 1, grid: true, label: "$", }, color: { legend: true, }, // stroke: { // legend: true, // }, // strokeWidth: { // legend: true, // }, symbol: { legend: true, // domain: [false, true], // range: ["a","b"], // label: ["a","b"], domain: ["Hired", "Not Hired"], range: ["plus", "times"], // fill: "green", // stroke: "red", strokeWidth: 2, }, marks: [ Plot.line(combinedData, { x: 'rank', y: 'value', stroke: 'vname', }), Plot.dot(combinedData.filter(d => d.vname != "Revenue Increase"), { x: 'rank', y: 'value', stroke: 'vname', fill: 'vname', }), // https://observablehq.com/plot/marks/dot#dot Plot.dot(combinedData.filter(d => d.vname == "Revenue Increase"), { x: 'rank', y: 'value', // fill: 'hired', // stroke: 'hired', symbol: 'result', // fill: 'result', fill: (d) => d.hired ? "green" : "red", // stroke: 'result', stroke: (d) => d.hired ? "green" : "red", // strokeWidth: (d) => d.hired ? 2 : 1, strokeWidth: 4, r: 5, // symbol: (d) => d.hired ? "triangle" : "times", // symbol: (d) => d.hired, }), Plot.ruleY([{wage: globs.wage, label: "Wage"}], { // legend: true, y: 'wage', // label: "label", stroke: () => "Wage", strokeWidth: 2.5, strokeDasharray: [6], }), ], })39:T475,profitData = { let profitVals = [ {rank: 0, vname: 'Profit Level', value: globs.baseRev - globs.baseCost, hired: NaN}, ]; let revTotals = [ {rank: 0, vname: 'Total Revenue Increase', value: 0, hired: NaN}, ]; let revMeans = [ {rank: 0, vname: 'Mean Revenue Increase', value: NaN, hired: NaN}, ]; for (let i = 0; i < candidatesSorted.length; i++) { let lastProfitVal = profitVals[i].value; let curCandidateData = candidatesSorted[i]; let curRevIncrease = curCandidateData.rev_increase; let curCandidateProfit = lastProfitVal + curRevIncrease - globs.wage; // Cumulative means profitVals.push( {rank: i + 1, vname: 'Profit Level', value: curCandidateProfit}, ) let lastRevTotal = revTotals[i].value; let curRevTotal = lastRevTotal + curRevIncrease; revTotals.push( {rank: i + 1, vname: 'Total Revenue Increase', value: curRevTotal, hired: true} ); revMeans.push( {rank: i + 1, vname: 'Mean Revenue Increase', value: curRevTotal / (i + 1)}, ); } let combinedProfitVals = [ ...profitVals, ...revMeans, ]; return combinedProfitVals; }3a:T90d,### Quick Sidenote: The "Standard" Hiring Model It's worth noting that the way I've formulated the hiring procedure above is **not** exactly the "standard" model that would be used e.g. in an introductory microeconomics textbook, because here I specifically wanted to highlight how we can model **heterogeneous** applicants, in the sense that each candidate we considered above has a different level of contribution to revenues. The "standard" textbook model doesn't get us very far in this direction, since it assumes that candidates are **homogeneous** in terms of their contribution to revenue. Meaning, in that model, every candidate has the *potential* to contribute some fixed constant amount ${tex`x`}/hr to revenue, but then (to "capture" the fact that employers stop somewhere, instead of hiring infinitely-many workers) it's assumed that there are **decreasing returns** to hiring more and more people. For example, if we assume a "coordination cost multiplier" ${tex`\delta \in [0,1)`}, then the first hired worker might contribute ${tex`x`}/hr to revenue, the second might contribute ${tex`(\delta x)`}/hr, the third ${tex`(\delta \cdot \delta)x`}/hr, and so on, so that eventually the contribution of the **next** worker is low enough to no longer offset the fixed wage ${tex`w`}. For an example of this "textbook model" approach, see the [Khan Academy video](https://www.youtube.com/watch?v=8fm9FjDV0iA) on **total, marginal, and average products of labor**. In that video, he discusses the coordination cost multiplier as essentially a "too many cooks in the kitchen" scenario, where at a certain point you've hired so many workers that **coordinating** their tasks becomes so costly that it starts to decrease your profit margins, and that's the point at which you stop hiring. But, I hope it's clear that across both of these models (Khan's model of homogeneous candidates with decreasing returns to number-hired, and the model here of hetereogeneous candidates ranked by contribution to revenue), hiring "stops" at the point where the ${tex`k`}th candidate considered, out of ${tex`n`} total candidates, **no longer increases revenue enough to "offset" the increased cost of paying the wage ${tex`w`}** (whereas hiring the ${tex`k-1`}th worker *did* increase revenue enough to offset this cost).3b:T774,## Implications for Fairness Why did you just spend all that time reading about an economic model of hiring? Because, now that we've emphasized the **centrality** of a candidate's **marginal contribution** to revenue, their **marginal product of labor**, we can suddenly remember that > **This marginal contribution is not *known* to the employer, and thus has to be *predicted* in order to make the optimal hiring decision 😱** So, we suddenly have a **Machine Learning** problem, in fact very close to the COMPAS ML problem we've been analyzing for a few weeks now: In the **COMPAS case**: * For a given individual ${tex`i`}, the ML algorithm predicts a (numeric) **risk score** * This risk score is then **"thresholded"** based on whether it is greater than or equal to 5, to generate a resulting **label prediction** ${tex`y \in \{\text{Low Risk}, \text{High Risk}\}`} * Individuals predicted to be **High Risk** are denied bail, whereas individuals predicted to be **Low Risk** are granted bail and allowed to leave the courtroom and continue with their lives until the day of their actual trial. In this **Hiring case**: * For a given individual ${tex`i`}, an ML algorithm could predict a **marginal product of labor level** * This MPL estimate could then be **"thresholded"** based on whether it is greater than the **wage level** ${tex`w`} for the position * Individuals whose MPL was predicted to be **above** ${tex`w`} would then be **hired**, whereas individuals whose MPL was predicted to be **below** this threshold would not be hired. So, we can think about this hiring decision using the same tools we've been using to analyze COMPAS. But, in this case (since we're dealing with levels of money), we'll be able to **go further**, since we'll be able to consider the **individual** impacts but also the broader **societal** impacts of these decisions, via a Social Welfare Functional.3c:T822,### Gender and Estimates of Marginal Productivity > *For the population as a whole, women spend on average about twice as much time daily as men on activities that involve caring for others (55 minutes versus 25 minutes).* > > (Folbre, ["The Care Penalty and Gender Inequality"](https://stonecenter.gc.cuny.edu/files/2022/09/Folbre-care-penalty.pdf)) > *Women are also more likely than men to provide care for elderly family members [...] Like child care, elder care is time-consuming and often interferes with paid employment, imposing high opportunity costs* (Amalvoyal et al. 2015, ["The Opportunity Costs of Informal Elder-Care in the United States: New Estimates from the American Time Use Survey"](https://pmc.ncbi.nlm.nih.gov/articles/PMC4450934/)). > *The gender gap in pay would be considerably reduced and might vanish altogether if firms did not have an incentive to disproportionately reward individuals who labored long hours and worked particular hours.* (Goldin 2014, ["A Grand Gender Convergence: Its Last Chapter"](https://www.aeaweb.org/articles?id=10.1257/aer.104.4.1091)) > *On average, women are more likely to delay or interrupt employment, to work part-time or reduced hours, to avoid work schedules that make it hard to accommodate family care needs, and to choose jobs that involve care provision, such as child care, elder care, teaching, and nursing. Even when men and women work hours that exceed the threshold of full-time employment (35 hours a week or more), men's average hours are significantly higher (Cha and Weeden 2014). Expectations of high work hours in some male-dominated jobs deter women, contributing to occupational segregation. Men's labor supply to the market is greater and less constrained in part because they tend to have women partners who supply more time to family care: when men work exceptionally long hours, their wives are more likely to quit their own jobs (Goldin 2014). In recent years, the wage premium for working extra-long hours has increased, contributing to gender inequality in earnings (Cha and Weeden 2014).*3d:T415,## Implications for the Impacts of Technological Development This is... somewhat outside the scope of the course, as we've been conducting it, but since we've gotten this far, the essential "framework" constructed in Acemoglu and Johnson (2023) with respect to the differential impacts of technological development on society writ large can now be summarized like: * Technological developments which **augment** human labor, in terms of **increasing workers' marginal products of labor**, will **aid** in shared prosperity, in the sense that the growth which results from this change will give greater returns to a greater number of people (think of utilitarianism) * Technological developments which **replace** human labor, even though they may **increase workers' *average* product of labor**, will **not** lead to shared prosperity (at least, relative to the scenario in the previous bullet point), since now **fewer** workers will be required to produce the **same** output as was being produced **before** the technological development. 3e:T44a,columns = (args, borders = false) => { const form = html`` form.value = {} let cols = 0 for (const key in args) { let cur_child = args[key]; console.log(Object.keys(args).length); if (Object.keys(args).length > 1) { cur_child.style = `border: 1px solid; padding: 5px; margin-top: 5px; margin-bottom: 5px;` } else { cur_child.style = `border: 1px solid; padding: 5px; grid-column:1/span 2; width:96%; padding: 2.5px; justify-content:center; align-text: center; display: flex;` } form.appendChild(cur_child); cols++ } form.style = `display: grid; grid-gap: 10px 15px; grid-template-columns: repeat(${cols}, auto); grid-auto-flow: dense; width:100%` // form.style = `display: grid; grid-gap: 5px 5px; grid-template-columns: repeat(${cols}, 48%); grid-auto-flow: dense; width:100%; height:100%; padding:5px;` form.oninput = () => { form.value = Object.keys(args).reduce((result, key) => { result[key] = args[key].value return result }, Array.isArray(args) ? [] : {}) } form.oninput() return form }3f:[] 2f:{"title":"Models of Technological Progress, Labor Productivity, and Economic Growth","cells":[{"id":0,"value":"# Models of Technological Progress, Labor Productivity, and Economic Growth","pinned":false,"hidden":false,"mode":"md"},{"id":11,"value":"$31","pinned":false,"hidden":false,"mode":"md"},{"id":18,"value":"$32","pinned":false,"hidden":false,"mode":"md"},{"id":69,"value":"$33","pinned":false,"hidden":false,"mode":"md"},{"id":108,"value":"$34","pinned":false,"hidden":false,"mode":"md"},{"id":854,"value":"[candidateData[0], candidateData[1]]","pinned":true,"hidden":false,"mode":"ojs"},{"id":387,"value":"candidateData = [\n {id: 1, rev_increase: 50},\n {id: 2, rev_increase: 10},\n {id: 3, rev_increase: 20},\n]","pinned":false,"hidden":false,"mode":"ojs"},{"id":523,"value":"candidateData","pinned":false,"hidden":false,"mode":"ojs"},{"id":528,"value":"Assuming the company currently makes a **\"base profit\"** of **$5/hr**, resulting from a **\"base revenue\"** of $15/hr and a **\"base cost\"** of **$10/hr**, what is the firm's profit-maximizing hiring decision in this case?\n\nHere we'll have to think about the company's decision in terms of the **vector** of decisions ${tex`\\mathbf{D} = (D_1, D_2, D_3)`}, where ${tex`\\mathbf{D} = (1, 1, 1)`} means hiring all three, ${tex`\\mathbf{D} = (1, 0, 0)`} means hiring only Candidate 1, and so on.\n\nYou can check the boxes at the top of the following cell to change the hiring decision vector, and the boxes underneath should update accordingly, showing the **revenue**, **cost**, and **profit/hr** resulting from your hiring decision. Once you've found the max-profit decision, the \"❌ *Not yet maximized*\" portion will update to say \"✅ *Maximized!*\"","pinned":false,"hidden":false,"mode":"md"},{"id":400,"value":"$35","pinned":false,"hidden":false,"mode":"ojs"},{"id":378,"value":"$36","pinned":false,"hidden":false,"mode":"md"},{"id":556,"value":"$37","pinned":false,"hidden":false,"mode":"md"},{"id":169,"value":"$38","pinned":false,"hidden":false,"mode":"ojs"},{"id":179,"value":"baseLevels = ({\n rev: 15,\n costs: 5,\n})","pinned":false,"hidden":false,"mode":"ojs"},{"id":635,"value":"candidatesSorted = candidateData\n .toSorted((a,b) => a.rev_increase < b.rev_increase)\n .map((d,i) => {\n return {\n ...d,\n vname: 'Revenue Increase',\n value: d.rev_increase,\n rank: i + 1,\n hired: d.rev_increase > globs.wage,\n result: d.rev_increase > globs.wage ? \"Hired\" : \"Not Hired\",\n }\n })","pinned":false,"hidden":false,"mode":"ojs"},{"id":191,"value":"$39","pinned":false,"hidden":false,"mode":"ojs"},{"id":561,"value":"Notice how, as you move from left to right in this plot:\n\n* The company does **not** \"stop\" hiring the candidates (as ranked by decreasing contribution to revenue) when their **mean** revenue contribution dips below the wage ${tex`w`}.\n* The company **does** \"stop\" hiring the candidates when the next worker's **marginal** contribution to revenue, relative to the **previous** hired candidate, dips below the wage ${tex`w`}.\n\nThis is the core insight we're trying to highlight here! As we'll discuss at the end of this notebook, one important implication of this model is that **technological developments** may end up benefiting **or** harming workers, depending on whether these developments augment the **mean** contribution per worker or the **marginal** contribution per worker.","pinned":false,"hidden":false,"mode":"md"},{"id":332,"value":"$3a","pinned":false,"hidden":false,"mode":"md"},{"id":335,"value":"$3b","pinned":false,"hidden":false,"mode":"md"},{"id":579,"value":"$3c","pinned":false,"hidden":false,"mode":"md"},{"id":337,"value":"$3d","pinned":false,"hidden":false,"mode":"md"},{"id":134,"value":"### Footnotes\n\n1\\. The use of \"can\" and \"cannot\" here point towards *legal* restrictions, but we could also think about the role of non-legally-enforced **social norms**, in which case we'd think about how these norms determine which factors a company \"should\" and \"should not\" incorporate in their hiring decisions. [↩](#fn1-ref)\n\n2\\. Since we've now added a \"denominator\" of 1 hour to the wage, we'll also consider all the other quantities — revenues and costs — on a per hour basis. [↩](#fn2-ref)","pinned":false,"hidden":false,"mode":"md"},{"id":123,"value":"### JS Pieces","pinned":false,"hidden":false,"mode":"md"},{"id":241,"value":"combinedData = [...candidatesSorted, ...profitData]","pinned":false,"hidden":false,"mode":"ojs"},{"id":197,"value":"globs = ({\n baseRev: 15,\n baseCost: 10,\n wage: 15,\n})","pinned":false,"hidden":false,"mode":"ojs"},{"id":147,"value":"fnActivate = {\n const isLocalLink = a => a instanceof HTMLAnchorElement && a.getAttribute('href').match(/^#/);\n const scrollTo = e => {\n let l = e.target, t;\n if(isLocalLink(l) && (t = document.querySelector(`[name=\"${l.hash.slice(1)}\"]`))) {\n e.preventDefault();\n t.scrollIntoView();\n }\n };\n document.addEventListener('click', scrollTo);\n invalidation.then(() => document.removeEventListener('click', scrollTo));\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":606,"value":"genToggle = (cIndex) => {\n return Inputs.toggle({\n label: `Hire Candidate ${cIndex}? (Rev ↑$${candidateData[cIndex - 1].rev_increase}/hr)`,\n width: 100,\n });\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":404,"value":"viewof hire1 = genToggle(1)","pinned":false,"hidden":false,"mode":"ojs"},{"id":407,"value":"viewof hire2 = genToggle(2)","pinned":false,"hidden":false,"mode":"ojs"},{"id":409,"value":"viewof hire3 = genToggle(3)","pinned":false,"hidden":false,"mode":"ojs"},{"id":429,"value":"totalRev = globs.baseRev\n + (hire1 ? candidateData[0].rev_increase : 0)\n + (hire2 ? candidateData[1].rev_increase : 0)\n + (hire3 ? candidateData[2].rev_increase : 0)","pinned":false,"hidden":false,"mode":"ojs"},{"id":446,"value":"totalCost = globs.baseCost\n + (hire1 ? globs.wage : 0)\n + (hire2 ? globs.wage : 0)\n + (hire3 ? globs.wage : 0)","pinned":false,"hidden":false,"mode":"ojs"},{"id":459,"value":"totalProfit = totalRev - totalCost","pinned":false,"hidden":false,"mode":"ojs"},{"id":490,"value":"profitMessage = totalProfit == 45 ? '✅ *Maximized*' : '❌ *Not yet maximized*'","pinned":false,"hidden":false,"mode":"ojs"},{"id":390,"value":"$3e","pinned":false,"hidden":false,"mode":"ojs"},{"id":464,"value":"function centerCell({orig_cell, full_width = false, border = false}) {\n let fw_text = full_width ? \"width: 100%;\" : \"\";\n let border_text = border ? 'border: 1px solid black; margin-top: 5px;' : '';\n return html`

${orig_cell}

`;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":591,"value":"openAllLinksInNewTab","pinned":false,"hidden":false,"mode":"ojs"},{"id":588,"value":"import {openAllLinksInNewTab} from \"@clokman/open-all-links-in-new-tab\"","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W3f","stdlib":"1","titling":"auto"}