How do inventors networks affect urban invention?
Regional Science and Urban Economics, 2018
Laurent R. Bergé, Nicolas Carayol and Pascale Roux
Social networks are expected to matter for invention in cities, but empirical evidence is still puzzling. In this paper, we provide new results on urban patenting covering more than twenty years of European patents invented by nearly one hundred thousand inventors located in France.
Elaborating on the recent economic literatures on peer effects and on games in social networks, we assume that the productivity of an inventor's efforts is positively affected by the efforts of his or her partners and negatively by the number of these partners' connections.
In this framework, inventors' equilibrium outcomes are proportional to the square of a new measure of network centrality, which encompasses, as special cases, several well-known forms of centrality (Degree, Katz-Bonacich, Page-Rank).
Our empirical results show that urban inventors benefit from their collaboration network. Their production increases when they collaborate with more central agents and when they have more collaborations. Our estimations suggest that inventors' productivity grows sublinearly with the efforts of direct partners, and that they incur no negative externality from them having many partners. Overall, we estimate that a one standard deviation increase in local inventors' centrality raises future urban patenting by 13%.
Suggested Bibtex entry
@Article{Berge2018inventor_network,
author = {Berg\'e, Laurent R. and Carayol, Nicolas and Roux, Pascale},
title = {How do inventor networks affect urban invention?},
journal = {Regional Science and Urban Economics},
year = {2018},
volume = {71},
pages = {137--162},
}
Anecdotes
The origin of fixest. I'm often asked how I came to develop the R econometrics package fixest for fixed-effects estimations. This paper is the cause.
Long story short, I was stuck with an ugly functional form for which I needed to estimate the parameters. It was something non-linear in parameters (the centrality defined upwards) and I needed to use fixed-effects. Oh, and it also had to be a Poisson model to be in line with our theory. Problem: there were methods to estimate non-linear in parameter models, methods to estimate fixed-effect models, but no method to (efficiently) estimate non-linear in parameter models with fixed-effects. That was a big bummer.
For context, this paper was part of my thesis, I was in my third or fourth year and I don't think I need to explain how desperate I was to finish something that never seemed to end. And I also need not explain that in empirical projects we easily make 1000s estimations, so if each estimation takes 1 day, well... no thesis.
But lucky me, I had some good experience in programming (thanks to a cool master thesis project) and liked math problems. So off I went spending countless hours coding, optimizing, trying to find math shortcuts, failing to prove convergence properties, etc. In sum I was procrastinating with a good conscience -- and that was fun (a welcome PhD respite!). At length, it worked. So I could run my estimations, write that paper... and finish my thesis.
Fast forward: for the sake of replicability of the paper, instead of sharing 1000s of lines of poorly documented code, I wrote a package on the method (FENmlm, please note how I improved on naming packages!). I then transitioned from my PhD to a 6 months statistics postdoc in Paris where I learned about C++ integration to R, which will turn to be a critical element of the software. Finally, I was lucky to dispose of a super long postdoc at the University of Luxembourg. There I improved my FENmlm software, wrote a paper on the method and had a hard time to publish it somewhere for novelty reasons (I agree to this point, but it was still disappointing).
The framework was ML (maximum-likelihood) and my Gaussian model was OK-fast but only on a par to the OLS of the R package lfe. For some reason, I wanted it to be faster (yes, you may call that procrastination). I then noticed that my method could be very simply extended to OLS/GLM. So here I am to create fixest.
In the meantime I accumulated quite some programming experience and used all of it to try to make a polished package. Then, less than 1 month after release comes Grant McDermott noticing the package (really I have no idea how since I didn't publicize it) and talking about it.
My initial plan was to release the package, forget about it and get back to working on economics projects, so I could eventually get a job. But this plan was destined to face the fate of all plans and be quickly shred to pieces by the unexpected attention brought up by Grant, which pushed me to improve the package. And improve it again. And again, etc. At some point I was full time working on it and I think this is no exaggeration to say that, averaging over the course of my four and a half years postdoc, I spent over 50% of my research time on package development. And eventually this package became what it is. That's the story.
It's just software. Oftentimes, when I'm asked about the stuff I do and I mention software development, economists (note: mostly senior) look at me dubiously and say "well, it's just software (thinking: why do you even mention it?)". Although in all honesty I can understand the comment, I always struggle to come with a good metaphor to explain that yes, it can be useful to economists, yes, there are differences between software, no, it's not just 3 poor for loops in a file, and yes, it requires a lot of effort and, especially, creative thinking to make something good. It was important for me to make that point since, when I was looking for a job, I didn't want the outcome of years of substantive work to go down the drain and, when the job committee takes its decision, I didn't want all this work to count as much as having "regional champion of table tennis" in your CV.
At first lack of confidence led me to throw numbers (wait it's 50K lines! it's been downloaded xx times!) but that was pretty lame and, arguably, didn't bring much consideration. Now I say that software is a bit like papers: can you tell the difference between a paper in a top 5 and a paper in Nowhere Economic Review? Although in both cases it's just words, sentences, tables and figures, I think yes, you can tell the difference. So it's the same for software and I try to make some of the first category (not saying that my software is a top 5 :-D but it's for the metaphor!).