Stan Hanks wanted to build computer hardware, so he arrived at Rice University in 1978 to study Electrical Engineering. But dropping a required introductory computer science class as a sophomore created a slight hitch in his plans.
“COMP 220 was taught in PL/I (Programming Language One),” said the CS alumnus (B.A. ’82). “I started building hardware back in high school, and I had been programming in machine code for a couple of years, but the concept of a high level language was alien. How was the software turning my descriptions of what I wanted to happen into machine code?
“I could go no further until I understood why it worked, so I dropped out and got the hardware reference manual for the computer we were using, and the compiler reference manual as well. Once I understood what the hardware was doing, and what the compiler was doing, then the language part clicked. Abstraction was not something I’d encountered before.”
Thus began his fascination with solving problems by building algorithmic solutions. Hanks passed COMP 220 the next semester, and his focus shifted from hardware to software in his junior year. By his senior year, he was deep into writing software systems and code.
“As an undergrad, I started working for the LCSE – Ken Kennedy’s Laboratory for Computer Science and Engineering. Both undergrads and grad students were working in the lab on research projects and Ken suggested I consider going to grad school,” said Hanks.
“Across the United States in 1981, about 140 people had been admitted to CS PhD programs and the demand was for 360. My decision was a lead pipe cinch. I applied to three or four schools and accepted Rice’s offer when my wife expressed a desire to remain in Houston.”
Hanks said his experience as a graduate student introduced a different perspective to solving problems. His undergraduate courses provided a solid foundation in the theoretical underpinnings and he said while a Rice CS student can understand almost anything they encounter, their approach is still as an engineer figuring out what to do.
“Going down the research path in graduate school taught me to identify smaller problem sets and apply research methodology to solve or better understand what type of problem I faced,” he said.
“As an undergrad, I thought, ‘That’s an interesting problem; let’s start working on it.’ But my grad student perspective was, ‘Wow. I wonder what’s really going on in there?’ We learned to peel the problem open, find the real core of the issue. Instead of treating the symptoms, we were looking into the cause.”
Graduate school also provided space for Hanks’ interest in hardware and his passion for software to overlap and merge in a lucrative way.
“I connect dots that other people don’t see, or at least that’s how one of my friends describes me,” said Hanks. “While I was still in grad school, a friend who worked for an oil company called me up. They had hit a problem, and he knew I had worked in UNIX and also helped design hardware and devices for Western Geophysical.
“He asked if I’d come fix their problem and I replied that I was really busy with my research. So he asked what it would cost for me to spend the day at their office. I guessed a number – $400. And he said, ‘OK, come on over tomorrow and we’ll pay you $400 even if you don’t fix it by the end of the day.’ So I showed up, and fixed it 15 minutes. For $400. And I thought, ‘I could get used to this.’ So I set myself up as the guy who could rapidly analyze and fix problems – sometimes building systems and sometimes fixing existing systems.”
He eventually left grad school behind, first working on a medical device and then in research for Shell. Hanks continued building his reputation among his peers in various industries as the go-to guy for difficult problems.
Hanks’ interest in hardware prompted him to build a multi-CPU-multiprocessor as a side project, an unusual combination in the 1980s. His curiosity then led him to distributed multiprocessors, which were relatively new, and those led him into building network systems. The network systems work connected Hanks with a new group of peers, and he kept finding and fixing problems. Along the way, he developed leadership experience and discovered similarities in solving the problems his team faced.
“In my first management role, I led a team of engineers. Shortly after our company was acquired in a merger, an accountant showed up and said, ‘You are now a P&L center.’ I had to figure out a budget and find people in the company to sponsor my team. That is when I discovered people have problems and businesses have problems, and finding a solution to those problems using technology is infinitely more satisfying than creating technology for its own sake.”
Three decades after leaving Rice, Hanks has leveraged his diverse technology and leadership skills into a role as the chief architect at a startup — a role that encompasses a wide variety of his favorite kinds of problems.
“There are business cases we need to meet, and cost points to achieve while trying to build out those solutions, and engineers and developers who need to have faith in what they are building. My job is to figure out how to make everyone as happy as possible.
“I have a huge amount of experience in building global infrastructure and in web-scale operations. But our challenge now is how to start off small and cost-effective, while preparing to scaling to hundreds of millions of users seamlessly.”
Hanks spends a lot of time reading new papers, looking at new technologies, and new products. He said he is still building budgets and staff plans, but periodically spins up a prototype and throws code at it, to see if it works the way he thinks it is supposed to work.
“Being a chief architect also requires communicating with different audiences. I sit down with stakeholders, senior developers, and the rest of the C-suite to discuss strategy and technology drivers. At the same time, I talk with the product team and hear their ideas, then explain where we need to be going to achieve our goals.”
After taking feedback and input, Hanks returns to the developers to map out a more definitive plan for the work. He also continually evaluates his company’s niche in the market in light of new technologies and new pricing information.
Solving problems is still the high point of his job. He said, “My best day at work is when I unexpectedly come to a solution for something that has been bothering me for a while –that ‘ah hah’ moment.
“I’ve optimized my career around pursuing interesting stuff, even though it wasn’t my original plan when I arrived as a freshman. Rice is a phenomenal place, and it fundamentally changed my world in ways I didn’t even know was possible until I had been there.”