͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌     ͏ ‌    ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­


The Obsession of High Performance

by John Criswell

When Lane told me I had to write an article for Multicast, I must admit that I wasn't overly excited. I wasn't sure what to write about, but I ultimately decided to reflect on the state of computing over the last thirty years.

Computing has come a long way. And I hate it!

While computing has experienced great success, I think it has also lost its way. In this article, I
'll cover one such wrong turn: the obsession of high performance.

A History of Performance

For much of its history, computers, despite being expensive, simply weren't fast enough to meet even meager computational demands. The focus on performance, therefore, made sense. For much of computing's history, performance changed the computing experience of end-users.

As an example, let
's step back to 1984. At that time, a word-processor for an Apple II computer could spell-check a document. However, memory was too small to contain an English dictionary. To work around this limitation, dictionaries were stored on floppy disk, and spell-checkers would need to frequently access data on disk. When I would spell-check my five-page reports for my high school chemistry class, I would literally eat dinner with my family while the computer spent thirty minutes dutifully finding the three words I had misspelled (I was good at spelling in my youth).

Fast-forward to 1995. At that point, I owned an 8 MB PowerMac 7200. The dictionary was stored in a fast hard disk with ample room in RAM. Spell-check took less than thirty seconds. Instead of spell-checking a document once or twice near the end of a project, I could spell-check whenever I wanted, after writing a page or two (I was still good at spelling, having recently graduated from high school).

By 2010, spell-check had become so fast that the computer automatically checked my spelling as I typed. It could even suggest the correct spelling at the point I had made the error. Today, the computer takes the initiative to correct my spelling by providing a similar, but incorrect, word replacement. Now my documents all have errors thanks to the computer, but at least none of them are spelling errors!

What we see from this example is that
performance changed the end-user experience. Computing became materially better for the vast majority of people because activities for which we wanted computing assistance went from being infeasible to possible to instantaneous. Decades worth of improvements to memory, processor, and compiler design literally changed what computing is to the average person.

Performance Today

With my apologies to Fred Child, let's consider computing performance in today's world. Does your laptop or cell phone do anything drastically different compared to what it did ten years ago? Well, it can now authenticate you by looking at your face. I suppose that's nice. My thumb needed rest from tapping that fingerprint scanner. What else? Oh! It has better graphics. That's nice if you play video games. But I haven't had time to play video games since graduate school. Super Mario Sunshine for the GameCube is still on my TODO list.

While utility is inherently subjective, I argue that, for most end-users, greater performance today does not equate to an improved computing experience. Nor does it lower cost. Cell phones always cost several hundred dollars, and workstations are always $1,500. Computers are basically the same as they were ten years ago, except that they have better graphics and more idle cores.

This is not to say that performance is unimportant; I merely argue that it
's important for an increasingly smaller number of people. If a researcher can shave a few cycles off of a computation performed routinely on a cloud computing system, Google and Meta will save a ton of money; that small savings is multiplied by thousands of machines each doing thousands of millions of computations per second.

But here
's the thing: Google and Meta are worth $2.65 trillion and $1.85 trillion, respectively. Unless I work for such a company, why would I care about the problems of an organization with over a trillion dollars? If I had over a trillion dollars, you would (understandably) tell me to go solve my own problems.

Yet performance drives the priorities of computer science education and research. What problem does every computer science program focus on? Performance. Which data structure provides the right performance/space tradeoff? What programming language abstractions generate the least overhead? How can you use GPUs and vectorization to make your program faster? What processor features can be leveraged to make your program run faster?

How have we paid for this obsession for performance? We lost reliability, security, and usability. Programs still crash. Attackers still steal your credit card number. Programs are still frustrating to use (recent graduates remember the software for course registration with justified disdain). However, because performance trumps all else, we
've convinced users that we, as a field, cannot do better in these areas despite decades of research to the contrary. Who said computer scientists couldn't do marketing?

Performance's Place in Computing's Future

To be clear, I don't think making computers faster is a bad thing. However, I do think that we, as a field, need to begin thinking more intently about why a computation should be faster instead of merely assuming it should be faster. Who benefits from improving performance? What do end users sacrifice if solving a performance problem is prioritized over solving a reliability, security, or usability problem? Is there a point in which we have enough performance, and where is that point?

I believe our field also needs to reconsider how we educate students. The science and art of building reliable, secure, and usable software systems is not a required part of our undergraduate curriculum despite decades of research in these areas. Most students aren
't even aware that there are decades of work in these areas. Perhaps for the next thirty years, we should be giving our students a broader understanding of what computing can be: fast, secure, reliable, and usable.

The obsession with performance has cost computing greatly over the past thirty years. The public at large has come to understand that computers are fast but unreliable, insecure, and painful to use. Is that where we still want to be thirty years from now?

Exposing the Invisible: Inside Offensive Hardware Security Research

By Yanan Guo


In hardware, this often means studying vulnerabilities that emerge not from software bugs, but from the behavior of the hardware itself. Microarchitectural side channels, for example, show that processors may unintentionally leak secret information through subtle differences in timing, cache states, or power consumption. Such findings expose how complex optimizations for performance can inadvertently undermine isolation and security.

2. How Offensive Hardware Security Research Works

Offensive hardware security research is fundamentally an empirical discipline. To uncover the hardware vulnerabilities, a critical step is to understand how the hardware works. Unlike software, whose logic can be inspected and traced, hardware implementations are largely opaque and proprietary. Researchers rarely have access to design schematics or detailed documentation, yet must reason about systems composed of billions of transistors and deeply layered microarchitectural optimizations. To understand such systems, they rely on reverse engineering – inferring undocumented behavior from externally observable phenomena.

To investigate the detailed behavior of microarchitectural components and their interactions, researchers create microbenchmarks – small, focused programs designed to trigger specific hardware behaviors. Researchers carefully adjust things like the memory access patterns and instruction sequences in these programs to observe how the system responds under controlled conditions, using metrics such as timing, performance counter results, and power consumption. Through repeated measurement and analysis, these experiments gradually expose consistent patterns that reveal how components such as branch predictors, translation lookaside buffers, and cache coherence logic actually behave beneath their public descriptions.

The challenge comes from the fact that hardware behavior can be observed only indirectly. Unlike software, hardware cannot be single-stepped or instrumented at fine granularity, so researchers must rely on coarse-grained measurements that are often noisy and affected by system variability. Interpreting these results demands both technical precision and cautious analysis. Even after identifying a potential signal in the results, researchers must verify that it is consistent and stems from a specific design feature rather than experimental error. This iterative process – forming hypotheses, collecting data, and refining explanations – can take months of sustained experimentation before a hardware design is fully understood.

However, identifying how individual components behave is only the first step. Practical attacks are typically composite: they result from subtle interactions across different microarchitecture components and across the microarchitecture and the software stack. For example, a speculative execution effect in silicon may be harmless in isolation, but when combined with optimizations in the operating system, it can become the trigger for an end-to-end exploit. Demonstrating exploitability therefore requires building an attack chain that spans hardware, firmware, operating system, compiler, and the target application – showing how a low-level signal can be amplified and translated into a breach of confidentiality.

Once an attack is confirmed, the work moves to the next phase: responsible disclosure. Researchers privately report the issue to the affected vendor, often with technical details and proof-of-concept code. If the vendor determines that the attack poses real risk to users, both parties typically negotiate an embargo – a confidential period during which the researchers withhold public disclosure while the vendor develops and tests mitigations. Negotiating the embargo length can be delicate: researchers seek transparency and fair credit, while vendors must balance security, performance, and release schedules. Typical embargoes range from a few months to a year.

3. Why This Work Matters – Often More Than Defense

Security evolves as researchers uncover how systems can fail. Much of today's defensive design is guided by knowledge gained from earlier offensive findings.

First, without offensive research, there would be no direction for defense. Every major defensive mechanism we know was born from an earlier offensive insight. For example, before researchers uncovered cache-based side channels, no one thought about cache randomization. And before cache occupancy attacks proved that randomization alone could still leak enough information to compromise user privacy, many believed the problem was solved. Each offensive discovery reshapes what "secure" even means and expands the boundaries of what defense must protect. Formal, principled approaches to security certainly help, but modern hardware is so complex – and industry attention to security so uneven – that defenses built in theory often fail (to be implemented correctly) in practice. Offensive research matters because it reveals where those theoretical assurances break down and where real systems fall short of their promises.

Second, offensive research matters because it holds industry accountable. Security is costly: it consumes silicon area, design time, and performance headroom. As a result, companies tend to ship ad hoc defenses and hide internal details, hoping that "good enough" will stay untested. It is only when researchers demonstrate that a defense fails that the design cycle restarts.

The history of
Spectre illustrates this well. When the first attacks appeared, they exposed how speculative execution – one of the most celebrated performance features – could be weaponized to leak data. In response, companies like Intel introduced new branch prediction and isolation techniques. Yet as academic work continued, researchers showed that those mitigations were incomplete which forced another wave of redesign. In fact, this cycle is not failure – it is how real security evolves. Offensive research pushes industry to confront uncomfortable truths, to reexamine assumptions, and to invest where it once cut corners. Without that pressure, security would remain a marketing checkbox, not a design principle.

4. Frustrations Behind the Work

The responsible disclosure process can be long, opaque, and frustrating. Researchers and companies often do not share the same priorities. Researchers want to improve overall security and make the public aware of important risks. Companies, on the other hand, focus more on reputation, user trust, and keeping their products stable.

These different goals can lead to tension. Some companies downplay the severity of a vulnerability or quietly fix it later without crediting the researchers who discovered it. Others request long embargo periods that keep the findings secret for months – not to develop mitigations, but to delay potential damage to their reputation. In such cases, disclosure becomes less about technology and more about patience, persistence, and principle.

Yet despite these challenges, responsible disclosure remains essential. It relies on a fragile kind of trust – trust that companies will take action, that researchers will act responsibly, and that, eventually, both sides will succeed in protecting users. These quiet struggles rarely make the news, but they are what turn a technical discovery into real security for everyone.

Closing

Offensive security research lives in the quiet spaces between discovery and trust. It is the unseen work that keeps the visible world safe – uncovering what could go wrong, so others can make it right.

In our Department of Computer Science, we've been busy designing new courses that reflect how fast computing is changing. Recently, we added courses such as AI for All, designed by Adam Purtee; Computer Architecture and Security, by Yanan Guo; Machine Learning Systems for Efficient AI, by Sreepathi Pai; and Nonlinear Optimization, by Jiaming Liang. Two new courses will be added to our curriculum this spring: Great Ideas in Computer Science, by George Ferguson, and a new seminar course by Chris Kanan. In addition, Eustrat Zhupa has revamped CSC 171, switching the programming language to Python to better prepare students for the AI-driven landscape. Each of these courses reflects our shared goal of connecting the classroom to the world our students will soon enter. Among these new additions is a course I helped create that looks towards the future of cybersecurity: Post-Quantum Cryptography (PQC).

The security of many cryptographic systems we use today, especially public-key algorithms, would be compromised if large-scale quantum computers became a reality. Post-Quantum Cryptography (PQC) refers to cryptographic systems that remain secure against both quantum and classical computers, achieved through entirely classical (non-quantum) means. It may seem surprising that we can protect ourselves from quantum attacks using traditional computers, but that is exactly what PQC makes possible.

Years of teaching an introductory cryptography course and my research interests inspired me to design a course that continues beyond where traditional cryptography leaves off. I believe that the best outcomes arise from collaboration and developing this course as a team effort proved to be an excellent decision. Working together with my colleagues, Professor Stanislaw Radziszowski and Professor Thomas Borrelli, we designed and launched this new course to explore these challenges and opportunities. The course introduces students to the ongoing National Institute of Standards and Technology (NIST) standardization process for post-quantum cryptographic algorithms. It also examines how quantum computing threatens today
's security infrastructure and how those threats can be mitigated through quantum-resistant schemes. The course quickly attracted students eager to understand the future of cryptography and cybersecurity.

In this course, students explore both the current state of public-key cryptography and the emerging field of Post-Quantum Cryptography. We learn the basics of quantum computing and examine why it poses a threat to widely used public-key cryptographic systems. Then we examine how quantum-resistant cryptographic systems, achievable through entirely classical means, can secure communications against both quantum and classical attacks. The course also covers the NIST standardization process for post-quantum algorithms and introduces potential post-quantum cryptosystems designed to withstand future quantum threats.

Designing the course was both exciting and challenging. The field evolves so rapidly that we take care to ensure students were learning concepts that would still matter years from now. Since there were no textbooks dedicated to PQC at the time, we developed the course topics entirely from scratch, combining theoretical foundations with the most recent research results. Because the NIST PQC standardization process is ongoing, the course requires continuous updating to reflect the latest developments. Of course, a new course is never perfect on its first run. Over time, topic selection was redefined, the schedule was adjusted, and we experimented with different delivery methods to make the learning experience stronger each year.

Our experiences eventually led to a SIGCSE paper, "Designing and Delivering a Post-Quantum Cryptography Course," and a poster one year later. We shared what worked, what surprised us, and what we learned about teaching a research-active field. I was happy that our work was highlighted at SIGCSE, the major international conference on computer science education, where educators discuss innovations in teaching computing. Talking to other educators confirmed that there is an increased interest in post-quantum cryptography and that undergraduate students are more than capable of engaging with these complex ideas when given the right tools and guidance. At the end of the course a final project is assigned, giving students the opportunity to apply what they
've learned to industrial problems and explore post-quantum cryptography in depth.

Looking ahead, I plan to continue refining the PQC course as new standards emerge, adding engaging assignments and real-world applications. Teaching at the intersection of theory and innovation is always a challenge, but it
's also where the most meaningful learning happens. Seeing how quickly students connected the material to broader ideas like trust, responsibility, and the future of digital communication reminded me of this. Several students said it was the first time they felt they were learning about something before it became mainstream. That sense of discovery reminded me of why I love teaching so much.

Image provided by Monika Polak

Promotions

Lane: I should mention to the readers that CSW's math department's scope includes computer science, and in fact the math department offers courses that look to me to be college-level immersions in programming, data structures and algorithms, AI, robotics, and more. And I suspect your hand has been central in creating and teaching that stunningly strong support for college-level CS education within CSW.

Proshanto: My core project over the last couple of years has been to build up the school's CS program. My aim is to make it one of the very best high-school programs in the country, and I think we're well on our way. The main reason for this is my students, some of whom are simply extraordinary. For example, I had a ninth grader last year who, in just four days, completed a project I first saw as a graduate student in CSC 400 at U of R. He built a sudoku solver that interleaved multiple parallel search strategies and heuristics to gradually solve any sudoku puzzle. I can't bear to see students like that stuck in the standard high-school CS curriculum, which is appalling.

So we have been creating advanced classes for our advanced kids. Some examples: an undergraduate-level data structures and algorithms class, a class on Object Oriented Design Patterns (a la the "Gang of Four" book), an introduction to Artificial Intelligence, and various classes on robotics design and programming.

Lane: What terrific learning opportunities available you and your colleagues have created for the students!

How have you enjoyed your career at CSW, and how has your specific legal background helped you better support students' education at CSW?

Proshanto: I adore teaching, and my background as a patent trial lawyer has turned out to be very valuable. First, it turns out that many of the core skills carry over. In court, one of my main jobs was to help a jury understand state-of-the-art technologies, which is not so different from helping a sixteen-year-old understand the subtleties of the complex plane. The process is the same in either case: break down the technical issues to their fundamental components, then weave them together into a clear, compelling, and memorable story.

Second, and more straightforwardly, I've used my legal background to set up a trial litigation class here at CSW, where students put on a full mock trial, complete with opening and closing statements, direct and cross-examinations, and evidentiary arguments. I also organize an inter-school mock trial event with another local school. It's all great fun.

Lane: I'll bet that a lot of colleges' debate teams, and law schools' incoming classes, are going to be strengthened by alumni of your trial litigation class!

Thank you so very much for being Multicast's Featured Graduate Alumnus, Proshanto. Your career – from AI to the law to education – is surely one of the most interesting, successful, and meaningful ones of any URCS graduate. And I'm very glad that your answers will share with all our alumni – as your teaching is also passing on to your CSW students – the approach and values that both you and Len Schubert epitomize: bringing rigor, creativity, and care to everything one does.

Warmest congratulations and wishing you all the very best in the years and decades to come!

THADDEUS PAWLICKI: We have with us John Pershing, who graduated from CS@UR in 2010 with a degree in Computer Science. He is currently CTO (Chief Technology Officer) at the American Society of Composers, Authors and Publishers (www.ascap.com). We must state that the opinions expressed are solely his own and do not express the views or opinions of ASCAP.

Greetings, John. How is the new job? This is your second position as a CTO, correct?

John Pershing: That's right, Ted. I was a VP of Engineering at 1010data, then… moved into What If Media Group as their CTO before coming to ASCAP. I am the Chief Technology Officer at ASCAP, and I run what we call GTS here. It's Global Technology Services.

TP: Tell us about ASCAP.

JP: ASCAP is a PRO, a Performing Rights Organization. When a musical artist writes a song they own a copyright on that song, and the copyright act dictates that they are owed performing royalties for anything, any public performances of their copyrighted works. There are also mechanical rights that have to do with selling physical copies of music. In the digital world, what's mechanical and what is performance is a little bit… unintuitive at times.

TP: That must get complicated in today's digital world.

JP: For example, it would be pretty onerous if every bar, grill, tavern, sports stadium, and airline, performing music as part of running their business, needed to get an individual license from every single songwriter. ASCAP is a 101-year-old organization: we were the first of our kind. People who own music, or are stewards of music copyright, come to us. They say: hey, we're going to give you the right to redistribute our copyrights under a blanket license. So it's a many-to-one, one-to-many relationship. That's what ASCAP does. We issue licenses.

TP: There must be some interesting data-mining opportunities in that space.

JP: Yes. In addition to sending us money, users send us data on what music is being performed. We survey what's performed on things like radio stations, we get cue sheets from TV networks, and we collect all this data, then use that to decide how to cut up the big pile of licensing money that we collect from all of these entities and distribute it to the songwriters.

TP: That's an interesting market space.

JP: Yes. You'll see biopics about musicians and their terrible deals with their record labels.

The PROs, we pay songwriters directly. ASCAP is a not-for-profit. So our goal is to put as many dollars as possible in the pockets of our members to make sure that they can make a living making music.

TP: So, what is your specific role in all that?

JP: My role is to make sure all of the technology that facilitates issuing those licenses, collecting those royalties, collecting usage data, analyzing everything, distributing that money back to our members, and all of the affiliated technology that supports that is running, working, and doing so on the quarterly basis that we pay out our distributions.

TP: Where do you fit in the overall market?

JP: There are 4 major PROs in the United States. ASCAP and BMI together control about 90% market share. The remaining 10% is split up between smaller players. We'll process close to $2 billion in royalties this year. I'm not gonna pretend that everything is sunshine and rainbows, but people are streaming a lot of music these days, and music streams are performances.

TP: It sounds very exciting. Your current position is really interesting, but it was a long journey to get there. You had an interesting 10-year rise through the ranks at 1010data after graduation.

JP: It's true, I did.

TP: Was that a rise through the ranks a "directed search" or more of a "random walk"?

JP: I will say there were elements of each. There was a bit of randomness and entropy in there. It certainly wasn't a deterministic exercise. The story of how I got to 1010, and I started as an intern, has a lot to do with URCS. I was in the computer science majors lab. The department's Undergraduate Coordinator, Marty Gunther, ushered several alumni into the lab. It was Meliora Weekend, and I didn't know what that was at the time. I was doing a computer networks project at the time. There was somebody from Microsoft, somebody from Google, and somebody from this company I'd never heard of called 1010data. So, I struck up a conversation with a fella from 1010 who turned out to be Dan Horowitz. He was a Rochester alum and an early employee at 1010.

TP: I remember Dan.

JP: So, Dan asked me: hey, do you have a resume? Luckily, the career fair was the very next week, and I had gone to the Career Center at the advice of my academic advisor, Daniel Štefankovič. So I was able to print that resume for free in the lab and hand it to Dan. That resume turned into a phone interview. 1010 flew me down to New York. I did a day of interviews. That turned into a job offer, which was a whole lot more appealing than the opportunity that Microsoft presented.

TP: A case of preparation meeting opportunity?

JP: Yes. I joined 1010 as an intern. I was appealing to them because I knew a lot of languages. This was something I found really amazing about Rochester. Unlike other programs, which may teach you very specific skills and frameworks, Rochester taught me how to learn. By that time, I had learned probably a… half dozen to 10 different programming languages, and a bunch of frameworks around those languages. I was able to come into 1010 and be extremely valuable to them because they needed work done in a diverse set of languages.

TP: Sounds like a challenging first gig.

JP: APIs didn't exist in the way they do today. Back then, you built SDKs. 1010data needed to build SDKs around their system in C, C++, Python, Perl, Java, the .NET ecosystem, and Ruby. There were a whole bunch of languages they wanted to build around. They had built the C framework, and they said, we need to build a whole bunch more. And that's what I did that summer. They turned that into a full-time offer at the end.

TP: That's a great endorsement for undergraduate internships.

JP: Yes. At the time, I wanted to pursue a PhD. The reason I went and did an internship is that Daniel had told me to go do an internship – that it would make my graduate school applications look more well-rounded. And in the course of that internship, I fell in love with the company. My boss at the time explained to me that you should take a job with us. You can pay down your student loans, and you should learn something about what goes on in industry. After a few years, go back and get a PhD. The computing industry is friendly enough in academia that they'll accept you back into the academy.

TP: We are still leaving a light on for you.

JP: I graduated into kind of doing a similar thing that I did as an intern. I was given a big cross-section of what we called client-side technology. This is native code running on Client systems. 1010data was a big data, distributed system, an interface that looked kind of like Google Sheets, but you could put 100 billion or a trillion records in a single spreadsheet, and still manipulate it with the same interactability you'd get with a desktop-sized application.

TP: It sounds like a lot of responsibility for a new employee.

JP: I owned all the code that ran on our customers' hardware to connect programmatically to 1010. Command line tools, plugins, drivers, all of that. It put me in a space where I was working in all of these native, high-performance ecosystems that were shoveling very, very large volumes of data back and forth. I eventually cross-pollinated into the backend. I did some work in 1010's distributed system – what you would explain today as a MapReduce implementation, before Google published the MapReduce paper.

TP: It must have been a lot of work.

JP: At one point, I was confronted by my boss, and he goes: "John, why haven't you worked on this new cool thing we talked about? We had this great idea over dinner months ago, and you haven't built it yet. I'm disappointed." I tell him, "I apologize, I'm sorry, I'm spending 100% of my time supporting all this stuff that we've built so far." I was in a very customer-facing role at this time. You might call it a forward-deployed engineer in today's parlance, but I was working hand-in-hand with the technical folks at hedge funds and retailers, and they wanted me to be working with them to solve their problems. My boss said, "There's an easy solution for that. Hire somebody and give them half of your stuff."

TP: Was that your first step into management?

JP: I hired somebody, but unlike the way I had been inducted into the organization, where I kind of had a pile of code poured on my head, I brought somebody in and said, "I'm gonna work as a partner with you."

TP: That's a bit unconventional.

JP: On paper, I was this person's manager. But I was their manager in the way that Batman was Robin's manager. We started introducing more modern team-level developments in that part of the organization.

TP: A great way to grow innovation.

JP: Then, 6 months or a year later, the same problem. "John, why are you and the rest of your team not working on these new cool things we talked about?" Rinse, repeat. That cycle repeated several times, and I very organically transitioned from an individual contributor responsible for building a lot of code to someone who was spending more time looking at other people's code, thinking about architecture problems, and working with people. If you'd asked me in the earliest part of my career if I wanted to do that, I would have said absolutely not, but this was a really interesting opportunity.

TP: Knowing your interests, I'm not surprised that it was a great fit for you.

JP: The reason I wanted to go into academia was because I wanted to teach. Ted, I started working for you as a TA in my sophomore year. Actually, I worked for you sophomore through senior year, but I first worked for you my sophomore year, and I have a vivid memory.

Working for you, working for Daniel in 282, teaching people, and getting a lovely feeling of euphoria when I saw the thing click, when someone learns something. That was genuinely a wonderful feeling for me.

My impetus for going into academia was: I'm gonna get a PhD, I'm gonna teach. Research is interesting, I love the work I did with Dr. Allen and Dr. Scott, but the drive to get a PhD was I wanted to go teach. When I got up into this managerial layer, I was spending a lot of time doing code reviews and coaching people on my team. I realized that the same neurons were lighting up that lit up when I was a lab assistant in CS171. I was able to explain to people things that I had learned.

TP: You always had a passion for that.

JP: So I built that initial team. I built a couple of other teams, and eventually, 1010data experienced very organic business growth. When I joined, there were probably 20 folks. When I left 10 years later, there were about 300. We had built an incredibly powerful tool that was extremely hard to use. We needed to rebuild that, and so I was put in charge of basically tearing out the top two-thirds of this product, and rebuilding it with self-service in mind. And so that was when I was first really put in charge of a team of teams, when I was managing managers.

TP: That must have been a tall task.

JP: That wasn't something that I wanted to do at that time for the same reason I wouldn't have wanted to become a manager when I was an individual contributor. I like reviewing code, I like being in the architecture, but also, I enjoyed managing people, enjoyed managing teams. I got to see a large group of people accomplish something that a single team wouldn't have been able to do on their own. It was really gratifying. It brought me up to being a VP of Engineering at 1010data, after a 10-year run there.

TP: That's quite a journey. What happened next?

JP: When Dan ultimately left 1010 to go start a startup in the dental tech space, I was told, in no uncertain terms, you are not being considered for this position.

TP: That must have been a bit of a disappointment?

JP: At 1010data, every year I had been there, I made a note to do a serious interview, or a few serious interviews somewhere else. I want to know my value as an engineer. I wanted to stay sharp and on top of interviewing skills. I always told myself, if I found a place that was genuinely better, I would leave.

TP: That is a healthy approach to career advancement.

JP: It wasn't until that 10-year period that I said, hey, I started here as an intern, I'm now the VP of Product Engineering, and I'm being told, you are not being considered for additional promotions. I said, okay, it's time to put myself out into the market. That's when I found the What If Media Group. And they were looking for a CTO. They had recently merged. These two companies started a joint venture in 2017. It turned into a full merger at the beginning of 2019. They had two engineering teams that very literally – it's not an exaggeration – had only talked to each other through APIs.

TP: For some software engineers, it doesn't get any better than that, right?

JP: So, I was given two charges when I joined What If. I was told: you need to bring these technology teams together, because they are extremely separate. As a company, What If Media Group at the time thought of itself as a marketing and advertising company with a tech team. They wanted to flip that on its head and become a tech company in the marketing and advertising space.

TP: Quite a challenge to corporate culture.

JP: At the time, they solved problems by throwing people at them. I helped the organization bring a lot more automation, data-driven decision-making, and ultimately made the organization really think of itself more like a tech company. So I did that for 6 years. Engineering at What If Media Group was about 19 people when I joined, and it was about 60 when I left.

TP: So, why did you end up leaving What If Media Group?

JP: We had, you know, really interesting problems to solve. Big data, we had streaming problems and historical analytics problems, a great team of people that I had really helped build. But the big hole was putting ads in front of people as a core business model. It's what runs the internet. It's what paid What If's bills. What If was a very profitable business. But… it wasn't something that had intrinsic motivators behind it. ASCAP reached out earlier in 2025, and a big reason I went to the University of Rochester was I have a huge passion for music.

TP: I recall that being a big interest of yours.

JP: I was in bands in high school, you know, performing and gigging, and I got to Rochester with an interest in engaging with the resources at Eastman. It was very clear that I did not have the chops to be a professional musician. That was made clear in the first semester or two, but I have a true passion for it, and the ability to enter the music industry, that was something that was extremely motivating to me. I have a huge amount of love and respect for What If Media Group and their team. But being able to shift into a not-for-profit that supports songwriters was a big draw for me. So, I'm here at ASCAP. This is day 13 for me.

TP: Yes, I can see your walls are still bare in your office.

JP: Yeah, I have not had a chance to decorate my office, but I am now in a space where, you know, I have a larger team here. There're between 130 and 140 folks in the engineering organization here at ASCAP. I no longer own product management. I'm getting back to being purely focused on engineering here at ASCAP.

So that's a kind of a corporate history, what I did from graduation up through where I am today.

TP: What a journey. That's really cool. My readers will love that. It's an interesting story. Shifting gears a bit to more technical topics; what mathematical or algorithmic tools do you use on a day-to-day basis?

JP: I like this question because, as a student, there's often a big abstraction between what I am studying and how it will be useful. This is something that I pushed on the CS department many years ago; I think some changes have been made. From a mathematics and algorithms perspective, I use statistics on a day-to-day basis; understanding probability distributions is genuinely important, in my opinion, in most walks of life, not just being a technical executive, but existing in the modern world. Regrettably, I took no statistics courses at Rochester, because it wasn't an option in the CS program at the time. I believe there's some optionality in there at this stage.

TP: Oh yes, it's required now. It may have been some of your influence.

JP: Excellent. For a while, it was an option. Stats is hugely important. Outside of that, Ted, I learned this from you, computational complexity, big O notation, is less useful in my personal day-to-day as a technology executive, but is something that comes up from time to time, and was a huge part of when I was an individual contributor, when I was an architect and reviewing code. I've lost count of the number of times I've seen naive implementations that have quadratic, cubic, or worse performance characteristics, which work fine on a test case, and are hopeless at production scale. Having that type of analysis and having a critical eye towards that is key. It is using the same muscles that were built up originally in CS172.

TP: I'm going to play that clip for my current 172 class, if you don't mind.

JP: There we go.

TP: Looking back, what courses did you consider most useful?

JP: The single most useful course that I took at Rochester's URCS was CS282.

TP: Okay, and why was that?

JP: It was the most brutally difficult course I had by a mile.

TP: You're not the first person to say that.

JP: Daniel is a phenomenal professor. I have a deep love for him. He was my academic advisor when I declared my major. It was a hard class. And I'm extremely happy that it was a hard class, because it meant I had to really put a ton of focus and attention on it.

I'll take a segue here to complain about interviewing. As I said, interviewing in the software engineering ecosystem is pretty broken. When we interview candidates for positions, we put them in situations where we say, hey, we're going to test your mettle based on your command of algorithms and data structures. Some of this is the content from 172, but a lot of the more challenging bits of it are algorithms you learn in 282. Every one of those interviews I did in the 10 years I worked at 1010data, in the interviews that got me the job at 1010data, got me job offers at Microsoft in all of those interviews, for the first decade of my career, they were almost singularly centered on content that you study in 282.

TP: It's that important?

JP: There's a lot that you have to learn on the job about the enterprise scale, application development, and software development. Those are skills that you have to learn in the seat. But as an industry, we demand that in order to get a job here, you have to show a mastery of the content in 282.

TP: So, it was hard, but worth it?

JP: It was easily the most valuable course I took. The work I put into that class, and again, the amazing work that Daniel put in, it was painful in the moment, but wow has it been useful in an ongoing capacity, both as the interviewee, but also as the interviewer. These days, I do a lot of hiring, and being able to assess someone's critical thinking skills, creativity, and capacity to be an effective engineer. You build the big muscles for those in a course like 282.

TP: Cool. Daniel will love to hear that, and it will encourage the students in 282. So let's shift gears a little bit. You've kept in touch quite a bit with the school, in fact, you're a member of the Hajim National School Council. Can you talk a little bit about that, and more broadly about your continuing interactions with the University of Rochester?

JP: Yeah. What I'll say is when I graduated from Rochester, I was pretty disengaged. I had my degree in one hand, a job offer in the other, and was like, "I'm going to New York City."

TP: Onward and upward!

JP: It was great, and then one day, I got a message from Marty, who told me in no uncertain terms that there was a new program being spun up called the Real Readers Program, and that I would be volunteering.

TP: Good for her!

JP: Marty was our mom, you know, the mother away from home for the computer science department. I have incredible love for Marty.

TP: If mom tells you you have to do something, you have to do it.

JP: So Marty said I'm volunteering for the Real Readers program, so by golly, I signed up and was assigned a student, and for all the reasons I've already talked about, in terms of things that I liked about being a TA in your classes or a workshop leader that made the parts of my brain light up. Being a real reader was fantastic. It let me connect with folks who, at the time, were only a couple of years younger than me. Through that, I got to see what was going on at school, and I got to provide a function that I wished were available to me as a student.

TP: What was that, specifically?

JP: I had the ability to look at these current students' resumes and tell them before they tripped over their own feet, before they crashed and burned in front of a live fire interviewer or application. I could tell them "here are all the things you're doing wrong in your interview." I had a lot of fun with that, and that led me to admissions interviewing. Initially, as an in-person exercise in Manhattan. Then, shifting to online interviews when the pandemic kicked in. That's how I started dipping my toes into volunteerism with the university.

TP: We appreciate that, here.

JP: That evolved into a now-defunct Hajim Young Leadership Council. This was a young alumni group focused on the engineering school. I was involved in that with several other URCS alumni. The council as a whole was a diverse set of alumni across all of the engineering disciplines, but the New York-centered contingent definitely skewed toward computer science. We planned a lot of events, we had a lot of fun, and the university gave us a budget to do really amazing things with. We got private tours of subway stations not open to the public. We brought professors down to give talks from the CS department. We had a great time with that. Then we were told at one point that the Young Alumni Council was being sunset, and we were all being folded into what they called the Visiting Committee.

TP: What did the Visiting Committee do?

JP: The Visiting Committee got debriefs regularly from Wendi, but it felt pretty unidirectional. We got a little bit more of a duplex connection, where Wendi was seeking our input. Wendy is an academic with an academic background. She knows how to run an academic institution, but a lot of the students in this institution are not looking for careers in the academy. They want to go into industry. So, very wisely, she seeks input from professionals in industry.

TP: What became of the Visiting Committee?

JP: The Visiting Committee has been folded into what used to be the Dean's Advisory Council. Now it is one unified group, which is the Hajim National Council. It has a similar function in that we meet on a regular basis, we get updates about what's going on in the engineering school, and we help shape some of the decision-making. We contribute in our small way to provide an industry perspective on some of the ongoing and upcoming initiatives.

And so that's what I'm doing there.

TP: Sounds fascinating. You were recently on campus for a different event?

JP: I was. It was my 15th reunion. Since joining the Hajim Young Leadership Council, I have come to all the Mel weekends that the university has hosted and have had a great time. I'll do a plug for any parents of young children. When I was a student, Mel Weekend didn't strike me as something that was a particularly kid-friendly event. It was amazing when I first brought my son in 2019. It was a great experience; both of my children love Rochester. They think it's a big carnival with games, kids' museums, and things like that. So we make it a family trip every year. I am up there for some of these volunteer meetings, in addition to the Hajim National Council, I also sit on the Alumni Board. I'll connect with all of those, but the kids love it, they have a great time. The university genuinely does a spectacular job at family programming these days.

TP: That's good to hear. Is there any particular advice that you'd give to young computer science majors at the U of R?

JP: When I got to Rochester, I was surrounded by people who had been coding and understood things. I worked very hard to make sure I was pushing hard and applying myself. I had an incorrect assumption that asking for help was an admission of weakness. I think that is, unfortunately, a common and very unhealthy perspective to adopt. Ted when I took your first class, I don't know if I went to a single one of your office hours.

TP: Still a little problem these days.

JP: As I grew with the university, I realized that office hours are not an admission of failure, that asking for help, connecting with your professor, your TAs, your workshop leaders, asking questions and engaging, that is a stimulative exercise. It makes connections, and things fire that might not have otherwise.

TP: Yes. Education is lighting a fire, not filling a pail.

JP: So, for a new student entering the CS program, I'll encourage you to connect with the plethora of resources that are offered: professors' office hours, your lab TAs, and your workshop leaders. These are folks who have stepped up and engaged. To be there to help you. Working with them is not an admission of failure, it's a reinforcement of enthusiasm.

TP: Do you have any other thoughts on the future of the computing field?

JP: The introduction of generative AI, these tools that can write code, has a lot of people asking a question, will software engineers exist in 5 or 10 years? The answer is yes. The people who will be in those roles, they are the people who have that curiosity, enthusiasm, and creativity. Generative AI tools are truly phenomenal at solving small nuclear problems. They're okay, in an unsupervised fashion, at solving medium-sized problems, and they're pretty bad at autonomously solving very large enterprise-scale problems.

TP: Do you have any other thoughts on the future of the field?

JP: I'll return to something I touched on earlier, which is that we are in a rapidly moving space. One of the best things I learned from URCS was how to learn things quickly, and to rapidly digest new systems, and use them effectively. In the seat in CS173, I truly did not understand why I was being subjected to a half-dozen different programming languages in the span of a single semester. It felt arbitrary and capricious. It turned out to be the reason that I got my first internship. It is the reason that it has been straightforward for me to pick up new languages, frameworks, and technologies. I started my career in a fairly narrow scope, and have had to expand it over time, and picking up new things is a straightforward exercise because of the skills I learned at Rochester.

TP: Any advice for the current crop of Freshmen?

JP: The tools that are white-hot today will not be the tools that are used when you graduate from Rochester and are looking for a job. That has always been true. That was true when I graduated, but it's even more true now as the clip at which these products are accelerating has increased. And so, the thing to do is learn how to learn. Don't zero in on a specific product or technology. Don't put all of your eggs in that one basket. I've forgotten more programming languages than most people will ever know. That's a skill I learned at Rochester, and it has served me extremely well in my career.

TP: So, what do you think was the biggest challenge that you had since you graduated?

JP: I was working at 1010data. Our very first customer was the New York Stock Exchange in the wake of 9/11. So we have this deep history with the New York Stock Exchange, a very, very tight relationship with them. They were in the process of rolling out a new product to do historical analytics on trades on NYSE. We were competing for this business with a bunch of other players in the space.

TP: Sounds intense.

JP: The New York Stock Exchange told us that they had built a framework they wanted everybody to operate in order to go through a variety of tests to prove that they are the best technology for the problem they wanted to solve. They said to run your tests, you can send us a fully baked version of the system, and we'll run the tests for you and tell you how you did. Or, if you want, you could come to our data center on Water Street, and you could set up in our data center. Then you could run the tests yourself, but from a firewall perspective, we absolutely, inflexibly cannot give you remote access.

TP: That's a challenge, for sure.

JP: I had a vacation planned. I was planning on going on a cruise with my wife, Kate.

I was told by my boss that I was not going on this cruise, that we were all moving into the New York Stock Exchange until we had this system up, running, and deployed. We canceled that vacation. My employer was very, very kind after the whole thing was over. They rebooked us on a cruise that was twice as long, and just told us to go and take the time off.

TP: That shows some class.

JP: But… we moved in and… we lived there. Some people would go home to sleep. Some folks were staying there. We had one terrible night… there was a sales guy who owned the account who was trying to be helpful. He was there the whole time; he'd bring us dinner. One day, we all went down, and he had a big, huge sushi dinner. We then went back to work; cranking on things we were not thinking about the air conditioning. We left this huge platter of sushi out in these conference rooms where the air conditioner had turned off when the business day ended. We got into a mite bit of trouble from the fish that had been cooking all night sitting out on that table. You don't think about this type of thing when you're sitting in a refrigerated data center.

TP: Oh dear, a bit of an embarrassing moment.

JP: But we worked on the system day and night, and we closed the deal. We got it done. At the beginning of this analysis, we didn't have the best technology. But with a lot of grit and a lot of ingenuity, we had the best solution by the end. We were the team that was willing to put in the time and the effort. I'll say none of the other products that were being considered in this bake-off had teams that were in the data center iterating, optimizing, and making sure that they were winning on all the dimensions that were being evaluated. That was certainly one of the most exciting moments of my engineering career.

TP: Cool, great. So since you mentioned it earlier. If we could turn to a personal note.

JP: Sure.

TP: Just so we have it on the part of the historical record. Can you describe how you and Kate met?

JP: Sure, it was in 2009. I was working for you, Ted. I was a teaching assistant in CS171. I was working in a lab. The other TA in that lab was Sam Atlas. We had split the lab up, working on things, and there was a certain somebody in this lab who was a smart study, and was something truly phenomenal to look at. In a moment of boldness, I asked Kate if she'd get lunch with me at Douglas Dining Hall. One thing led to another. We reached out to you with nothing but transparency in mind to let you know that this relationship was budding. And Ted, you, in your infinite wisdom, said, that's fine, Sam will be evaluating all of Kate's labs moving forward. The rest is history. We just celebrated our 13th anniversary.

TP: Congratulations.

JP: Two beautiful young children, a 7-year-old boy who is gonna be Class of 2043 at Rochester, and a 4-year-old girl. We got married on September 15th, 2012. On our wedding night, we called Ted Pawlicki, to let you know that this starry-eyed couple who met in your class had just tied the knot, and we wanted to let you know.

TP: I remember that. It was a sweet moment. Thanks for sharing it. Okay, anything in closing that you want to say?

JP: In closing, I'll return with a theme I've touched on once or twice already, which is that you don't know what the industry is going to look like. In a few years, when you graduate, in a decade, when you're in the middle of your early career, or in a couple of decades, as you move into your mid or later career. We are in an industry that changes too fast. Learning how to adapt and being curious. Those are skills that will take you farther than any knowledge of a specific network protocol or a particular programming framework, or really anything in that space. Curiosity and… the ability to pick things up quickly, that is… that is what you need, and it's part of what Rochester teaches.

TP: All right. Thank you. I'll let you go then. This has been great. It's great seeing you again, man.

JP: Ted, this has been fun.

2025 Commencement

All images provided by Juliana Rizzo

Recent PhD Conferrals

Image provided by Xiaofei Zhou

2025 Honors Research

Jingyuan Chen
Committee Members: Jiebo Luo, Hangfeng He

Multimodal Intelligence: Bridging Visual Synthesis and Sleep Analytics Advances in Long-Form Video Diffusion and Automatic Sleep Staging

This thesis presents two novel frameworks that address fundamental challenges in multimodal intelligence, specifically in long-form video synthesis and automatic sleep staging. In the first part, we introduce Ouroboros-Diffusion, a tuning-free denoising strategy for long video generation. By leveraging a recursive self-conditioning mechanism, Ouroboros-Diffusion synthesizes extended video sequences with enhanced temporal coherence and smooth motion transitions. Our approach mitigates common issues found in conventional text-to-video methods such as object drift and flickering artifacts hereby providing robust performance in generating visually consistent and engaging long-form videos.

The second part of the thesis proposes sDREAMER, an innovative framework for automatic sleep staging that employs deep multimodal fusion to analyze polysomnographic signals. By integrating EEG and EMG data through a carefully designed neural architecture, sDREAMER achieves state-of-the-art classification accuracy, offering significant improvements over traditional single-modality approaches. Extensive experiments on publicly available sleep datasets confirm that our method not only enhances prediction performance but also provides more reliable sleep stage detection, which is critical for clinical assessments.

Collectively, the contributions presented in this thesis offer a unified perspective on visual synthesis and physiological signal analysis. By bridging these two distinct yet complementary domains, our work lays the foundation for future research in multimodal intelligence and paves the way for more holistic approaches in computer vision and biomedical applications.

Tran Duy Anh Le
Committee Members: Lane A. Hemaspaandra, Anson Kahng

Hardness of Bribery and Control under Voting-Rule Uncertainty

In this thesis, we study the complexity of bribery and manipulation in the setting known as voting-rule uncertainty, where the attacker does not know which of a set of voting rules will be used but wants their attack to succeed regardless of which voting rule from the set is used. Our study is in the manipulative-attack framework known as the nonunique-winner model. We show that knowing the easiness or hardness of bribery for each of two rules does not determine the complexity of bribery for their joint use as an uncertain pair. We also establish results on bribery on a finite set of voting rules. We then provide results on constructive control by adding voters in the voting-rule uncertainty setting {k1-Approval, . . . , kx-Approval, l1-Veto, . . . , ly-Veto}.

Matthew Iceland
Committee Members: Anson Kahng, Daniel Štefankovič

Extensions of the Surprisingly Popular Algorithm

The Surprisingly Popular algorithm [PSM17] is a voting algorithm designed to accurately recover the ground truth answer from a crowd of people. One limitation of the original algorithm is that it is limited to binary or multiple-choice questions, and it may become difficult to implement in practice when there are too many answer choices. We present extensions to apply Surprisingly Popular to questions with an indefinite number of answer choices spread over a continuous domain. We use a single-peaked function to obtain vote and vote prediction distributions for each voter. We present related theoretical results for the new algorithm and test a prototype implementation on empirical data. Furthermore, we suggest improvements to make the prototype more effective in practice.

Undergraduate and Graduate Highlights

Faculty and Staff Highlights

Alumni Updates

Photo Updates:


The second project is with Bill Gerwick, a natural products researcher (NPR) at Scripps Institute of Oceanography. NPR is not some California incense and crystals thing; Bill dives in the ocean and retrieves novel molecules to bring back to the lab and then tries to figure out their structure. We've built several highly-used systems to map from NMR measurements of the molecule to lists of similar molecules to speed structure discovery. Recently, we've built SPECTRE (for SPECtral TRansformEr), a transformer-based system that can optionally take several types of NMR data (2D HSQC, 1D Carbon, etc.) to make structural predictions. And we just got our grant renewed!

Alumni Updates (continued)


Art Altman, MS '87: I retired from a career in energy-tech finance, and moved to Manhattan. I am doing portrait photography part time. www.artmaltman.photography.

Matt Boutell, PhD '05: Matt and Leah Boutell became grandparents last year when his son and his wife Julia welcomed their son Calvin into the world. Matt is officially a generation removed from his time in the department, as Caleb was born in Matt's first month as a grad student.

Aaron Gorenstein, MS '11: My wife Lenore and I were grateful to welcome our third child at the end of June. Ezra joins his big brother Raffi (2) and big sister Serena (4) in our cozy Westchester co-op. In professional news, October 2024 I ended my foray into databases/distributed-systems and returned to compiler work, accepting a role at Nvidia, joining the CUDA compiler team as a senior compiler optimization engineer.

Sudhanshu Gupta, PhD '25: I defended my PhD dissertation in July and graduated in August, starting in my new role as a Silicon Performance Architect at Meta Reality Labs. In this role, I am working with a team that is designing processors for the next generation of Meta's AR/VR devices.

Alice Kyburg, PhD '94: I am currently teaching an online course Making Ethical Decisions with Data for the University of Wisconsin Extended Campus for the Masters in Data Science program. I'm also teaching at the Martha's Vineyard Public Charter School. So much for retirement!

Richard (Nemo) Newman, PhD '87: I retired from UF CISE Department a few years ago to join a start-up. Since then I have founded another startup (Aerial Tech AG | Real-Time UAV Tracking Solutions) and am working part-time for IC2, a small engineering company in Gainesville, FL where I live.

Previously I consulted for Intellon Corporation, which was acquired by Atheros, then by QualComm, working on networking protocols for powerline communications. From that work I am co-inventor on 17 patents and helped write the HomePlug 1.1, HomePlug AV, HomePlug GreenPHY, IEEE P.1901, and IEEE P.1905 standards.

My wife Frances and I have three sons, John, James, and Julian. John is working in IT, Julian just graduated from Full Sail University in computer animation and is working with a small gaming company in Orlando, FL. James is making pizzas for a local company here in Gainesville, after graduating from the culinary magnet program at Eastside HS.

Massimo Poesio, PhD '94: 1) Possibly the most interesting news from this past year is that I became a Fellow of the Association for Computational Linguistics in December 2024

https://www.aclweb.org/portal/content/acl-fellows-2024.

2) Also in December there was a Dagstuhl workshop on 'Human in the Loop Learning through Grounded Interaction in Games' that I co-organized in which a number of well-known researchers in the area of using conversational agents in games for data collection shared their views over a week in beautiful Schloss Dagstuhl

https://www.dagstuhl.de/en/seminars/seminar-calendar/seminar-details/24492.

3) The Dagstuhl workshop relates to our work on developing conversational agents able to interact with players in virtual world games such as Minecraft
we produced a SciTube video about this research:

https://scitube.io/minecraft-meets-ai-how-virtual-agents-learn-to-collaborate/.

Isidore Rigoutsos, MS '87: I founded in 2010 and have been running the Computational Medicine Center at Thomas Jefferson University (TJU) (https://cm.jefferson.edu).

I established in 2019 and have been running an assured admission program to TJU's Sidney Kimmel Medical College for UofR undergrads from Comp Sci, EE, and Biomedical Engineering. See here:
https://careereducation.rochester.edu/blog/2024/11/05/computational-medicine-early-admittance-at-sidney-kimmel-medical-college-info-session/ and here https://www.rochester.edu/college/ccas/handbook/computational-medicine.html.

Eric Ringger, PhD '00: Here's my latest update! Rejoining BYU CS faculty to work on AI and global communication.

Andrea Salgian, PhD '01: I am now chair of the Department of Computer Science at The College of New Jersey.

Robert Schudy, PhD '82: I have no publications since the two books on online education.

I'm currently Commodore (CEO) of the Gulfstream Sailing Club, and president of the affiliated Gulfstream Sailing Foundation, which is an educational charity. The Club has taught over 5000 children and adults how to sail. My wife Liz Watson and I are currently in Greece, cruising with friends from the Club.

I continue to help churches reduce their carbon footprints and improve their sanctuary lighting. I got my start in this while I was a graduate student at URCS. The facilities manager discovered that I could quickly and accurately assess the energy use savings from facilities changes. He phoned me about once per week, asking that I evaluate something. He was a very good man and a delight to work with. The biggest single carbon reduction that I identified came from replacing the coal-fired steam heat system with a natural-gas fired power plant that provided hot water heat. That change took years and it reduced the University's carbon footprint by about 20,000 tons per year, if I recall correctly.

Phyo Thiha, PhD '19: I left my job as a senior data engineer at Amazon in early 2024 because of their return-to-office mandate. Since then, I joined a small real estate consulting firm, called John Burns Research and Consulting, as a director of data engineering (just an inflated title, to be honest). I am helping them migrate their legacy databases and data warehouse to Azure cloud with my team. Three months ago, my wife and I relocated to a city in the northwest of LA called Redlands. We are trying to get used to the dry weather here since we lived in south Florida before.

Will Walden, PhD '24: No big updates from me. My first year in the job has been good and I've enjoyed getting to know and work with a number of URCS alums at JHU, including Alex Martin (BS '24), Ben Van Durme (PhD '09), and Matt Post (PhD '10).

Gregory Wheeler, PhD '02: I am Professor of Philosophy and Computer Science at Frankfurt School; Head of the Computational Science & Philosophy Department; Academic Directory of the Master of Artificial Intelligence & Data Science Program. In addition, I am co-founder and CTO of Exaloan AG, a Frankfurt-based FinTech. The company was founded in 2019.

Mohammed Zaki, PhD '98: There are a few noteworthy items:

1) Elected as Fellow of SIAM (the Society for Industrial and Applied Mathematics), 2025, for "contributions to data mining and knowledge discovery, and leadership in data science."

2) Fellow of AIIA, International Artificial Intelligence Industry Alliance, 2025.

3) Test of Time Award at the EDBT2024 Conference (Extending Database Technology), for our paper "Reachability Queries in Very Large Graphs: A Fast Refined Online Search Approach," recognizing papers that have had most impact in research methodology, conceptual contribution, or transfer to practice over the past ten years.

4) Finally, I became the Co-Director and Site Director for the RPI-Stevens NSF IUCRC Center for Research Towards Advancing Financial Technologies (CRAFT).

Share your outcomes and updates with the department!

ugalumni@cs.rochester.edu, gradalumni@cs.rochester.edu

Connect with us in the URCS Alumni Group

https://www.linkedin.com/groups/12655649/

Articles and Accomplishments

Biking Across the Great Divide

by Dylan McKellips '25

Biking across the country was a blast. Every day was an excellent adventure. I saw many things and met excellent people. The days were long. I typically biked 10-12 hours each day, averaging the mid 60s mileage-wise and around 3000 feet of elevation a day. However, the descents were long and awesome, making up for the long grueling climbs.

Some highlights include seeing nearly every type of local wildlife possible including fox, wolf, bear, moose, pronghorn, elk, deer, rabbits, mountain goats, eagles, osprey, hummingbirds, feral horses, and marmots.

I also enjoyed getting off the bike and summiting 12 peaks along the way, eating sourdough bagels from local bakeries, and befriending other riders who were following roughly this same journey.

However, as predicted in the 2025 graduation address, I encountered much adversity. The short list is as follows:

- On my first day, I biked 73 miles through the remote Chihuahuan Desert (5 hours of which was spent walking my bike through sand pits), and ran out of water while the temperature peaked around 100. I then got sick from the first water source I found, and dragged myself into the nearest town after 20 hours of movement. A kind fireman provided me with Cool Ranch Doritos and clean water, and after taking a rest day to rehydrate I was ready to hit the road again.

- On my fifth day, I was in a large open field when a lightning storm came, striking as close to a quarter mile from me. I found shelter near a parked semi truck after 20 minutes of the most terrifying (and probably the fastest) biking of my life.

- I spent 9 days with a broken brake (4 days without my front brake, immediately followed by 5 days without my rear), including the most difficult and technical descent of the entire trip.

- I biked (carefully) for 5 days through the barren and unpopulated Great Basin of Wyoming with a broken spoke before finding a bike shop.

- My rear axle randomly snapped.

- I misjudged my timing entering Canada, and ended up having to bike an hour guided by moonlight (my headlamp died) in the region with the highest inland concentration of grizzly bears in the world, before fording a stream and taking shelter in an abandoned hunting cabin.

However, as (again) predicted in the graduation address, each obstacle was a learning experience that made me a more experienced and prepared adventurer (and left me with some stories).

Challenge is an important part of adventure (and life), and without it the trip (and my life) would be much less interesting.

Now, I've settled into research at Utah. I'm working on aggregating bicliques, which is a fun problem to work on. After spending my undergrad taking primarily algorithms courses, I'm finally learning how computers work by taking an architecture class and a programming language class. Recently a speaker (Daniel Kroning) came to Utah, and gave an interesting talk on accelerators. He's facing issues with locality, which Professor Ding's caching/locality research would be applicable to. My roommate, fellow URCS alum Leo Sciortino, found particular inspiration in the problem, believing tenancy was directly applicable. It was great to talk with him and make that connection. He also is facing a graph-based problem that seems interesting. I understand that Professor Ganesh Gopalakrishnan (who invited this speaker) will have Professor Sreepathi Pai traveling to visit him in the spring, and I'm looking forward to seeing him. Inspired by the systems group at UR, my lab has taken the lead on organizing a theory group at Utah, where we have weekly paper talks, and I'm working to organize lunches. I've collected intel on the local Indian buffets, and hope they will become a staple. Outside of class, I've been climbing a lot and working on house renovations (the house Leo and I moved into needs a lot of love, but we've made it habitable). All in all, life is good and the PhD journey has been an exciting one so far! I'm grateful for Professor Ding's mentorship in my undergraduate years that started me down the research road. I've found the lessons learned in his lab to be invaluable. I'm excited for what the future holds!

Images provided by Dylan McKellips '25

Successful 2025 EaGL Workshop

On October 11th and 12th the department brought regional leaders in theoretical science to campus for the 8th Eastern Great Lakes Theory of Computation Workshop.

URCS Photography Club

The club has been active this year, experimenting with various camera and film types.

Images provided by Neeley Pate and Professor Sreepathi Pai, URCS Photography Club

PhD Student Benjamin Valpey Wins

Best Paper Award

Congratulations to computer science PhD Student Benjamin Valpey, who won the "Best Paper Award" at the 17th NASA Formal Methods Symposium held in June in Williamsburg, Virginia.

URCS Students Solve Practical Real-World Problems

Hydric Galaxies

Hydric Galaxies by Jovanna Hu '28 (CS), Isabella Lu '28 (business), and Shea Ge '28 (digital media studies) takes second place in the Art of Science competition.

Interested in More Department News?

Take a look at our (new and improved) news feed to read about more papers, discussions, and awards.







This email was sent to cs-labstaff@lists.rochester.edu
why did I get this?    unsubscribe from this list    update subscription preferences
Computer Science Department • University of Rochester · PO Box 270226 · 2513 Wegmans Hall · Rochester, NY 14627-0226 · USA