What Developers and Economists Can Learn from Each Other!
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 34 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/38568 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Bangbangcon (!!CON 2016)7 / 34
3
15
16
17
18
19
24
28
30
32
34
00:00
Software developerComputer animationJSONXMLProgram flowchart
00:19
Software developerComputer programComputer programmingSimilarity (geometry)MereologyMathematical analysisInformation technology consultingPhysical systemSoftwareStatisticsProcess modelingSimulationMathematical optimizationStructural loadShift operatorFormal grammarCodeQuicksortGroup actionLinear algebraFunction (mathematics)Personal digital assistantSoftwareView (database)GradientLastteilungBitCodeWave packetResultantDecision theoryComputer programOptimization problemMultiplication signMereologySocial classAlgorithmGame theoryRoutingEndliche ModelltheorieStandard deviationWebsiteInformation technology consultingBoiling pointGraphics processing unitDegree (graph theory)Arithmetic progressionPhysical systemMathematical analysisSystem administratorOperating systemExecution unitMetropolitan area networkField (computer science)Direction (geometry)Student's t-testObject-oriented programmingReverse engineeringBlack boxCoefficient of determinationSimilarity (geometry)Software engineeringProjective planeComputer animation
06:31
Open sourceStatistical hypothesis testingSoftwareOpen setExpert systemIdeal (ethics)ÖkonometrieCalculationComputer programmingAerodynamicsGUI widgetData modelRadio-frequency identificationPoint (geometry)CodeDisintegrationEndliche ModelltheorieLinear regressionStandard deviationControl flowChecklistPhysical systemRevision controlComputer programLibrary (computing)Point (geometry)Physical systemLink (knot theory)Information securityCodeBit rateSoftwareError messageEndliche ModelltheorieStandard deviationStatistical hypothesis testingMultiplication signKeyboard shortcutComputer programAlgorithmQuicksortSet (mathematics)Linear regressionDynamical systemWebsiteRevision controlWritingCalculationINTEGRALDependent and independent variablesStatisticsUnit testingResultantData analysisAsymptotic analysisMathematicsChecklistFreewareÖkonometrieMereologyOpen sourceLevel (video gaming)Slide ruleGame controllerCausalityProgrammschleifeComponent-based software engineeringExecution unitMobile appBitExpert systemMachine learningGoodness of fitOpen setGroup actionModule (mathematics)
12:43
Variable (mathematics)Linear regressionEndliche ModelltheorieCore dumpNP-hardRadio-frequency identificationProcess modelingComputer networkAbsolute valueNumerical analysisCodeBuildingSineGroup actionSound effectNormal (geometry)CodeQuicksortSoftwareCausalityLocal ringComputer simulationRule of inferenceWritingStack (abstract data type)Computer programMereologyField (computer science)Standard deviationLinear regressionContext awarenessGroup actionPattern languageSlide ruleEndliche ModelltheorieClassical physicsReflection (mathematics)Core dumpTerm (mathematics)Multiplication signMathematicianProduct (business)Adaptive behaviorPay televisionInternationalization and localizationFigurate numberSystem callPairwise comparisonRight angleComputer animation
18:01
Field (computer science)Pay televisionHacker (term)Ideal (ethics)Internet forumTheoryGradientStudent's t-testFaculty (division)Event horizonBlogShift operatorTwitterComputer programmingTwitterReal numberSocial classProgramming languageComputer programTheoryField (computer science)Web 2.0Self-organizationHierarchyPay televisionBlogForm (programming)Process (computing)Hacker (term)QuicksortEndliche ModelltheorieMultiplication signLibrary (computing)Task (computing)Shift operatorEquivalence relationState observerStudent's t-testStaff (military)GenderArmFaculty (division)Event horizonCore dump
21:17
Power (physics)FreewareComputer animationXMLProgram flowchart
Transcript: English(auto-generated)
00:20
I want to thank the BangBangCon Committee
00:23
for letting me do this talk. I was originally scheduled for last year, but last year at this time, I was in bed with a two-week migraine, so today is vastly better.
00:42
So I wanna start out with saying, well, this isn't an econ conference, so why am I talking about programmers and economists? Well, economists do a ton of programming, from the first class
01:02
to dissertation work to current research. You're, you know, doing a lot of programming as an economist, and the programs often have serious policy implications because fairly frequently you're generating statistical models. Those results get published in papers.
01:23
Or they're part of policy analyses, and all sorts of important decisions are made based on the output of these programs. And I find that tech and econ cultures have a lot of similarities, and I'll get to that in a bit.
01:41
Finally, some parts of the economics philosophy have changed my views on programming and vice versa. A little bit about me. I was at Carnegie Mellon for two years, studied CS, but I can only remember about 10% of it on a good day, and I left for reasons.
02:03
And then I worked for a while doing business analysis consulting. I was a sys admin. I went back to CMU, studied economics this time, finally got my degree after a while, and I was accepted in grad school.
02:22
I went to Northwestern for a bit, started in econ PhD program, spent about two years there, and left again for reasons. And then I worked for Solutions for Progress in Philly, first as a research assistant.
02:43
If you're interested, ask me sometime about the farm. And after that, a software engineer, because the company needed someone in the systems group who could code Perl, and I could do so poorly,
03:02
so I was better than working on the farm. And now I'm working for Comcast, as a DevOps engineer, or as I prefer calling it, DevOps. So I wanna begin with what economists
03:21
can learn from programmers, or developers, or sys admins, or what have you. First, sustainable development. As I said before, modern econ is programming, statistical modeling. So much of it is part of empirical work.
03:41
Empirical work is one of the standard things in economics nowadays. Computational econ is increasingly popular. And so this is basically simulating economic agents using AI techniques. You might have heard of agent-based modeling.
04:02
General purpose graphics processing units. They're available, they're getting cheaper. They make large-scale optimization problems faster and cheaper to solve, because most of what economists do boils down to linear algebra. And GPUs are excellent at doing linear algebra
04:20
really, really fast. Finally, algorithmic game theory. It's of considerable interest in both CS and economics, and there's a lot of overlap in that field. And you find this a lot in things like auctions, like eBay, or all-pay auction sites.
04:41
You even find algorithmic game theory in things like load balancing and routing. But it turns out that coding gets short shrift. When you're a grad student, you're spending most of your time in classes. You don't really have actual time to do it right,
05:01
you just have to get some results. There's no formal training. You're thrown in, you get a problem set. There's very little direction. You wind up using a lot of code written by a handful of people with no documentation, but someone in a previous class or in another group
05:22
told you, yeah, this is what you need to get it to run. Programming, data munging, debugging. If you're lucky, you can get a research assistant to do it, but of course, when you're that research assistant, you got some problems, possibly.
05:41
No time to learn Fortran, and there's a bunch of econ code out there written in Fortran, but there's no time to rewrite it in Python either. So what do you do? And if you're real unlucky, you might just get an executable, and now you've got this black box,
06:01
and of course, there's no time to reverse engineer it. So you work, work, work, and a few years later, I don't remember making this, but it works. Well, I hope it works. You don't know.
06:20
However, there's hope. There's something called the QuantEcon project, which has blossomed since last year when I was to give this talk. It's basically open source Python and Julia libraries. There's a bunch of tests.
06:40
It's got backing from various research groups. It's fantastic so far. The Software Carpentry, basically teaching general skills of writing with modules, writing sustainable code.
07:02
FRED, which is the Fed Reserve Economic Data website in Quandl. That's a site with pay and free and pay data sets. And these offer standardized API, so you have to do a little less munging than you previously had to.
07:21
And the Open Knowledge Foundation, which has all sorts of resources for people who never had the data courses or the data analysis courses, but it's an easy way to get started on that. Next thing to learn, algorithms.
07:43
And you don't need to be an algorithms expert. You don't need your Intro to Algorithms book from undergrad if you've had it or whatnot, but it's kind of good to have a grasp on asymptotic behavior because data sets are often bigger than you expect,
08:01
but they're usually smaller than you hope. And you have to be careful about, you've got an N squared algorithm, you're running it on a huge data set. It could very well take a while. Bonus, if you've taken econometrics courses,
08:22
you find that some of the ideas of statistical asymptotic behavior move over to algorithmic asymptotic behavior. When I was doing undergrad research, one of the things that I found myself doing over and over and over was nesting loops,
08:41
sometimes three, four, five layers deep. Time to take a step back because I'm probably duplicating things. I can probably think about some shortcuts to make the calculations a little bit faster. And finally, don't do more than you have to.
09:02
Use techniques to pre-compute things like memoization, dynamic programming. Finally, testing. You've got results, but are they consistent? I don't know.
09:21
Did you make sure you have your controls? I think so. You made a complicated model. Are its implications what you thought they would be? Well, I wrote them on paper, but I don't know. And finally, you're using your colleagues' libraries and their floating point
09:41
and your colleague doesn't really understand IEEE 754, so what you think you might be getting isn't necessarily what you're actually going to get. So how bad could it be? Well, here's a few disasters.
10:01
One is Donahue and Levitt paper, the abortions and crime paper, basically showing, trying to demonstrate that there was a link between abortions in the 70s and declining crime rate 20 years later. It turns out that the code neglected to include the controls, so it forgot to control for various things.
10:22
And once you corrected that, the impact was just about zero There was another paper from Marty Feldstein claiming that Social Security depresses savings. There was an error in that, in the code, that once fixed, reduced that to virtually zero.
10:46
And finally, most recently, the Reinhart and Rogoff paper claiming that high debt levels reduced growth. This is important in part because it has significant policy implications for EU austerity
11:02
and in fact, it was a paper used to justify it. But it turned out that there were significant Excel copy-paste errors, which totally overstated the relationship. Whoops. So what can we do?
11:21
We can learn, economists should learn to write tests. Unit tests for small model components, integration tests for full models, and regression tests to make sure that the regressions as were you developed. Actually, the results don't change dramatically
11:43
if you change small features in your code. Use standard libraries. They're out there, they work most of the time. There's usually documentation. Explicit checklists for control variables.
12:03
You think you've included all of them? You probably haven't. Finally, use GitHub or GitLab or some collaborative system. Because you can get other people looking at your code, you can do code reviews. And finally, you get version control in the deal,
12:21
which when I was studying economics, most people didn't use it. Now I want to turn to what programmers can learn from economists. First causation, this says lurking variable kitty where you least expect it.
12:44
So modeling in one slide. So in any sort of model, you've got factors x. You want to see what impact they have on some other variable y. You build models to estimate those effects.
13:02
One of the core assumptions is that x is uncorrelated with y. Frequently, it's not true. We hope it's true. When it doesn't happen, you have endogeneity bias. The most popular way to deal with that is replace that x with another variable that's correlated with x, but not with y.
13:23
And that's called an instrument. Then you rerun the regression. And I want to use this to troubleshoot like an economist. But one, there's endogeneity bias everywhere. It's more difficult to avoid in tech debugging,
13:41
in part because instruments are terribly difficult to find. You can't really ignore institutional effects. It turns out that seemingly technical causes are actually policy related. A programming problem I had at work a couple of weeks ago
14:03
was actually due to the code I was dealing with was actually correct, but I was attempting to place, but it apparently violated certain policy rules
14:23
that went into developing the program. And this was something that took me a long time to figure out because I was focused on the technology, but not the policy. And finally, in tech and economic modeling, it's important to understand
14:41
the cultural and historical context. Economic models make all sorts of assumptions about culture and history. Doesn't necessarily look like it in a simple regression, but we frequently assume that countries have normal sort of growth and spending patterns
15:05
and any deviations are what we're looking for. And that's a sort of tacit, we tacitly assume some sort of normal. And similarly in programming, we make all sorts of assumptions
15:21
even beyond internationalization and localization. The classic example being does someone have, assuming that someone has both a first and last name. And of course there's many other assumptions that we make and get broken at our peril.
15:42
Next I wanna talk about specialization and trade, which is something that I think we can learn about. And it's a little contentious because I think generalists are awesome, but life's too short to do everything. Do you really want to write your own network stack for production?
16:01
I don't. Even a skilled generalist can benefit from specializing and novices can help with that too. And specializing is a lot less useful without trade. If there's no one wants your COBOL expertise,
16:22
there's a little benefit in focusing on it. And so we come to comparative advantage. This is David Ricardo who first developed the idea in the late 18th century. I want first absolute advantage. Alice is better at writing network code than Barb.
16:41
And Barb is better at building numerical models. Hence they should just do what they do best. On the other hand, comparative advantage. Alice can write network code and numerical models better than Barb. But Alice is better at numerical models than she is at network code.
17:01
Hence Alice should take on the numerical models. Barb writes the network code. They can do, they can both work at the same time and so they can get more done than either alone. But this is a hasty generalization. Comparative advantage demonstrates what's possible, not necessarily what's best.
17:24
Finally, I want to talk about what both economists and developers can learn and have to learn. And one of them, and really the main thing is community reflection and action. And this is where the communities are similar. This is the classic XKCD comic
17:42
about fields arranged by purity. Economics wants to be somewhere around mathematicians. It's in terms of practice, it's somewhere between sociologists and psychologists.
18:02
There's a premium on the hardcore. Both tech and econ spend a lot of time on hierarchies. You know, in tech, OS hackers are hardcore and real, web devs are not. In economics, the hierarchy is theorists are at the top and then there's industrial organization people
18:22
and economic historians, such as myself, are not. And both have forms that advance these sorts of ideas. In tech, there's Hacker News and in econ, there's econ job market rumors, which is basically the 4chan of economics.
18:42
Take that how you will. We are only as good as what we tolerate. We need to critically examine our fields. We need to look at these arbitrary classes of real programmers and real economists. Re-evaluating, privileging theory
19:03
over what actually happens. And in tech, we need to reassess our privileging of tools over people. And by people, I mean devs, end users, support. Minorities in both fields are underrepresented and discouraged.
19:21
I was the only, when I went to grad school, I was the only active African American in my department, that student, faculty, and I think staff. There was one professor who had retired a couple of years before. And so I felt very out of place.
19:41
And I also felt largely out of place until relatively recently in tech. And in both fields, racism, sexism, homophobia, transphobia, are rampant. I can talk about things I've seen in econ offline.
20:02
But what can we do? One is more inclusive events. Not just across race, gender, and class, but also skills and interests. And perhaps there could be an econ equivalent of bang bang con sometime. Make it easier to get into technical and economic discourse.
20:21
Blogs and Twitter have made a significant shift in voices and econ over the past few years. And be patient and listen. As Kat Small noted yesterday, best to refrain from approaching a problem tools first, whether you're trying to impose an economic model
20:42
on your observations or a programming language or libraries on a programming task. And finally, this talk is dedicated to my colleague, Tiago Perez,
21:00
who passed away two weeks ago. We were classmates at Northwestern. And his birthday was on May 4th, so May the 4th always be with him. Thank you.