Tyler Cowen quotes from Clive Thompson’s new book on high-impact geeks.
The 10Xers he [Marc Andreessen] has known also tend to be “systems thinkers,” insatiably curious about every part of the technology stack, from the way currents flow in computer processors to the latency of touchscreen button presses. “It’s some combination of curiosity, drive, and the need to understand. They find it intolerable if they don’t understand some part of how the system works.”
1. I have argued before that CEOs with a coding background have an advantage. You make better decisions when you understand how software development works.
2. In 1989, when I was at Freddie Mac in charge of developing simulation models for calculating the cost of mortgage prepayment and default risk, I first taught myself option pricing and understood the importance of the entire path of interest rates over the life of a mortgage. Also, one of the first decisions concerned a programming language. We went with C, in large part because the investment bankers were working with C. But first I had to teach myself C and do some of the coding myself, to make sure that it “felt” right.
3. In 1994, when I launched my Internet business, I had an understanding of the economics and basic operation of the Internet, based on the working-paper version of Hal Varian and Jeffrey K. MacKie-Mason’s analysis and Ed Krol’s Whole Internet Catalog. I also launched it when I was very high in personal Minsky cycle, basically conceiving the first version in a single sleepless night.
4. When Netscape introduced server-side JavaScript, I learned that. I started a local “users’ group” for the Netscape server, and I found a software developer at that users’ group.
5. He was even more into understanding “every part of the technology stack” than I was. In those days, nothing was reliable. The typical Windows computer crashed several times a day. Browsers were poorly implemented. The Internet itself was not all that reliable. Server software was often unreliable. Many web sites relied on Perl scripts, which someone once aptly described as looking like comic-strip curse words, so that they were nearly impossible to modify or debug.
6. When Java was released, I took a course in it, so that I would understand it. I formed the opinion that it would be more useful on the server side than on the client side. This was fortunate, because the Netscape server was a disaster, and when the Java Web server was released as a beta product, we went with it, and it was much more stable. I continued to code, even though my net contribution was close to zero (my developer had to spend time fixing some of what I wrote). Again, I needed to have a feel for everything, so that I could understand the decisions he was making. We got the point where every page we served was assembled on the fly by pulling elements out of a database.
7. In 2008, when the financial crisis hit, I coined the phrase “suits vs. geeks divide.” I could tell that some of the central players, including executives at large financial institutions and the leading policy makers, did not understand the behavior of options that I learned about in (2). The suits did not know what they were doing. They enacted TARP, an $800 billion program, under the assumption that you could just buy up the bad mortgage securities and hold them for a while. I knew that this was not the case, and after a few months they gave up.
8. About five years ago, I tried another start-up. I wanted to do some of the coding myself this time. But I did not understand how much the software world had changed. It seems to be all about stitching together different packages. I was too much of a dinosaur.
Anyway, I hope that the book is as interesting as Tyler says it is.
On #7, I’d be happy to see (or get a link to) an overview on how the options work. The Big Short seemed to cover a lot about the problems that Dr. Michael Burry saw in the way the tranches were set up. Do you have such an overview of why just “buying up the bad securities” was not enough?
I got the feeling all the lawyers and investment bankers “could” understand the fine print, if they spent the time reading and studying it. But they didn’t, since each was close to some prior boilerplate done before and therefore “good enough” with just a few tweaks. What the suits do get right is that the decision makers need to believe the person presenting the deal, that the deal is actually good for them.
And of course, all the simulations were based on “house prices never go down” for the relevant bets.
On (8) coding, I remember going from Fortran – Basic – Commodore-64 assembly – C – VBA (Excel & Access) – SQL (db detour). Now some Java & Python. A huge amount of development is the set of libraries and connecting inputs & outputs. So the development stack varies, and often changes over a couple of years.
Tableau, for instance, as the presentation output instead of Excel (or Excel graphs in Power Point).
Regarding your point (8), software has become much more about integration over the last several years. It’s much less about logical thinking than remembering which value to use in a configuration file which is much more boring.
For those that are interested, wired.com has an article titled: Recipe for Disaster: The Formula That Killed Wall Street
It’s about the Gaussian copula function. Here is a slice:
David X. Li’s Gaussian copula function as first published in 2000. Investors exploited it as a quick—and fatally flawed—way to assess risk.
Specifically, this is a joint default probability—the likelihood that any two members of the pool (A and B) will both default. It’s what investors are looking for, and the rest of the formula provides the answer.
The amount of time between now and when A and B can be expected to default. Li took the idea from a concept in actuarial science that charts what happens to someone’s life expectancy when their spouse dies.
https://www.wired.com/2009/02/wp-quant/
CEOs with a coding background have an advantage
In my experience, any type of engineering background confers a similar advantage. Learning how to design and debug systems with multiple complex parts, whether in software or steel, develops a way of looking at a company that is very useful to management.
I’m going to comment from the other side of the divide.
When I was young, I wanted to be the best software engineer I could be. I utterly neglected the social and business aspects, I assumed that I would meet more rational people in the R&D business, so never mind social. I presumed the guys running the company would attend to business, so never mind business.
I have many regrets. If I had it to do all over again, I would study psychology with the same intensity – and the same mentality – as I studies machine architectures. And I would have learned enough about business to able to communicate with the suits and to recognize the warning signs of incompetence and criminality at the executive level.
The hardware stack, the software stack, the human stack. They all add up to one stack. Behind nearly every technical problem hides a people problem.
The suits don’t care about the technical details. The techs don’t care about the rest of the stack. But it all matters. All of it.
In a similar situation, I tried that. It didn’t work.
If you’re seriously introverted like I am, and it sounds like you are, it’s not that hard to develop a basic understanding of psychology. But teambuilding and company politics work in an atmosphere laden with image, ego, moralism, symbolism, and frankly plain delusion. I am strongly inclined to both solitude and rationalism, and attempting to work in that milieu is as boring and frustrating to me as engineering is to (stereotypical) poets.
YMMV
“Whole-systems engineering, when you get good at it, goes beyond being entirely or even mostly about technical optimizations. Every artifact we make is situated in a context of human action that widens out to the economics of its use, the sociology of its users, and the entirety of what Austrian economists call “praxeology”, the science of purposeful human behavior in its widest scope.”
– Eric S. Raymond
While that’s all true, I am kind of surprised that you would need to do all that much studying to figure out if you have bad management. You just need to talk to your coworkers, and it should be pretty obvious. If things that are obvious to most of the line employees that would boost the company’s bottom line aren’t being done, you know that management isn’t good. If there are things like that, and they usually get done in a reasonably timely fashion (and we are talking about timely in terms of a bureaucracy), then you know that management at the least isn’t totally incompetent.
Everyone wants to start banking firms, in one form or the other.
Who is putting up the money?
About five years ago, I tried another start-up. I wanted to do some of the coding myself this time. But I did not understand how much the software world had changed. It seems to be all about stitching together different packages. I was too much of a dinosaur.
I tried the same thing. I learned a ton about full-stack software development, but I am also too much of a dinosaur.
This has been a good resource (updated in 2018):
https://www.youtube.com/watch?v=gVXcqO9A1vo
Mind map:
https://coggle.it/diagram/WMMEvSoNyAABBX2w/t/web-development-in-2018/b97ca171d59ba2ab3b7ea8da244a8ed3a154ffa067568635fe2676068a1d44d0
> 8. About five years ago, I tried another start-up. I wanted to do some of the coding myself this time. But I did not understand how much the software world had changed. It seems to be all about stitching together different packages. I was too much of a dinosaur.
That’s definitely the perspective of a former manager of mine, who spent much of his career doing SIGINT work for the defense industry, before becoming a tech manager.
I think this is largely due to the open source movement. It’s made a lot of the (what I think is interesting) algorithmic and infrastructural work essentially free. While it at times feels as though it has reduced the creative problem solving of programming work down to the drudgery of stitching random packages together, it has enabled an explosion of what I call “tech-enabled” businesses. That is, companies that are outside of the hi-tech sector using technology in a strategic way. What they are in the business of hasn’t changed, but *how* they do business is changing constantly.
There is still room for the older way of developing software: I was doing that as recently as a few years ago, but it’s no longer the default. I think the general philosophy (coming from Stack Exchange founder Joel Spolsky) is “only develop software from scratch if it is part of a core competency for your business”. And that everything else should be externally sourced (when possible).