Trevor Marshall (
After the event, we caught up with Trevor to see what he thought of AMD's offerings, get his thoughts on the hysteria over generative AI, and look back on his past as a concert musician. Read on below for a short interview with Trevor, a full recording of his conversation with Meryl, and a fireside chat on security and compliance with Wayne White and Lawrence Chin (
At 2Gather: New York City, you spoke onstage with Michael Brzezinski from AMD. When we spoke afterward, you mentioned you had been considering the AMD-powered C2D compute instances for a proof of concept you were working on. Did you work with AMD on that at all?
We tried spinning up some workloads. We have a very C2-heavy stack. Most of what we do is throughput-based. We're not keeping stake in a lot of processes, so a lot of the compute optimization chips that we're using are the best thing for what we're looking for, and that's most likely going to be the case going forward. Because it's the C2 family, we get the benefit of any other underlying actual physical substrate coming through. and the benefit of those improvements. We'll probably stick with that family over the next couple of years in case something else emerges.
Did you see or hear anything at this event that applied to your work in a similar way?
We've been PCI compliant for a couple of years. We're getting our SOC 2 attestation this year, so standardized control frameworks regarding regulatory oversight and technical oversight have been top of mind. There was a nice presentation from Palo Alto Networks regarding some of what's on the horizon when it comes to technical regulation, so it was good to see that. We'll probably look at some of what they call harmonized frameworks, because there's all sorts of ways of looking at basically the same technical control, and so we've taken that approach in the past and we'll probably just revisit that. Especially now that we're attesting to multiple certifications. That was cool to see and get more information about.
At 2Gather: NYC, you mentioned the tendency of some coders to get carried away experimenting with a new "sweet tool." Do you have any thoughts about how to manage that tendency when it comes to generative AI?
I think that there's quite a lot of moral hazard that's emerging. It's so easy to now get auto-generated code through Copilot or through other products that are emerging. No doubt, if you are an efficient developer, you can leverage that type of technology to become more efficient, produce more code, and things like that, but it's going to lead pretty quickly to an abstraction and a disconnect away from the actual business logic itself, where something goes wrong in production, you don't really know what's happening, and you're probably going to produce less efficient code.
Now, maybe some of these autosuggestions get so much better than the human that eventually they take care of it, but you always end up - - and this is the nature of our systems - - when we think about ourselves as engineers, we don't really hold ourselves to the same high standards that a mechanical engineer would where the tolerance is zero percent for failure. Software engineering has always had this built-in, "hey. some things are going to go wrong, but we'll have incident response and we'll make sure that we're operating as correctly as possible." Especially for a company like us, where we're in financial services, reliability is super important for us. As these gen-AI code production things come into production, and that "sweet-tooling" of, "oh, look at this sweet intelligent plug-in that now writes half my code," I'd just keep an eye over the next couple of years on some postmortems that emerge from code that was not written by a human.
I read that you used to be a musician. What was your instrument?
I played orchestral percussion and I wrote music.
Did anything from your music background carry over to what you do in technology?
Two big things came for me from my music background. The first was discipline. I was very hardcore, conservative. I was at the Juilliard precollege. Every Saturday from 8 a.m. to 8 p.m., I'm doing music, and then every day besides that I'm practicing 5 hours a day. I wasn't big into sports. I wasn't that big into education at the time. Knowing what it took to be exceptional in a true meritocracy, which until very recently, especially in classical music, it's still pretty much a complete meritocracy. There are some political navigations around that, but for the most part, you can't fake being a great musician, because everyone ends up finding out in some way or another. Even if you look at the hyper-produced artist, what they have is beyond music, as in image. There's an artistic integrity generally that's really hard to fake, so that discipline was really important.
The second thing was the creativity with writing music. Actually, a lot of the abstractions that would come up in writing music with metric modulation, those immediately had applications into algebra when I started studying math in college, which is the direction I took once I went to undergrad. It tickles the same part of the brain. So I think those were the two big things: the ability to imagine something and turn that into reality through creativity - - you have to completely understand what you're trying to produce when you're writing music - - and then the discipline of actually being able to produce it and get it to that place that you're thinking of.
DoiT and Current at Cloud Adoption Summit New York City:
Palo Alto Networks at Cloud Adoption Summit New York City:
Extra Credit:
