July 17, 2019

About Schmidt Futures

  • A philanthropic initiative founded by Eric and Wendy Schmidt.
  • We bet early on people to help them build vision, focus, and scale.
  • We also invest in tools and platforms that accelerate the growth rate of socially-valuable technologies.

NYU/Schmidt Futures Computation in Economics Pre-doctoral Traineeship

  • We select 15 outstanding predoctoral researchers from around the USA
  • Bring them to NYC for 5 3-day weekends over the next year
  • Provide a $5000 stipend, plus all flights and accommodation
  • Sessions cover:
    • Version control and workflow
    • Databases and fuzzy matching
    • Modularization and testing
    • Alternative data (OCR, scraping, image and text data)
    • Performance and using cloud resources

Don’t despair if you can’t make it along—all materials will be made public.

Get in touch if you want to nominate someone.

What is the point of this talk?

I’d like to highlight a few practices common in software engineering that may help economists perform better research more quickly, with less stress.

I’ll cover:

  1. Non-functional requirements
  2. Iterative development + Agile
  3. Versioning and collaboration
  4. Using formal QC
  5. Testing models

What is not the intent of this talk?

Some tools from software engineering may help some economists do better work, more easily. That does not imply that software engineering tools are all high-value things for economists to learn.

The point is to make economists aware of norms in another field, not turn economists into software engineers.


Functional vs non-functional requirements in software

In software engineering a functional requirement specifies what the system should do/how it should look, etc.

Non-functional requirements—often called -ilities—specify how the system should be. For example:

  • Reliability
  • Accessibility (open source?)
  • Maintainability
  • Testability
  • Scalability etc.

Helpful -ilities in economics


  • For researchers or journalists who want to use your work, it should be as easy as possible to do so.
    • Create libraries (or better: improve existing ones) to help others use your work.
    • Provide data for charts.
  • Build trust among users by publishing test coverage/roadmaps/concerns.
  • Build tools that help users grok your work.


  • Work should be as verifiably correct as possible.
  • Models’ weaknesses and edge or breaking cases should be well-understood and reported.


  • It should be as easy as possible for others to understand, critique and build on your work. Open source as default.

Some examples of work with these -ilities