Speaker 1: And welcome back to another episode of Adventures in DevOps.
I'm Warren, your host, and today I am really excited,
and I know I say that pretty frequently, but I
am actually excited today for today's guest who we brought
in the show. Partner, general manager at Microsoft for developer Relations,
focusing on everything coding related, has quite the extended experiences
in consulting and software development, and before that, principal technical
architect at Disney. Welcome to the show, John Papa.
Speaker 2: Hey, thanks for having me, Warren. I'm excited to have
a conversation with you in your audience today.
Speaker 1: Honestly, I almost wanted to click record when we were
talking pre show because we're going on quite the conversations
about just everything that's happening in today's world at Microsoft,
other companies, security, etc. I think most of that is
just really interesting, especially throughout your whole background. I've got
to say though, early in my career, it was clear
to me that I I thought I wanted nothing to
do with Microsoft. I never thought I would touch a
Microsoft product or buy anything that Microsoft ever created in
a million years. But solely my perspective on that has
really been changing, and I've seen them transition through purchasing
quite the assortment of brands that the best that money
can buy, Xbox, the open source community most importantly, even
heavily into Linux now. And anyone that knows me knows
that I'm just like such a huge fan of vis
Code compared to all the other IDEs, there's really just
no alternative for me. So I'm like really happy that
you're on the show and I can pick your brain
about some of those.
Speaker 2: Yeah, sure, and we can talk too about I wasn't
too much unlike you for a period of my life.
So it's not a place I thought i'd find myself
back as Microsoft. But I am back here and I'm
all matted all Apple. All my products, everything I use
is not Microsoft os. So it's an interesting life I have.
Speaker 1: That's got to be a special experience to be on
the developer relations team and you know, not actually be
such an avid Microsoft product used there. This is your
PR department of anything to say about that, well.
Speaker 2: We'll see after they hear this episode. You know, all
the devices in hardware and o wes as they use,
they're all Apple. I just like the ecosystem and I'm
a web guy at heart. For the last fifteen years,
and fifteen years ago you wasn't really fun to use
web with Microsoft products and Windows and whatnot, and I
could tell you horry stories there. But it's gotten a
lot better. And the good news is today the machines
really don't matter as much as the cloud services and
the other kind of services. So it's the APIs and
the AI and Azure is amazing. I love the cloud
services at Microsoft. Big fan of those, big fan of
vs code. It's actually the biggest reason I came back
to Microsoft. So I was like, you mean, I don't
have to get a Windows machine. I don't have to
buy a Windows phone gasp or whatever else. They're like no,
So like, all right, I'm sold.
Speaker 1: If you can come back and not have to sell
your soul to the ecosystem and you have freedom of choice,
that's like, I think that's a developers dream come true.
And I have to say, before I was using vs code,
tried things like Sublime and Adam and Visual Studio code
back in the day when I was working at a
Microsoft shop and we were doing Visual Basic and then
net and I remember trying to run Linux and Mono
to even compile the c Sharp to run times for
Linux and it. They were just like standard things that
just did not work out of the box whatsoever. And
it's just so night and day now that the company
that had released these products that only under a certification
or licenses were you able to use are now leading
the open source community MPM, GitHub. It doesn't matter what
products we're talking about there as far as Git service go.
Microsoft is the open source community.
Speaker 2: Yeah, it really is. And Microsoft's is. It's funny there's
a cohort at Microsoft that's been around for a long
time who's been heavily into open source and big advocates
of it, and to be honest, for a while back,
and I'm going to say the late two thousand and
five twenty ten era, it was hard to be in
a Microsoft's OSS. And I worked there for two years
back during that timeframe, and I lived in Seattle and
then I decided to move to Florida, so I left.
I didn't have through with their open source policy, but
I was just like, you know, it was hard. It
was difficult because even then it was like I'd have
people on I had a video cast we did with
silver light and flash way back in the day, and
having people on using a Mac. It was very much
frowned upon. I'm like, but this is what people are using,
Like let's actually show the devices. Who cares a device
they use if they're using your service and products somewhere
in the story like that's part of the journey. Embrace
the differences, and it's completely flipped, which is what I
love about this. I went back to Microsoft to think
twenty seventeen, and at that point I was already convinced.
I was two years after vs code came out, and
I was part of that story of when vs code
came out as well, which I'm very proud of. I
was like you, I started the Visual Studio for many years,
and I was a dot net c SHARPVB, dot net
kind of person, and I got away from it because
doing web with that was just not working and for
a lot of reasons. So I got away from that
and I went to a Mac and I'm like, all right,
I'm going to try all the editors and I I
had an experiment for a year in twenty sixteen where
every month I tried a different editor. While I was
working at Disney, I tried Sublime out of brackets them
forgetting some of the other names web Storm. You know,
of course, what's now vs Code. I tried visual Studio.
There were a couple that are dead and go on
that I can't remember. There were blog posts about this
and they got the attention to some Microsoft people and
they invited me up to Redmond. I have to have
a conversation, and I felt like I was in this
cloaked dark room with a bunch of people I'd never
met before. Long story short, turns out they were planning
vs code and at the kind they called it Tacchino,
which is a region in Switzerland. And Eric Gamma, who
was the Gang of Four famous for the Gang of
Four Patterns book, was there. I didn't know you were
from Microsoft at the time. Creative Eclipse as well. He
was there, Chris Diez, Scott Hunter, a bunch of other
people at Microsoft like, what makes you think we wouldn't
make a great open source editor? And they started picking
my brains all things I liked about, all the different editors,
things I didn't like. Fast forward a couple months later
May of twenty fifteen, and they were like they were
going to launch it built, and they invited me on
stage to talk about it and I was like, absolutely,
it was just awesome, like, this is actually a really
cool editor. The biggest gap they had at the time
and they launched it was no extensions. Can you imagine
no marketplace or extensions for an editor. But they launched
it so fast. It wasn't there until a couple months later,
but it was still pretty amazing. But it really really
enjoyed that time.
Speaker 1: I do think that there was a huge change in
the usability of vis code by shifting to allowing not
just the marketplace but the external language servers to be
able to support those independently, which may mean through extensions
or realistically through the architecture. I do understand the challenge
with with marketplaces, though you're talking a lot, and I
think this is one of things we see today malicious
actors utilizing this as a mechanism for deploying vulnerabilities into IDEs.
And I think the biggest one that came out was
this Darkula theme that had just as many downloads as
the dark theme of Dracula. And I think it's a
really cleverly named too extension because it sounds like it
should be Darkula if you really think about it. And
so just so many downloads and just militia. So I
understand the reasoning there, but it sounds like you are
to thank for the vs code experience, the ide experience
that software engineers have available today. Maybe not in the
last couple of years. You know, we can thank the
viobecoders for that.
Speaker 2: Yeah, I definitely had a hand. It's a very small
hand in that. I know. It's definitely wasn't all my
opinions they took, but it was nice that they reached
out too. Again, think about it. They didn't have to
do this. Yeah, they could been like, we've created a
visual studio, which at the time was the largest editor
in use anywhere in the world, bigger than any other editor.
I don't know how many millions and tens of millions
of users. But they could have been like, build here,
not invented here. You know, we're going to do it.
We know better than everybody else. And they reached out
and looked for people to figure out how to make
this work. And they still do that. We still do that,
which is one of the things I love about working
in Microsoft is there is a It's not the whole
company like you know, company is huge, but there are
parts of the company that I work with that I
love because like developer division, they are always looking for
how do we get real live customer feedback. Who are
these people using these things and what do they do,
what are they like, what are they not like? And
to me, that's what makes me thrive and develop relations.
Speaker 1: One thing that I actually will follow co hosts is
not here today often talks about, especially with the product
management experience, really trying to figure out the difference between
what you are building or what you want to build
and then the product you actually end up with once
you take customer feedback is just so different and often
if you're not paying attention, you will end up with.
I think this is why we see a lot of
startups historically fail is they're not really doing the product management.
And I see a lot of startups today they realize
that they have this need for business or sales or
marketing even and then engineering if they have an outsourced
that unfortunately, but they still don't understand the goal of
product management. They don't understand that, you know, where they
want to end up with six months or a year
or five years down the road, because they're so focused
in maybe VC funding or just getting investment and so
that's for sure the thing that feels like it gets
thrown out the way. And I can understand it though,
because it's very difficult to find good product managers out
there that actually want to understand and do the market research.
And the fact that specifically vs Code but really Microsoft
has taken this approach really shows that you can understand
the long term market here rather than just release something
and having an opinion based development strategy.
Speaker 2: Yeah, and I'm sure it happens more often than not too,
Like there's definitely we release the product. It seems like
we're such a big company all the time, like every day.
But like with VSCO, what's great is there's no more
a release cycle like the years ago. When I worked
at Microsoft back in the late two thousand era, it
was like once a year you get a version of something.
You know. Now, if you go more than a week
without seeing a change in our product, you're surprised. Although
I do wonder it's funny. We used to make fun
of jovscript Flavor of the Week back when jobscript is
going crazy. New Framework of the week would come out
and then just disappear. Now it feels like, are we
like hitting people with new AI feature of the week.
You know what's going on out there, not just us,
but you know Anthropic and Amazon and everybody in meta.
Speaker 1: There's so much we can say here. I mean, I
think you're onto something, and I think part of it
may just be the PR news cycle realizing they need
to keep the ball rolling with whatever audience that they've captured.
They need to throw something otherwise like, oh, well they stopped,
they stopped innovating. That means they're not doing anything anymore.
And what was interesting is actually on the previous episode
that we just recorded with incident IOW, we theorized that
we may be at a point where we have all
of the whatever innovations we've had with l lams have
come to the maximum point, like from this technology, and
now it's no longer about building something better, but we
can actually build stuff with that technology more so than
try to innovate in that space specifically. But yeah, I
see a lot of these product release features that we
see out there today and they don't really make a
big impact. But it's interesting because especially with a VS code.
Maybe I'll ask you specifically what you're feeling is on
like the copilots of the world, the things that in
our experience we get really close to integrating with. So
we're using an ID and we're talking about autocompletion or
just engaging with just collaboration inside our tool of choice.
Speaker 2: Yeah, I think it's I think where it is today
is not where it's going to be in a couple
of years, first of all, and all the products. I
don't have any insight on this that I'm sharing just
other than my feeling is this does change so fast,
and you go back to a couple of years ago
and copilot came out, it's nowhere near what it is today,
clearly and effectively. For a while, people and I think
a lot of people still think it's just autocomplete on
steroids where you're typing and suddenly you get a suggestion
and there you go. There's some more code. But there's
so much more can do. And this is because of
all the competition that's out there, and because the rapid
rives the models and the way that they're using this,
and all the chip usage in the back end too,
which we keep it about. You know, a ninvidio must
be loving that you look at this. And I think
where we are now is We've got this world of
agentic AI, and what I mean by that is the
most effective way to use AI in our tools today,
whether it's WebStorm or Intelliga or clar ser Visual Studio
Code or Claude or whatever it might be, Cursor when
serve who knows all these tools are relying upon these
AI models in an agentic way. They want to be
is my words, they want us all to become managers
of agents. So the future of developers, and I'm a
developer at heart, then we're for decades. It's not me
managing a team of twenty people offshore and in house
to get my work done. There will still be those people,
but all those people are now going to become managers
of AI agents. So imagine this. We've got a backlog
of work, we use an agent inside of vs code
for example, or Cursor or Claude or whatever you choose,
and we use an agent to read our spec files.
Requirements are business users, which, let's be honest, eighty percent
of the time it makes sense to us as devs.
In twenty percent of the time, we have no idea
what they're asking for, so we just guess right. Hopefully
we ask that's.
Speaker 1: A little high for me. I think I'm willing to
go as high a forty or fifty percent.
Speaker 2: Yeah, yeah, But it depends how honest you are with
yourself and how much you want to ask the business people,
like what exactly did you want? And then I go
back and work on my stuff with the agent and
come back an hour later, and all that stuff's there.
When you think about that, at the end of the day,
you could literally have ten issues ready to go, you know,
with your manual review. I would never recommend automatic pull
request merging. And I'm going to say right now that
by the time I retire and I'm out of this industry,
we're not going to have that. Please. I don't want
that happening. I want a human to be there to say, yes,
this is good or no it's not. But I do
love the fact that the agentic world is pulling us
to this era of we're going to be agents of
sorry managers of agents.
Speaker 1: I like your optimistic perspective, and I also like the
autimistic perspective of expecting that humans will be in the
loop there. I think part of the trouble is that
we often see a lot of companies spinning up with
this belief or their marketing materials saying otherwise that you
can just go to town and it will do everything
for you. And then you end up with like the
replets of the world that are deciding to just delete
production databases filled with user data because that seemed like
a good idea at the time.
Speaker 2: Yeah, format c colon slash, Why is this a good idea? Agent? Absolutely,
run with it. Yeah, I hear you.
Speaker 1: What's really interesting, you know, from that perspective that you've shared,
is that I feel like, I don't want to say
GitHub specifically, but maybe it's Microsoft, maybe it's get ub,
maybe it's just vis code. Whatever the agent is that's
running there is having the expectations about how to do
software development or how to do each of those pieces specifically,
knowing that it should, say, breakdown a particular request, user
request or support request, et cetera into things that could
be user stories that then can be converted into tickets
and then run with that and I find that that's
the thing that needs to be done. And where we're
at a mismatch is a lot of these agents today
are focusing on, like as you said, managing them and
telling them what the right process is. But I find
that that's the whole challenge, making sure that there is
the right process in play, making sure that it is
not commenting on those if statements, knowing when to make
the right trade off set as a still have to
convey that context to the agent in order to make
it do those things correctly.
Speaker 2: You do, and I think you're hitting the nail on
the head with a couple areas. One is you have
to give the agent's context today. I'm sure that'll lessen
over time. Like there's some things that probably would make
sense for the agents and the models to just all
not go learn, Like, come on, good comments should be
a thing that isn't we all disagree on in the world,
So models should figure that out. But what your process
is would differ from company to company or even team
to team. So you've got to give it that context.
And that's where things like Agent's MD, which has become
like the universally accepted or unofficially adopted this is how
you tell your tools, whether you're using a VS code
or CLAUD this is how you tell it that this
is what you want it to do. But the other
side is, and I think we missed this a lot.
Is that the skills that we've learned over the years
are still very valid, Like you still got to have notice.
I'm not saying skip having issues, skip having a backlog,
skip having pull requests and code review. No, all that
is good context, small pull requests, good idea. I'm putting
that in my context from age and MD. Please don't
give me a forty file you know, seven thousand line
PR I don't want it. I can't consume it. I'm
either going to reject it or just accept it. And
God forbid I accept it because now I don't know
what half of it's doing. There's skills that we've learned,
whether you went to school or not, and that's not
part of this chat here, but you've learned skills as
an engineer over the years. Those skills are not going away,
Like that's a foundation. Will you be doing those And
let me give you an analogy of this. I learned
SQL years ago in college, like I had whole course
on it. I wrote four books on SQEL in the
late nineties. Nobody really gets that anymore. And it's okay,
Like that is a lower level language now that we're
using tools to write for us and do for us.
Is it a skill that I think should have gone away. No,
because there's times you need to look at those sequel
statements to understand how is it actually getting the data?
Is it doing it in an optimal efficient way? Is
it actually getting the data? I think it is too
in some cases, Like that's still a skill to have,
but it's not a skill. Whereas in the nineties you
might be writing equal statements for two three hours a day,
You're not writing for two three hours a week anymore.
It's completely different, and I think that's a good thing.
The skills that we've learned along the way, even before AI,
were really valuable to us getting to this point. And
hopefully we can use AI to continue to make the
tooling better, to abstract some of those away that's more monotonous,
and then give us insight into here's places you need
to look. I created this code. Is this logic what
you wanted? And that's the kind of stuff I'm looking
for AI to give me more on is be that
para programming partner. I want agent to be that thing
that gives me a gut check to rubber duck. And
I still want to have that human involvement. I do
think it's a mistake when people start talking about and
I'm not suggesting you were, but I've heard people say that,
you know, we're going to get to a point when
I didn't need to learn computer skills. No, and let me
leave you with this thought on that. I had this
wonderful tweet, which i'll keep anonymous, where somebody put out
earlier this year my whole SaaS system was built with
some tool zero handwritten code. AI is not just an
assistant anymore, and yes, people pay for it. And then
just a couple of days later, the person's like, I'm
under attack. Ever since I started building this thing, and
I'm paraphrasing, we maxed out on API, people are bypassing subscriptions,
creating random stuff on the dB. I'm not technical. Sos
take me longer than normal to figure out. For now,
I'm just gonna stop sharing what I do publicly on
the social platform. And there's just some weird people out there.
Speaker 1: Yeah, that's a canonical security ye obscurity there to solve
the problem.
Speaker 2: Yeah.
Speaker 1: I almost want to take the side of the vibe
coder and you know, argue against this, But first I
think it's it's really interesting to see that there was
a recent release by an executive working at a cloud
hyperscalar who suggested that it was a good thing to
have such a high percentage of code being written by MS.
Almost on the same day there was a huge, major
incident at the cloud provider that took much longer than
previous incidents to actually resolve. And I I think we
see these and I worry that they're going to happen
more and more as we potentially are keep getting closer
to wanting to pull the human out of the loop there.
And you made an interesting point about expecting, say the
pull request that an agent or some LM is generating
for us to be small in nature. And I really
wonder whether or not it wouldn't be better to stop
thinking about code being generated, just like we stop thinking
about the lower primitives of bycode, or what happens in
assembly after the linker and integrated before you know, after
we compile it are running and realize that maybe that
tools I get are you saving the diffs, Like that's
not the optimal output that we could be capturing when
utilizing an agent. But I don't know what the right
answer is because I do see these other systems that
are attempting to jump in the middle here, and they
suggest that you commit specs to the repository and you
review those. And I don't love that either, because I
feel like the output often is highly fluctuates based off
of the model you pick or the generation, and as
you pointed out, you still need someone to review it.
And how can we review millions of lines of code?
Just as that I know what every developer is thinking
here testing and debugging code. That's my favorite part of
being a.
Speaker 2: Developed You know, you're reminded me of again going back
ten years when I was at Disney. So I worked
at Walt Disney. It's part of my history and I
live five minutes from Disney. In fact, I'm going there
tonight for dinner. My role there was to basically do
engineering excellence, which is just a group of basically saying,
how do we make sure that everybody across all these
places around the world are developing the same way. First
I told my vice president, who need didn't like this.
I don't think everybody should develop exactly the same way,
and he's like, well, that's too bad to your job.
So we had an interesting profession relationship. But what I
did was, I said, you know, I think there's certain
things we should all agree on, you know, whether you're
using different languages or processes or tools. And I came
up with just to because I worked at Disney. Everything
begins with the D at Disney, you know, Disney, Disney Parks,
Disney Land, you know. So what I came up with
was the seven d's of development and everything was there.
I'm like, all right, we got to think about these things.
And I'm gonna this is going back about fourteen years,
so bear with me. I think there was. There was,
in no particular order. Documentation. You need to have some
kind of docutation what the heck you were doing, usually
from the business people in general talking about that book,
biggest big book of specs that you get, you know,
twenty years ago you and throw down the garbage. So
some kind of documentation. You've gotta have some kind of
design work, like before you actually built it. Maybe you
should like figure out what you're gonna build first before
you just sit down, even if you're vibe coding today,
like you've got to have an idea of what you're doing, right,
So document design actually development there's the big D, right
that's going in there. There was destroy, which was testing,
so you've got to have a way to destroy it.
It had to be a D. So got to find
a way to put a D in front of testing.
Let's see what else do we have. Deploy was one
of them. I'm leaving off that I can't remember. And
then the final one was I couldn't come up with
a good D for reviewing, so I called it and
I'm Italian, so I called it the review. So the
seventh day was the review. You gotta do it. So
with this review, effectively you had to have a code
review process. And we put these things in place. We
made posters of it and everything. We used Marvel characters
because Marvel was big back then, and said everybody's got
to do these seven things. Notice none of those said
you've got to use Java or Python or JavaScript or whatever.
It didn't say I had to use aws or Google or Azure.
It was all about making sure you had the process
in place. And part of the the reviewer process was
you had to have two people reviewer code who weren't you.
And that was the most contentious thing that I ever
did there because people were like, well, no, I got
to deploy, man. Okay, so you're gonna write code and go,
and let me tell you what happens at Disney when
you just write code and deploy. I have two interesting story.
So I was called into this. They called it the
war Room at the time, which was a terrible name
for it, but it gives you an idea of when
they deployed. They basically had this massive room that looked
like thing out of you know, Defcon three from Wargames
movie in the early eighties, and they would deploy and
they'd have all these systems online looking going, okay, we
just deployed a thing over here to this park. Is
the rest of the park still running? Like, let's make
sure because everything was entertangled back then, you know, we
didn't have all this separation in this world tech nowhere did.
So they called me and they said, okay, we have
a problem. We just hired this company to and I'll
keep the company names out of a company to come
in and basically create locks on all of our doors
of our hotel rooms. Keep in mind, Disney has like
thirty resorts, and I don't have many rooms they have today,
but there's probably one hundred thousand rooms. It's probably the
world's largest single place to have hotel rooms. And like,
we picked a couple of the resources that do this
test with them and we deployed it. And the deployment
was effectively that when you use your magic bands, which
of the time were just coming out. So first wearable device,
you know, talk about fifteen years ago, you tap it
on the door and it will unlock your door sever
a room key today that's everywhere. Fifteen years ago this
didn't exist and this company's everything failed everything, and they're like,
can you help us figure this out? And so we
had the people at the company who create the locking systems,
like that's what they do is create locking systems. They're
not highly into the tech, right, they knew the tech,
but not as much. They're more locks. Then we had
our developers, and then we had our basically our executives,
and they're all trying to talk and it was like
talking three different languages. You know, that's Tower Babbel kind
of thing. And they're like explaining it. I'm just sitting
back and listening. At one point they go, yeah, and
you know, we're not sure where the problem is because
here's what we do. This is the process, and they're
explaining the process of how the lock signal goes to
the server, which is under a desk at the front
of the hotel. I'm like, first thing at peak my head,
I'm like, where is it? All right? Keep going and
like yeah, and we're using what kind of Davis using? Oh,
we're using this thing called the Jet database. And everyone's
like yeah, yeah, yeah, no one had heard of it.
I'm like the Jet database and like, you mean the
thing that runs Microsoft Access And they're like yeah, why.
And at the time, Access was not a multi user
I didn't even know if Access exists anymore. Gosh, isn't
I work at Microsoft. They were basically running five thousand
rooms at this one resort, and they're locking mechanisms off
a single database underneath the front desk hotel server, you know,
on a single power strip with no backup, on a
database that doesn't handle multiple connections. And on top of
it all, they had a router that only handled one thing,
was handling all five thousand switches one call at a time,
and if there was more than one, it would back
up the second and it would throw away the rest.
And they asked me what if I had any suggestions
and I said, yeah, don't do that. And I'm telling
you this story not because it's a rip on the company,
but to say this happened because they deployed without trying
or having odds people look at things. One person had
the idea to try this, and that person worked for Disney,
so it's not just the company's fault. And that person
was like, Hey, let's deploy it, give it a go.
I guarantee you if more than one person looked at that,
somebody would have said, hey, wait a minute. And well,
of course that stuff's all result today and much more
multi ten and yell. And I am taking a little
liberty with some of the discovery there, but that's how
happens when you don't have people look at your code.
Speaker 1: I hate the story because I totally believe that this
is actually still happening at some companies today. Yes, like
hands down, no question, But I do fully believe that
these sorts of things that are fixed and improved at Disney.
And I just for anyone who's just like listening now
and not watching the episode, I have to say, Johnson
one of the most amazing recording rooms that I've seen.
I mean, there is memorabilia all over the place. It
is quite a joy to look at, with stormtroopers and
the octocat and multiple Mickey mouses in Italian and you've
just got too many things here to name. I think
your Obi wan Kenobia's blinking red in the background for
some reason.
Speaker 2: Yeah, he is. I'm not sure why. I think that's
just a light, a trick of the lights, but I
see it. I just noticed.
Speaker 1: And I still think that's quite an innovation in the
last fifteen years to really focus on well ninety nine
percent of your work is like not even doing the
development realistically, and I throw in business practices there, like
you're at the end of the day, you're there to
solve a problem which is realistically walking and unlocking you know,
in your example from Disney, the hotel room doors or
the customers, rather than you know, solving just an arbitrary
software problem. And when you're looking in that regard, and
I think this really just makes the whole story about
getting customer feedback and really testing it in a way
that makes sense, and not just deploying it and calling
it a day. And I honestly don't where where're going
with this, but.
Speaker 2: It's the human involvement, right they yeah, no question, Yeah,
you know there was. There's something else you made me
think of a testing too, which is a different story.
Not as long as we were working on something. We had.
This thing used to be a think called oh my gosh,
Disney's Magical Express. Basically they pick it from the airport
and a bus and bring it back to the hotels.
And there was the system basically where they had some
custom devices before iPhones and stuff were super popular. iPhones
were early addition at this time, and they had these
like custom Android devices or Windows Device can Remeer, which
they were where you could basically build give it to
the person at the airport who work for Disney to
say it's hey, it's warrant, and he's here with his
family and the four bags and they're going to you know,
this hotel the Contemporary. They get on the bus, they're
on bus forty two. The bus driver has it, says up,
they're here, and they get to the hotel. Somebody checks
them in on the app again in the same kind
of device, and they get in. It's just a very
simple app process, not a lot of functionality, but it
helps I think at the time, it was running twenty
five million luggage pieces a year. It was insane, like
the amount of fruit. But this thing was going through
and there were people, and we had to read to
build it for some other crazy reasons, and we had
to rebuild this quickly. And I remember the biggest contentious
part I had was like we don't have I said,
I want to do a field test, Like we don't
have time for field tests, Like I know this works
sitting in my cube, but I want to go to
the airport, get on a bus. I want to do
all the steps I don't have to give to all
this users. You don't want to, but letting me be
the person who does it, And like, why would you
want to do this? I'm like, because at the airport,
I'm on airport Wi Fi on.
Speaker 1: The buses right there, right like yeah.
Speaker 2: And then I'm on cell phone when I'm on the bus.
And then when I get to the resort. There are
two Wi Fi signals at each resort. They guess the
one you can use when you come Warren and the
one for the cast members the people who work at Disney.
So I'm like, I don't know how this thing's going
to behave based upon the switching of networks, because each
one has different security levels, different security you know, to
do it and lo and behold, I did it anyway
when they said not to, and me and my buddy
went and did all this, and we found that the
switching of the Wi fis and the cell phones again
ten years ago did not work well. We had we
had to change things up, and the speeds were so
completely drastically different. We had to change what kind of
data was requested at each stage the way too. And
this stuff comes in play. If you don't test it,
how do you know? I mean, can you then we're
deploying this a Christmas By the way, can you do
you have any idea how many people come to Disney
at Christmas? Like? Can you imagine if this thing broke
down and all these unhappy people not being able to
get their stuff, and all it took was me four
hours to get on you know, go to the airport,
get on a bus and drive back.
Speaker 1: I always found that so ridiculous when someone says we
don't have time to test it, because you know there's
the then I don't do you have time to spend multiple
sleepless nights to debug production incident while it's happening like that.
That's the trade off there.
Speaker 2: I'm want to do enjoy Christmas break without being interrupted,
you know with my family. That was my motivation, but.
Speaker 1: Comes out of a different budget that comes out of like,
you know, the production budget rather than the you know
the budget.
Speaker 2: Yep, And it did by way. At Disney they had
they had development, then they had sustainment, and sustainment was
a completely different budget. I'm like, why do we have
such a big sustainment budget, Like maybe if we did
a better job up front, we wouldn't need to have
so many problems the back end.
Speaker 1: Well, I think the incentives drive a lot of things
in this world, especially in software development, and I think
that's one of the things that we see now starting
to cause problems in just the organizational structure and tech
companies where we're we're somehow decided all of a sudden.
You ask any software engineer, even I'll say tech lead
or software manager is evaluating people on the lines of
code like the sheer number that they produce a good
metric for success, And I don't think any of them
really say yes. I will say there are some parts
of the world where they believe that the answer is yes.
But everywhere else, I think everyone agrees that the answer
is now. But then we see these technologies that we're utilizing,
and we're getting to a point where people are being
I'm honestly rewarded, but maybe punished or not delivering by
sheer quantity as much as they have before. And I
just I don't see the incentives growing to meet the
changing world that we're in because arguably, if the job,
the development, the creation, the design, the testing is becoming harder,
so then is the management of those things as well.
And I just think there may be a challenge to
also evolve the management of technical resources to the twenty
first centric.
Speaker 2: I think the way we actually look at what makes
a successful a really good developer in the future, what
makes them a good developer. I do think at one point,
probably a long time ago, in lines of code was
a good thing. I mean, I got them glad I'm
way past that point. But in fact, I create a
presentation years ago which I keep evolving cold readable code,
and I did a bunch of research on this for
it used to be clean code, which was a big thing,
and I said, Joe, clean code's good, but what a
readable code? And because you think about it, and the
more studies you do in this, and I think it's
getting more true today with ai IS. Before AI, I
found a bunch of studies at show you spend ten
times the amount of time reading your code then you
do writing. You think about it. We've been lying as
developers for years. People in your family go, what do
you do for a living? I write code? Do you
do you really or do you just literally spend eight
or your hours a day reading code that you wrote
already and kind of tweaking it and moving it around
and refactoring make sure it works. And then with AI,
AI is writing a lot of the code. I'm okay
with it writing the code. I'm not going to get
rid of the reading part. That's the part I find
is we need to be there to make sure it's
doing it. I want a human to be there on
the line for this, because the human's going to be
one as to fix it. If we're in a completely autonomous,
ancientized world for everything to me, that's not We're so
far from that at this point, and I think it's
unrealistic to put us there in the near future. Velopper's
roles are changing. I have no problems. So I'm like
what you said at LM's ready code, I'm have a
problem with any company or using LM's write code. I
do have a problem with them going oh the code
has been written, push go ah, let's fire the developers
and now let's just push. To me, that is I'm
shocked we're not having more disasters because of that kind
of stuff.
Speaker 1: You know, I'm not as shocked because my shock level
hasn't really gone down since I entered the professional world.
Like once I graduated and I went to work for
a bunch of companies and I saw the code that
other engineers were writing, I was shocked that there were
any systems in the world that could work correctly. Yeah,
deployed software on on satellites that never got an update.
Always amazed me how those things could run like bug
free for decades even, And I'm just like wow, realistically wow,
because I look at what's generated today and I have
zero faith. And so there is a thing where the
thought is that LMS and any sort of agentic system
raises the floor up and so on average, the median
is better than it was before. But the expertise that
and into the software development process isn't being improved where
we're not raising the ceiling in any way. So you
still have to be as you pointed out earlier, you
still have to be great at everything that was there
in the past. But people with less ability, you know,
in experienced engineers, are now able to produce things that
are slightly better. If I look at that perspective, it
basically says lms don't help us produce not just LMS,
but any sort of system built on top of them,
don't help us produce better products or more reliable solutions
or anything like that. But it does help people to
potentially learn or And there's even a questionable answer about
learning there because it was a study published by a
Microsoft back sponsor about the reduction and critical thinking when
you pull in automated systems like LMS et cetera to
actually do the critical thinking for you. So there is
a question of you know, where exactly is the best
place in the process for us to actually pull these in.
You know, what are we missing out in society where
this is the right thing? And I think you started
off this episode basically asking, you know, what is the
point where is the actual goal here? I love it
as like a science fiction a direction that we've gone
where oh, yes, now we have these tools that automate
lots of things. I think automation was another area where
a lot of people were rightly concerned early on that
you know, automation will take away jobs in some regard,
but there was a goal there. It was we can't
scale effectively enough without automation. And then that leads me
to believe what the LM revolution or AI revolution or
whatever you want to call it, that the problem is
being able to scale, being able to deliver a factor
more products or technology or software than we would app
before without it. And so that for me makes the
question did we need more things?
Speaker 2: I don't think the humans ever need more things. And
think about it, This goes into a less my father
taught me years ago. The more money you make, the
more you will spend. Right, you will find ways to
spend your money, and I think we'll find ways to
spend our free time as well, which is fascinating. It
wasn't a pan recently about AI, and we had some
very different opinions on where AI should be. And one
of the questions that always in my head is what
problem does that solve? Or a better way to ask
is maybe a kind of a nastier way to ask
It is Okay, ifenderu I future, you're gonna go tell
your friend about Okay, who asked for that? Okay? Sometimes
we're just creating AI for the sake of AI. Doesn't
it feel like that? And you just pointed out Warren
a great thing that's happening everywhere. I don't think we
all see is that AI is being used everywhere. Nobody
knows where it should be used. So what's happening. All
the companies seemingly are saying, let's AI everything and we'll
see what things actually stick. And I know there's more
strategy behind this, but it feels this way, and to
a degree, I think a lot of the places we're
seeing AI today some of those will not exist in
the future, and others they absolutely will and they'll double down.
That's probably how you think about the Industrial Revolution when
it came about, was probably like this, let's automate everything
and let's figure out what actually works. Okay, you know
we can actually do like conveyor belts and things like that,
and machines to generate and create things, but maybe we
actually still need a human to, like, you know, check
quality control because I want to make sure the thing
we just created actually still works like a car roped
the assembly line. I think we're going to find that
more with AIS. There's got to be places that the
human has to be there. And it's it's one of
the reasons I love the name co pilot so much,
and I believe it was Nat Friedman, the former CEO
of GitHub, was one of the creators of the co
pilot name when they first came out with that, and
it's because he's also a pilot of airplanes. So the
story goes that basically, it's like, it's not someone who's
going to replace your job or take it or do
the work for you. It's a pair programmer. It's a
co pilot. You're the pilot and there's someone next to you.
It's this AI tool, not someone but a thing, and
it's working with you. And I like that model because
whether you know, LM's are big a couple of years ago,
and you know, and then it gets into, oh, we're
going to do all this AI agent stuff and who
knows what the next thing is going to be wherever
this goes, if we relinquish the ability of the humans
to be playing a major factor in this. You know,
we laugh at the whole thing of Skynet with Terminator,
but really should we be laughing at that? Because what
do we want us to be? Where's our role as
humans in this? And I do think we need to
play a big role in it. And it's one of
the reasons I love things like Get Up Copilot and yeah,
you know, my team does like Java, Python, that JavaScript,
et cetera. We do a lot of different languages. But
the language wars are over in my mind. People still
fight them. But I'm like, all right, I am going
to use an AI tool to convert from Python to JavaScript. Sorry,
It's just why would I spend my time learning the language,
you know, so in depth that I've already got when
I can use a tool to help me get that
foundation and yeah, and then I'll tweak it and have
somebody look at it. But those are the kind of
things to me AI is good for. Or are generating
the foundational pieces for my new application. You want a
vibe codeed to get it going, sure, but then still
have a process, use software engineering processes that have been
hardened for decades. Make sure all that stuff's there, and
get humans involved to work with it. I just think
if you don't have that, and like release control, version control,
branching strategies, CICD, these are all still very valid. The
only thing I worry about a little bit is I
worry about the idea that, yes, the floor has been raised,
so anybody can code now with these tools. Yes, but
I'm not a huge fan. I'm just going to put
it out there. It might be contentious. Not a fan
of Hey, put your startup idea into this tool and
I'll generate everything for you and it just works prompt
trusts me. Really, it's not a fan of that, and
I like it for a starting point, but then hire
somebody to actually look at it.
Speaker 1: See, you know, I think some of those French things
I do sort of understand though, because if we look
at the startup world, the value in the process here
was sort of idea validation, which requires the human feedback aspect.
And those companies that are switching to using either vibe
coding or some sort of other LM to generate a
lot of their code for them were potentially before it
needed to get funding and then just outsource the software
development to build a prototype in first place. Arguably, I
am not a proponent of outsourcing critical internal competency. If
you want to be a technical company, out like to
an outsourcer to build something for you, because it's I
think it's very similar to the result that we get
when we use an LM. So I think in that
regard there is a short circuit there. But I think
what you've made me realize is that maybe the metric
for value in our process or in the output that
we have is the number of human hours that have
gone into it. It doesn't matter what tools you use, or
how many outsourcers you use and whatnot. The result is
like internal into the company when you're building that product,
whatever tools you're using, how many hours are you putting
into it. You don't get to short circuit that in
any way, because that's really the intelligent part of the process.
It doesn't matter how great those lms are for us.
As you pointed out, I think the reason you're thinking
about having a human in the loop is because you
recognize that there's always something there that can never be automated.
Speaker 2: Away, and I think you still have to have critical
thinking skills throughout this process. I do think that development
will take a lot less time now with a I
use the tools properly, it should do that. But I
don't think it goes from you know what would once
take six months and one hundred developers to build. I've
been on projects that big. It's not going to go
from six months hundred developers down to six minutes and
no developers. Just it's not going to do that. And
if you do that at your company, but you know,
I wish you all the luck in the world, that's
not going to be where I'm going to be.
Speaker 1: I think this is where a lot of my faith
in the innovation falls down is that I look at
these companies that are promising me some sort of tool
to do a lot of work or a lot of
the work that I think has to be done, and
I asked them, Okay, let's say I've been using your
tool for five years now and I've built you know,
billion dollar business on it that has an incredibly complex
software stack. What do you expect the process around your
tool usage to be or the architecture of those things.
If it's spec driven development, how many spec files do
you expect me to have. What do those look like?
What is that like when someone needs to change something?
What does that go? And they're like, we didn't really
think about that. We were just thinking about you need to,
you know, make a UI and so you first do
this thing and then you write this command and bam,
you're done. And I'm like, I don't care. That's like
two hours, ten hours, one hundred hours even to get
something done. I'm way more interested in the long term
process here. And if you say, well, that's going to
take like years of agent time to iterate on solving
that question you've asked. When you're at that scale, I'm like, well,
that's not a real solution. You haven't really solved any
hard problem here. You set up a lemonade stand and
you didn't really go further than that.
Speaker 2: And I think some of this is user preference too,
Like when you u seing ghetto Copela at agent mode.
One of the things I like, I like it to
ask me questions along the way. I don't want it
to go away for half an hour and build something
and give it to me. I wanted to, you know,
give it the context and go And if I wasn't
clear in something, I wanted to say, hey, did you
want this UI to have a save button or to
no save button? Making this up? Oh yeah, I didn't
tell you that. So I wanted to have a save
button here because I want an explicit you know, HP
call to go to back end? Okay when using ag GTP,
do you want to use HPS or what other kind
of bag? I wanted to ask me questions along the way. Now,
I don't want it to be a you know that
guy who sits in the cube next to you and
who's asking you forty eight questions a minute, but there's
a there's a lever, and I want to be able
to tune that with my agent. So it's like and
that's also part of the agents MD for me is
ask me questions when you're not sure which way to
go before you go off on a ten minute adventure
of coding. Mister agent or missus agent, you know, come
ask me or show me what you've done, give me
a demo, show me screenshots. This is my preference. I
know there's some people who I've talked to after sessions
on this and workshops where they're like, I'm totally not
like that, John, I disagree. I want the thing to
create the whole thing for me and then I'll look
at it. So there's different ways of going about it.
I think that's part of what we have to figure
out is what is the best way for different companies
to adopt standards, which I'll come back to. My main
point of this whole episode is companies still need to
have critical thinking, They still need to have processes. They
still need to have guidelines, and I call them style
guides because I've written these things. Basically, it's what is
your company expect from your development output? Not just a
functional program, but do they expect you know, these get
up commits? Do they expect small prs, they expect certain assets,
There's certain things that should be there along and long
development cycle. Do they expect a demo a week? We
did that at Disney a lot every week or every
two weeks. It was every two weeks. We'd have an
iteration end and we'd have a demo to the users
to say, here's what we have so far, this is
the feat she you asked for. Great chance to give feedback,
you know, also make some even if everything there is
no feedback. It always made them feel good to go,
all right, they got this. I want that from my agent.
Speaker 1: You just made me think of this perspective that came
out not too long ago that was saying something like
only five percent of i'll say enterprise companies that are
utilizing any sort of ailm et cetera are actually getting
the value out and I don't know how much it
really went into. I mean, it's hard to justify the why, right,
like why isn't that the case? And I can understand
the perspective of those I hate to call them vibe
coders that just say I want the tool to do everything,
because I think this maybe where we disagree with other people.
We know that the tool isn't capable of doing everything yet,
and so we want the questions to be asked so
that we can clarify them, whereas I can see other people,
and I think there's maybe sort of the why that's
been propagated by these companies that are in almost trillion
dollar debt now trying to justify their products creation that
they can do everything, because we know that they get stuck.
We know that there are struggles there that they just
can't have the right answer to. There are too many.
It depends in our experience for it to solve that
and that we can answer those questions for them, but
we have no faith in the agents actually answering them correctly.
Speaker 2: Yeah, I think it's something we all have to be
aware of. Understand where's AI playing a role in our lives?
And to me, AI is I'm going to say something
it probably shouldn't say out out too much, which is
AI is just another tool that we're all going to
learn to use, just like the cloud was amazing, the
Internet was amazing, all these foundational changes and shifts that
were out there. It's just as dramatic as all those changes.
Like think, what how when the internet came that's like AI.
We're going to be using it, but there'll be other
things and our lives still go on. You think, when
the Internet came out, it opened up new our doors
and possibilities and efficiencies. But we still have our businesses,
and we still have our jobs, and we still have
our lives and those things still exist. So AI is
not the most important thing in the world. It is
a part of our worlds which we have to figure
out where does it actually fit in and where doesn't
it fit in? So feel free, everybody out there to
use that statement and ask when somebody says, here's a
new AI feature and go who asked for that?
Speaker 1: I just just feel like we're both going to get
so many angry letters.
Speaker 2: Oh yeah, absolutely, I get them all the time. Yeah,
I work in an AI world and I've got to
do it. But you know, at the same time, you
got to be real, like, AI is amazing, but it's
not everything.
Speaker 1: I still want to continue this conversation, but I also
feel like this may be a good jumping off point
to go over to picks. So before we go there,
I'll ask, is there any last thing, any last point
of conversation, anything that you think that we've missed that
you just feel like, Yeah, you have to tell the viewers.
Speaker 2: Yeah, I think if you're technically wise, if you're looking
for something with AI, go check out get Up Copilot.
I guarantee you there's features that you didn't even know
existed in there. Every time I do my Get Up
Copilot sessions that I do or workshops and people who
are using these things come to them, they find ten
new things that they didn't know existed and can make
their lives better. So these tools are moving so fast.
Give it a shot. Take a look at it and
check out agent mode. Check out the cli. Do is
a copilot cli. Some people will know. Got to check
these things out. They're pretty cool.
Speaker 1: Yeah, even if you don't go there for the copilot.
I've got to say I've been on a huge kick
since the NPM security incident with the malicious packages to
use dev containers everywhere, and in the process of doing that,
I went down the copilot route and as part of that,
I got to say the code completions in line, like
every single time, the first the first completion always exactly
what I want. And so just one at a time.
If you don't even want to engage with a model
and you just want that and you just want to
try that out, like, just go and do that, and
then after that if you're done, that's fine. But it's
definitely a great starting point, honestly. So with that, let's
we're going to move over to picks. So, John, what
did you bring for us today?
Speaker 2: Totally non technical. One of the ways I keep up
with everything is I used to play soccer a lot
years ago, and as of aged, my body just can't
do it anymore. Too many joint issues and things. Keeping
healthy mind and body is really important out there, and
I've gotten into running. I do something called F forty five,
which basically just to workout programs. I do strength resistance,
I do cardio. Find something out there, folks, do some
kind of activity, get away from the desk, go outside,
do something. And my pick for all this is what
got me really motivated to do this was even though
I played soccer for years, I'd never run more than
I'd say, two miles consecutively anywhere, even like at a
slow jog. I got into Run Disney. Run Disney is
a do you run at Disney World exactly what it is.
They run five kse ten case half marathons and marathons,
and you do it with through the parks, with characters
and music and all sorts of stuff going on with
you know, tens of thousands of people and it's amazing.
If you haven't checked out Run Disney, you really should.
It's just an amazing experience, a bunch of people who
are totally non competitive having a good time to run
through and it's helped me change my entire physical and
mental emotional well being over the last several years. And
definitely check it out. That does sound really interesting.
Speaker 1: I've always found my struggle with just running is that
I have this internal monologue that just sort of gets
bored unless I have something else to engage with. Ye,
which has always been a challenge for me. But I
feel like being in a particular environment, definitely one that
you necessarily haven't been to before, it definitely creates a
unique opportunity.
Speaker 2: That's where audio books can be awesome, by the way,
and podcasts.
Speaker 1: Yeah, I mean, if you're not listening to the Adventures
in DeVos podcast while you're going for a run, I
mean you missing out on a unique opportunity there, exactly.
Speaker 2: Yeah. So what did I bring?
Speaker 1: I did the lame thing. I guess I brought a technology.
I've been to thing ear pods, different brands and companies
to try to figure out what I want to use
for the podcast because I used to be using these
Sennheiser I'll just hold them up real quick, and they're
really great for high quality stuff, but I don't like
them interacting with me while I'm on a call or recording.
It's just one more thing that I'm just aware or to.
So I recently finally sat on these shocks open open
fit too I'll just hold up with the little is
and of course it's got my magnetic USB C charger
in it, because I love those things as well.
Speaker 2: This has been.
Speaker 1: Absolutely great there. They don't go in the ear, so
they don't like cause me like physical pain after hours
and hours having them on. I can bring them on
the plane or for eight plus hours when I'm traveling
and they just they just sit there absolutely like just fantastic,
and I can hear everything. Bluetooth of course, tried so
many things and just disliked all of them.
Speaker 2: You know, I use shocks for running. I don't use
the open, open ear ones. I use the ones that
wrap around your head.
Speaker 1: They're bone conducting.
Speaker 2: The bone conducting for the two biggest reasons. One is
I don't like having things my ears all day. Yes
eventually it hurts or yeah, lose a little bit of
And the other part is when you're running, I don't
want to hit by anything. So having the bone conducting,
I can hear everybody around me and hear my music
or podcast and they're amazing.
Speaker 1: Yeah, so these aren't bone conducting, but actually I can
just show them. They don't have a piece in it,
so they're just sitting actually outside my ear for a
similar reason that I can hear everything else that's going on.
But yeah, the shocks bone conducting one. The only reason
I didn't go with them is that it felt a
little weird and I still had to turn the volume
off to make it happen. But yeah, when I exercise
and whatnot, it's definitely the thing that I much prefer
because being able to hear and not get well. Luckily,
I'm actually in Switzerland and so actually really close to Tacchino,
the Italian canton in Switzerland, so not as many cars here,
but if you're in anywhere where there are cars, it's
definitely a huge danger to go around. Yes, with the
plugs in your ears.
Speaker 2: It has saved me several times. My wife has told
me many times she worries about me running, and I'm like,
thank god, I've got these bone conducts headphones. Because some cars,
especially live in Florida, so people sort of do not
know how to drive, and very luckily I've not been it.
Speaker 1: Now, I think that's probably a statement that's true no
matter like which state or country you go to. No
people here they don't necessarily know how to drive. The
car is Fitzalan. They do stop for you actually here.
I don't know if they know how to drive, but
they definitely are way more aware of pedestrians going around and.
Speaker 2: Who's better AI drivers or human drivers like that. We
didn't get into that hall of thing.
Speaker 1: So and I and I shuddered to at the end
of the episode open At this moment, I guess that'll
be a research for the listeners to decide to go
out and do who is better. And maybe with that,
I'll say thank you John so much for coming on today.
It's been an absolute fantastic episode.
Speaker 2: Yeah, thanks for having me. It was really fun talking
to you.
Speaker 1: Yeah, this is absolutely great. And if anyone wants to
see John back on the show, you know, feel free
to email email us and tell us what we missed
or what we got wrong, and we'll try to get
him back on in his busy schedule and one of
winned the next couple of years when we see UH
how AI actually goes and UH involves over time. And
with that, I'll say thank you to our listeners for
joining us for this episode, and we'll see you all
next week.
Speaker 2: M