Human Capital and Filepaths

Someone wrote a story about my life. It’s a report from The Verge called “File Not Found: A generation that grew up with Google is forcing professors to rethink their lesson plans”.

When I started teaching an advanced data analytics class to undergraduates in 2017, I noticed that some of them did not know how to locate files on a PC. Something that is unavoidable in data analytics is getting software to access data from a storage device. It’s not “programming” nor is it “predictive analytics”, but you can’t get far without it. You need to know what directory to point the software to, meaning that you need to know what directory contains the data file.

As the article says

the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students. It’s the idea that a modern computer doesn’t just save a file in an infinite expanse; it saves it in the “Downloads” folder, the “Desktop” folder, or the “Documents” folder, all of which live within “This PC,” and each of which might have folders nested within them, too. It’s an idea that’s likely intuitive to any computer user who remembers the floppy disk.

I am a long-time PC user. Navigating File Explorer is about as instinctive as drinking a glass of water for me. The so-called digital natives of Gen Z have been glued to mobile device screens that shield them from learning anything about computers.

Not everyone needs to know how computers work. I myself only know the layer that I was forced to learn.

My Dad, to whom I owe so much, kept a Commodore 64 in a closet in our house. About once a year, he would try to entice me into learning how to use it. I remember screwing up my 9-year-old eyes and trying to care. Care, I could not. It’s hard to force yourself to do extra work without a clear goal. The Verge article explains

But it may also be that in an age where every conceivable user interface includes a search function, young people have never needed folders or directories for the tasks they do. The first internet search engines were used around 1990, but features like Windows Search and Spotlight on macOS are both products of the early 2000s. Most of 2017’s college freshmen were born in the very late ‘90s. They were in elementary school when the iPhone debuted; they’re around the same age as Google. While many of today’s professors grew up without search functions on their phones and computers, today’s students increasingly don’t remember a world without them.

One area in which I do minimum archiving is my email. I rely heavily on the search function. I could spend time creating email folders, but I’m not going to put in the time unless I’m forced to.

Here’s where the “problem” lies:

The primary issue is that the code researchers write, run at the command line, needs to be told exactly how to access the files it’s working with — it can’t search for those files on its own. Some programming languages have search functions, but they’re difficult to implement and not commonly used. It’s in the programming lessons where STEM professors, across fields, are encountering problems.

Regardless of source, the consequence is clear. STEM educators are increasingly taking on dual roles: those of instructors not only in their field of expertise but in computer fundamentals as well.

Personally, I don’t mind taking on that dual role. I didn’t learn to program until I really wanted to. The only reason I wanted to was that I had discovered economics. I wanted to be able to participate in social science research. Let these STEM or business courses be the motivation for students to learn to use computers as tools instead of just for entertainment.

Allen Downey wrote a great blog on this topic back in 2018 that is more practical for teachers than the Verge report. He argues that learning to program will be harder for the 20-year-olds of today than it was for “us” (old people as defined by entering college before 2016). He recommends a few practical strategies, while acknowledging that there is “pain” somewhere along the process. He thinks it is sometimes appropriate to delay that pain by using browser-based programming interfaces, in the beginning.

I gave my students a break from pain this week with a little in-browser game that you can play at https://www.brainpop.com/games/blocklymaze/ They got 10 minutes to forget about file paths, and then it was back to the hard work.

I have found that a lot of students need individual attention for this step – the finding a file in their hard drive. I only have to do that once per student. Students pick the system up quickly. File Explorer is a pretty user-friendly mechanism. Everyone just has to have a first time. Sometimes, Zoomers just need a real person who cares about them to come along and say, “The file you downloaded exists on this machine.”

One way around this problem is to reference data that lives on the internet instead of in a local machine. If you are working through the examples in Scott Cunningham’s new book Causal Inference, here’s a piece of the code he provides to import data from his public repository into R.

full_path <- paste(https://raw.github.com/scunning1975/mixtape/master/, df, sep=“”)

df <- read_dta(full_path)

The nice thing about referencing data that is freely available online is that the same line of code will work on every machine as long as the student is connected to the internet.

As more and more of life moves into the cloud, technologists might increasingly be pointing programs to a web address instead of the /Downloads folder on their local machine. Nevertheless, the kids need to have a better sense of where files are stored. He or she who can understand file architecture is going to get paid a lot more than their peers who only know who to poke and scroll on a smartphone.

There is a future scenario in which AI does most of the programming for us. When AI can fetch files for us, then File Explorer may seem obsolete. But I worry about a world in which fewer and fewer humans know where their information is stored.

Power Drill Versus Python 3.9

I wrote this Complaint on Wednesday:

Consider the power drill. I learned how to use one when I was a child. I have one today that I occasionally bring out for home repair projects. It works just the way it did when I was 8 years old, and I expect nothing to change. There is something nice about tools that function the way they worked the last time you pulled them out of the basement.

Consider programming a web app. Two years ago, I created a web app that I will refer to as Buchanan2. This week I wanted to create a new web app, called Buchanan3. I thought, if I’m lucky, I can use Buchanan2 code as a scaffold upon which to build Buchanan3 in a matter of hours.

To build Buchanan2, I used ToolA and ToolB and Python-based coding. When I opened up ToolA, I got a message that Old ToolA would be deleting next month, so I better upgrade to New ToolA. Ok. I upgraded, hoping it wouldn’t break Buchanan2. Then I opened up ToolB, and it was worse in the sense that more had changed. Also, Buchanan2 had been build using Old Python. New ToolA will not tolerate Old Python. I must figure out how to upgrade to New Python. I fear that Buchanan2 will break if I make all these changes.

While navigating all the changes and upgrades, I fight to stay on the free tier of ToolB, since I already pay for ToolA.

I spent hours searching through documentation. Maybe I could have worked faster. The flesh rebels against this labyrinth, as you would flee a room when the fire alarm sounds. Suddenly, I was on Twitter, and then I was in the kitchen getting snacks.

These situations make me very frustrated, but not hopeless. I have faith that if I bang my head against the desk enough times, and read one more message board reply, that Buchanan3 will work. It has to work. It will work, eventually. I hate New Python, and New ToolB, and anyone who would force me to learn new things all over again. Yet, in this fashion, I somehow got Buchanan2 to work, years ago.

I will keep at it, as a reluctant irritable self-taught programmer.

Today is Sunday. Since writing that, I have progressed and I feel much better. One thing that helped was getting on the lowest paid tier of Tool B and writing an email directly to the creator of Tool B. He wrote back quickly and helped me see my user error. If I’m lucky, Buchanan3 will be working within 2 weeks.

This situation reminds of research by David Deming and Kadeem Noray of Harvard. They find that recent STEM graduates make more money than their peers who picked softer subjects to study in college. Demin and Noray suggest that technical skills become obsolete in a matter of years and thus the wage premium for studying STEM in college declines over the first decade of working life.

My experience is just one anecdote, but there is no way that my college education a decade ago could have exactly prepared me for New Python, New ToolA and New ToolB. Those tools didn’t exist back then.

Charter Cities and Genetic Algorithms

My dear friend Mark Lutter has had me all riled up about charter cities for a few years now. I link to a new podcast from USFQ’s Aula Magna magazine on the subject that gives a very short introduction to the topic. After recording the podcast I returned to preping a class on genetic algorithms and got all riled up because I saw a connection between the two I hadn’t seen (clearly) before. Charter cities can be real life genetic algorithms for institutional innnovation.

Genetic algorithms are a form of machine learning that searches for solutions to problems by trying out a variety of solutions. As the name implies they are based on the evolutionary algorithm of diversity-selection-amplification to adapt solutions. In a genetic algorithm a population of of possible solutions to an optimization problem is instantiated and solutions with high fitness and reproduce (using cross over, mutation, and other genetic operators) to create new populations of solutions. over enough iterations genetic algorithms are goods ways to search for solutions whe the solution space is complex and poorly defined, which is probably what institutional space looks like.

Now imagine a country that is designed as a genetic algorithm and charter cities within the country as posible institutional solutions. The constitution of the central government is the overall framework of the genetic algorithm and the diversity of institutional arrangments at local government levels (i.e. different charters) are posible solutions.

Viewing charter cities in this light, the interesting question now turns to the rules of the central government and not necesarily to the rules implemented by the charters themselves.

A few of the questions that have begun to bother me follow. What country level rules lead to convergence, or at least continual adaptation to better institutional arrangments at the local level? What should the constriants be imposed on the charters for better, faster convergence and learning? Zoning and housing restrictions would be a clear impediment to convergence as they limit foot voting. If we view charter cities (and fiscal federalism) as an experiment to search for solutions to institutional arrangements for governance, can we use the criteria used by IRB boards as the minimum set of requirements that informa the central government constitution/framework where this experiment takes place?