 I want to thank the BangBangCon committee for letting me do this talk. It 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. So I want to 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 to dissertation work, to current research, you're 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 or they're part of policy analyses and also 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. 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. And then I worked for a while doing business analysis, consulting, I was an assistant man. I went back to CMU, studied economics this time, finally got my degree after a while, and I was accepted in grad school. I went to Northwestern for a bit, started an 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. If you're interested, ask me some time 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, so it was better than working on the farm. And now I'm working for Comcast as a DevOps engineer, or as I prefer calling it dev oops. So I wanna begin with what economists can learn from programmers, or developers, or sysadmins, 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. 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 like agent-based modeling. 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 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. 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. 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 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 are that research assistant, you got some problems, possibly. 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, Iver. So what do you do? And if you're real unlucky, you might just get an executable, and you've got this black box, 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. However, there's hope. There's something called the Quanticon 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. 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. FRED, which is the Fed Reserve Economic Data Website and 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. 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. 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 app of grasp on asymptotic behavior because data sets are often bigger than you expect, 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 out of our huge data set. It could very well take a while. Bonus, if you've taken econometrics courses, 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, 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. Use techniques to pre-compute things like memoization, dynamic programming. Finally, testing. You've got results, but are they consistent? I don't know. 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 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. 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 forgot to control for various things. And once you corrected that, the impact was just about zero. There was another paper from Marty Feldstein claiming that social security depressed the savings. There is an error in that that once, in the code that once fixed, reduced that to virtually zero. And finally, most recently, the Reinhardt and Rogoff paper claiming that high debt levels reduce growth. This is important in part because it has significant policy implications for EU austerity. 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? 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 where you developed. Actually, the results don't change dramatically if you change small features in your code. EU standard libraries, they're out there. They work most of the time. There's usually documentation. Explicit checklists for control variables. 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, 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, or you least expect it. 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. 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. And that's called an instrument that you rerun the regression. And I want to use this to troubleshoot like an economist, but wonders endogeneity bias everywhere. It's more difficult to avoid and tech debugging 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 was actually due to the code. The code I was dealing with was actually correct, but I was attempting to place, but it apparently violated certain policy rules 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 a cultural and historical context. Economic models make all sorts of assumptions about culture and history. Doesn't necessarily look like it a simple regression, but we frequently assume that countries have normal growth and spending patterns and any deviations or 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 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. Next I wanna talk about specialization in 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? 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 cobalt expertise, 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. 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. 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. 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 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. 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 and economic historians, such as myself, are not. And both have forums 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. Take that how you will. We are only as good as we'll be tolerating. We need to critically examine our fields. We need to look at these arbitrary classes of real programmers and real economists, reevaluating, privileging theory 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. When I went to grad school, I was the only active African-American in my department that's 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. 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. 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. Blogs and Twitter have made a significant shift in voices in Econ over the past few years. And be patient and listen. As Cat Small noted yesterday, that's to refrain from approaching a problem tools first, whether you're trying to impose an economic model on your observations or a programming language or libraries on a programming task. And finally, this talk is dedicated to my colleague Tiago Perez, 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.