The Lost Art of Debugging with Mark Heckler
Jim Grisanzio with Mark Heckler
Duke’s Corner Podcast — August 22, 2022
Duke’s Corner Podcast with Java developer and JavaOne 2022 speaker Mark Heckler from St. Louis. Missouri in the United States. Mark is a software developer and developer advocate at Microsoft, a Java Champion, a conference speaker, and an author. Check out his book Spring Boot: Up and Running. In this conversation Mark previews his session at JavaOne — Das Boot: Diving into Debugging Spring Boot Applications. Mark also talks about the value of technical conferences and the community.
https://dukescorner.libsyn.com/the-lost-art-of-debugging-with-mark-heckler
Transcript
(00:00:00):
Hey, it’s Jim.
(00:00:01):
Got another speaker profile here for Java 1 coming up in October in Las Vegas.
(00:00:07):
This is with Mark Heckler.
(00:00:08):
I first met Mark in Atlanta at DevNexus in April of this year.
(00:00:15):
And seems like a really nice guy.
(00:00:16):
I’ve been following him on Twitter for a while.
(00:00:19):
He’s very active there.
(00:00:20):
He’s a software developer and developer advocate at Microsoft for Java.
(00:00:26):
And he’s a speaker, Java champion, FOSS developer, Kotlin developer.
(00:00:30):
He’s an author.
(00:00:30):
He wrote Spring Boot Up and Running.
(00:00:34):
And very active on Twitter at M-K-H-E-C-K.
(00:00:40):
And his session that he’s doing at Java 1 is about the lost art of debugging.
(00:00:47):
And this is really interesting to me because I’m very interested in how engineers solve complex problems.
(00:00:53):
And highly scalable systems are incredibly hard to…
(00:00:58):
debug because they’re so big no one can read every single line of code so you you
(00:01:03):
have to approach it in a in a systemized way right and so i’m just i’m very
(00:01:08):
interested in this and mark’s a good guy and i hope you enjoy the conversation talk
(00:01:15):
to you soon hey mark how you doing listen java one is back you going
(00:01:25):
As a matter of fact, I am.
(00:01:26):
I am actually getting to present there again this year.
(00:01:29):
Excellent.
(00:01:29):
Excellent.
(00:01:30):
That’s why we’re here.
(00:01:30):
We’re here to talk about your session at Java 1, which is back in Las Vegas, October 17th through 20th.
(00:01:37):
So what are you talking about?
(00:01:39):
I’m not sure.
(00:01:39):
I’m kidding.
(00:01:40):
I’m kidding.
(00:01:42):
I’m talking about debugging Spring Boot applications using, of course, Java.
(00:01:47):
Cool.
(00:01:48):
Why is debugging important?
(00:01:51):
I’m actually interested in this because I used to work in Solaris and I used to work on the test team.
(00:01:56):
I’m interested in people who debug and find problems.
(00:02:01):
Well, you know, for years I’ve looked at debugging as kind of the lost art.
(00:02:05):
And I feel like we as developers,
(00:02:08):
we tend to rely on experience versus actual truth and finding that source of truth.
(00:02:13):
So we shortcut a lot of things and sometimes that even works.
(00:02:16):
Sometimes it doesn’t work at all and we wind up wasting a lot of time.
(00:02:19):
And we typically think of a lack of debugging skills as a junior.
(00:02:23):
developer type of problem,
(00:02:24):
but it isn’t because again,
(00:02:26):
as more experienced developers,
(00:02:28):
many times we fall into the same pitfalls,
(00:02:31):
maybe for different reasons.
(00:02:32):
Again, I’ve seen this before, this is how to fix it.
(00:02:34):
But so many times we try to short circuit it,
(00:02:36):
try to shortcut things and wind up making a much longer resolution time than we
(00:02:42):
would necessarily have to.
(00:02:43):
And much more frustrating too.
(00:02:44):
So when you find the source of truth,
(00:02:46):
you can fix the actual problem versus vigorously attacking symptoms.
(00:02:50):
And that’s what this talk is all about.
(00:02:53):
interesting that you mentioned that this is not necessarily a problem for more
(00:02:58):
junior developers why why are senior developers sort of not you know some senior
(00:03:03):
developers anyway why is this an issue for them
(00:03:05):
Well, I think we all could do better.
(00:03:07):
You know, I’m a firm believer in we’re always learning and we should always be learning.
(00:03:12):
But I think,
(00:03:13):
again,
(00:03:13):
for different reasons,
(00:03:14):
I think a lot of times when you’re new to a technology or a tool chain,
(00:03:18):
it’s just a lack of awareness.
(00:03:20):
But once you fall into a pattern and you,
(00:03:23):
you know,
(00:03:23):
I’ve fixed this three times,
(00:03:24):
this type of issue three times,
(00:03:26):
I should say,
(00:03:26):
hopefully not the same thing.
(00:03:28):
But when you’ve been there a time or two,
(00:03:31):
you tend to find things that fit patterns,
(00:03:33):
which generally is a good thing.
(00:03:35):
However,
(00:03:35):
again,
(00:03:36):
you can fall into that trap because if it approximates something that you’ve seen
(00:03:42):
before and there’s a quick fix that maybe you spent a lot of time trying to find,
(00:03:46):
you just typically apply that quick fix.
(00:03:49):
I kind of think of like taking your car to a mechanic.
(00:03:52):
So if you take your car to a mechanic and the mechanic says,
(00:03:54):
Oh,
(00:03:54):
I’ve seen this,
(00:03:55):
just fix this,
(00:03:56):
just replace this.
(00:03:57):
And that’ll be $400.
(00:03:58):
And you say, great, I’ll be back on my way.
(00:04:00):
And if that mechanic doesn’t do adequate troubleshooting, they’re just going based on, you know, a
(00:04:06):
sort of approximation of something they’ve seen before,
(00:04:08):
chances are that’s not going to fix the problem and you’re going to be back
(00:04:11):
tomorrow and then another 400 or $800.
(00:04:13):
And then you do that three or four times and you think,
(00:04:16):
gosh,
(00:04:17):
if that person had just taken the time to accurately diagnose the issue,
(00:04:21):
probably in half a day,
(00:04:22):
I would have had my car back,
(00:04:23):
spent less and been a much happier customer.
(00:04:25):
And that’s kind of what we fall into.
(00:04:27):
Even as more experienced developers, we fall into that trap all too often.
(00:04:32):
interesting interesting okay so so tell me about the actual session in terms of how
(00:04:35):
you do it i mean i mean i’m watching some of your videos you do a lot of live
(00:04:39):
coding is that going to be you know what it’s about yes now i will say that uh in
(00:04:44):
the context of spring boot applications there is a lot of uh a lot of things that
(00:04:49):
happen on your behalf largely i kind of attribute most of them to auto
(00:04:52):
configuration many times if you’re new to spring or even if you’re not you kind of
(00:04:56):
view that as a little bit of dark art you know so um
(00:05:00):
It isn’t.
(00:05:01):
It’s all science and technology.
(00:05:02):
It’s not magical, it’s logical.
(00:05:05):
But many times,
(00:05:06):
it helps to peel back those covers and see,
(00:05:09):
for instance,
(00:05:09):
the application initialization,
(00:05:11):
what happens in the dependency injection container.
(00:05:13):
I step into that, again, through the debugger,
(00:05:17):
And then we actually write some code.
(00:05:18):
And I try to keep it very simple code and straightforward so we can focus
(00:05:22):
specifically on what we’re trying to accomplish versus setting the table around it.
(00:05:26):
But yes,
(00:05:27):
it’s 100% in the debugger and in actual,
(00:05:34):
in the IDE,
(00:05:34):
in the browser where we see what comes back,
(00:05:37):
for instance,
(00:05:37):
from Actuator to get to the crux of the matter and what the problem could be and
(00:05:41):
how to solve it.
(00:05:43):
interesting i mentioned a little bit earlier that i was actually interested in this
(00:05:46):
topic because i used to work in solaris i used to work at sun on the open solaris
(00:05:50):
project and um i was on i worked in the kernel team obviously i’m not a kernel
(00:05:56):
developer but i was on i was in that organization surrounded by kernel developers
(00:06:00):
and i was these are obviously non-trivial people right so they’re highly skilled
(00:06:05):
and i was always very interested in their
(00:06:09):
training in terms of their thinking process of how they wrote code,
(00:06:12):
how they tested code,
(00:06:13):
how they did code reviews,
(00:06:14):
things like that.
(00:06:16):
Just as a, almost as a training for me on how to manage a project, right?
(00:06:22):
Because when you’re dealing with such highly scalable and very,
(00:06:26):
very important systems,
(00:06:27):
just like you do in Java,
(00:06:29):
these things have to work,
(00:06:30):
they have to work well.
(00:06:33):
And I was interested in their thinking process.
(00:06:36):
Particularly designing the system,
(00:06:39):
you say debugging and so fixing problems before it’s out there,
(00:06:42):
essentially.
(00:06:44):
In your experience, talk to me a little bit about the difference between writing code and then debugging.
(00:06:54):
What’s the difference in the thought process?
(00:06:58):
Well,
(00:06:59):
the simple answer,
(00:07:00):
I suppose,
(00:07:00):
is one’s a creative discipline and one’s a very,
(00:07:02):
very much analytical discipline.
(00:07:04):
But there is a lot of overlap and a lot of play.
(00:07:09):
Hopefully,
(00:07:09):
again,
(00:07:10):
and I kind of hone in on this specifically,
(00:07:13):
but obviously,
(00:07:14):
hopefully,
(00:07:14):
we’re doing test-driven development.
(00:07:16):
We’re actually creating the test first to catch a lot of things that might potentially crop up.
(00:07:20):
We’re not just throwing code out there and going, gee, I hope it works.
(00:07:23):
However…
(00:07:24):
You know,
(00:07:25):
so I am ignoring a lot just for the topic because we only get a short time together
(00:07:29):
to discuss this and then,
(00:07:30):
of course,
(00:07:30):
much more time afterward.
(00:07:32):
But I do think it’s in…
(00:07:37):
The two disciplines are not orthogonal.
(00:07:41):
I mean, you have the creative discipline, which is wonderful.
(00:07:44):
You know,
(00:07:45):
I always talk about development,
(00:07:48):
not just that it’s a very mathematically based type of process,
(00:07:52):
it’s an artistic process as well.
(00:07:54):
The two are not mutually exclusive, and in fact, they complement.
(00:07:58):
But I do think that it’s easy to kind of fall more on one side or the other if we
(00:08:03):
don’t maintain that balance.
(00:08:05):
And once you create some code,
(00:08:07):
even if all the tests pass,
(00:08:09):
many times something happens,
(00:08:11):
which I always do come back to so many times.
(00:08:14):
And again, I’m guilty of it too.
(00:08:16):
If you call over your… It used to be when you’d sit next to people.
(00:08:20):
Now, of course, we’re geographically dispersed.
(00:08:22):
Thank goodness.
(00:08:23):
I think that makes us a lot more efficient and effective in many ways.
(00:08:26):
But…
(00:08:26):
But if you call over someone via Teams or Slack or what have you,
(00:08:30):
and you say,
(00:08:31):
just kind of sanity check me,
(00:08:32):
look over what I’m doing.
(00:08:33):
And of course, then you step through things and you start talking through things.
(00:08:37):
A lot of times what happens is that the other person or you,
(00:08:41):
if you’re the person called over,
(00:08:42):
you say,
(00:08:42):
well,
(00:08:43):
what’s it doing?
(00:08:44):
Well, it’s doing this.
(00:08:45):
Well, how do you know it’s doing that?
(00:08:48):
Well, because I’m getting no value back.
(00:08:50):
Okay, so how do you know it’s doing what you say you’re doing?
(00:08:54):
Well, because I’m getting no value back.
(00:08:56):
Yeah,
(00:08:56):
but aren’t there more than one plausible scenarios that would result in you getting
(00:09:00):
no value back here?
(00:09:01):
Well, no, I don’t think so.
(00:09:03):
You don’t think so.
(00:09:04):
And until you isolate exactly what’s happening and why it’s happening, you really don’t know.
(00:09:10):
You just suspect.
(00:09:11):
And again, sometimes we kind of have a strong suspicion and that turns out to be right.
(00:09:16):
And most of the time that’s good,
(00:09:17):
but that can actually hurt us down the road because if we get lucky,
(00:09:20):
I shouldn’t say get lucky,
(00:09:22):
but if we happen upon the solution three or four times in a row,
(00:09:27):
we just assume that that’s always the case.
(00:09:30):
And the world has a funny way of showing you things are not 100% almost inevitably.
(00:09:35):
It’s going to show you that edge case at some point,
(00:09:37):
and you’re going to spend an inordinate amount of time trying to find what the
(00:09:40):
truth really is because it all of a sudden doesn’t match the other four or five
(00:09:44):
times it happened almost identically before that.
(00:09:47):
Something has changed.
(00:09:49):
There’s a variable that’s different.
(00:09:51):
Not literally a variable, but perhaps it is.
(00:09:53):
And that’s what we have to combat.
(00:09:55):
Combat the assumptions,
(00:09:57):
find the verifiable truths,
(00:09:58):
and find the solution to the actual problem underneath.
(00:10:03):
It’s very interesting.
(00:10:04):
You use the word truth multiple times here.
(00:10:07):
Yeah.
(00:10:08):
And it’s very interesting.
(00:10:10):
You don’t know until you actually see the data and actually go through the whole thought process.
(00:10:14):
It’s just basically a scientific method.
(00:10:17):
Yes.
(00:10:18):
And I also talk about the what and the why.
(00:10:21):
Well, first of all, many times we short circuit this and we think we know what is happening.
(00:10:26):
But when we find out what’s happening, it’s something different.
(00:10:28):
The what is different.
(00:10:29):
But even once we determine the what,
(00:10:32):
many times,
(00:10:32):
again,
(00:10:33):
there can be multiple ways of getting that result.
(00:10:36):
I’m getting back a value of four.
(00:10:38):
Why am I getting a four?
(00:10:39):
Well, I’m pretty sure I know that.
(00:10:41):
Well, then we’re into a new set of assumptions.
(00:10:43):
We have to verify why we’re getting four here versus we’re pretty sure we know why
(00:10:47):
we’re getting a value of four back here.
(00:10:50):
So is this something you’ve been interested in for a long time?
(00:10:54):
Yes.
(00:10:54):
You know,
(00:10:55):
that’s something that I had a good mentor years ago who really pounded into me the
(00:11:00):
importance of debugging,
(00:11:02):
good debugging skills.
(00:11:03):
And sadly,
(00:11:04):
like most things that we do when we get involved with something,
(00:11:08):
we get busy with other things and it just never happens.
(00:11:10):
And I thought for years about doing a talk on debugging.
(00:11:14):
And I actually, this is kind of the intro talk.
(00:11:16):
I actually am putting together a much deeper dive,
(00:11:19):
but this is kind of the let’s get started and start the conversation talk because
(00:11:23):
I’m just now getting around to this.
(00:11:25):
You know, it had been on my list for some time and I’m finally kind of throwing it out there.
(00:11:30):
So I’d like to take this much deeper and broader, actually, in terms of ground that we cover.
(00:11:36):
But I think this is a good start to kind of get people thinking along these lines about,
(00:11:39):
you know,
(00:11:39):
let’s…
(00:11:41):
I’ll say slow down.
(00:11:42):
That doesn’t mean take three days to try to troubleshoot an issue that you can
(00:11:45):
maybe get a couple hour fix in.
(00:11:47):
But many times we think, oh, this will be a quick fix.
(00:11:50):
And it almost never is a quick fix.
(00:11:52):
So rather than try to throw something out and miss and then do that three or 10 or
(00:11:57):
50 times,
(00:11:59):
if we just take a beat and we really analyze what’s actually happening and why it’s happening,
(00:12:05):
relatively speaking,
(00:12:06):
the fix is much faster,
(00:12:07):
even though we tend to slow down,
(00:12:09):
take a breath and then fix it right.
(00:12:11):
Interesting.
(00:12:12):
Well, I’m sure it’s going to be a great talk.
(00:12:14):
I’m really interested in it myself,
(00:12:16):
just for project management experience,
(00:12:18):
basically,
(00:12:19):
because I observe developers and the way they work,
(00:12:23):
and I glean anything I can,
(00:12:24):
any kind of lessons I can for what I do.
(00:12:32):
I’m interested just to speak a little bit more broadly here about your experience.
(00:12:37):
Why did you become a developer?
(00:12:41):
Boy, it’s probably one of the worst reasons in the world.
(00:12:45):
Well, I actually have heard worse, so I won’t say that.
(00:12:48):
But I…
(00:12:50):
You know,
(00:12:51):
when you’re first starting out in this field,
(00:12:53):
many times we look at computers as being precise,
(00:12:56):
right?
(00:12:57):
It either works or doesn’t.
(00:12:58):
It’s on or off.
(00:12:59):
I mean, even binary.
(00:13:00):
I mean, you’ve got your one and zero, right?
(00:13:02):
It’s literally two values.
(00:13:04):
So at the very core of it, it either is something or isn’t something.
(00:13:08):
It either, like I said, is on or off.
(00:13:10):
So I felt like, you know, there are so many, I guess, disciplines, career options, whatever, where the…
(00:13:18):
the people make things kind of messy and I always kind of initially when I was much
(00:13:22):
younger and much more I guess naive thought the computers would isolate and
(00:13:27):
eliminate much of that little did I know that dealing with people is is a larger
(00:13:32):
portion of it I often say that anytime we try to find a solution to a problem the
(00:13:36):
tech even though not to minimize the difficulty of the tech and the the complexity
(00:13:41):
But the tech is the simple part, right?
(00:13:42):
It’s getting all of the stakeholders on board,
(00:13:44):
getting everybody to agree that this is a valid user requirement and we have the
(00:13:49):
capability to implement it.
(00:13:50):
Does it make sense?
(00:13:50):
And can we scale it?
(00:13:51):
And so many things.
(00:13:53):
And technically, yes, those are challenges, but the people challenges are much larger.
(00:13:58):
So ironically, one of the reasons, the main reason I got into tech is absolutely a flawed approach.
(00:14:04):
reason at all.
(00:14:06):
But that said, I do enjoy the people part of it.
(00:14:08):
I think that is what makes it certainly more dynamic.
(00:14:11):
And then you still have the debugging underneath.
(00:14:14):
You still have that very precise analysis that you can apply as well.
(00:14:17):
So in my mind now, it’s kind of the best of all worlds.
(00:14:21):
Certainly a different perspective than what I came into it with.
(00:14:27):
Interesting.
(00:14:28):
OK, so if you if you had to do it all over again, would you would you do it?
(00:14:34):
In other words,
(00:14:35):
you became a developer,
(00:14:36):
you know,
(00:14:36):
years ago,
(00:14:37):
but now,
(00:14:38):
you know,
(00:14:38):
we’re now we’re now,
(00:14:39):
you know,
(00:14:40):
it’s a different world now,
(00:14:41):
different technology,
(00:14:42):
different tools.
(00:14:43):
The tools that you guys use are incredible.
(00:14:46):
I mean, I used to be in the construction business, so I know a lot about tools.
(00:14:50):
essentially excavating equipment, hammers, nails.
(00:14:53):
These are all tools and they can get very sophisticated.
(00:14:57):
And one of the things that has really struck me is the sophistication of the tools.
(00:15:01):
A single developer can do an enormous amount of work now versus years ago.
(00:15:09):
So would you do it all over again?
(00:15:11):
Yeah,
(00:15:12):
anytime I think about this,
(00:15:13):
I always think of the Einstein quote,
(00:15:15):
if I had it to do it over again,
(00:15:16):
I would have been a locksmith or something like that.
(00:15:20):
Yes, the short answer is yes, I would.
(00:15:22):
And you touch on something that’s kind of a paradox, right?
(00:15:26):
Because a single developer can do so much more now,
(00:15:29):
and yet we do much more as a team,
(00:15:32):
as a team sport,
(00:15:32):
if you will,
(00:15:33):
than perhaps we ever have in our past.
(00:15:35):
So again, I guess…
(00:15:37):
That could be good or bad, depending on your perspective.
(00:15:39):
But generally speaking, we have better tools than we have ever had.
(00:15:43):
I always feel a little guilty saying this,
(00:15:46):
but it’s like we have a much bigger candy shop or a much bigger toy box or toolbox
(00:15:50):
or whatever analogy you want to use.
(00:15:52):
But we have so many more things at our disposal, much more affordable, reasonable, reachable, shareable.
(00:15:58):
And we have a much greater potential demand.
(00:16:02):
for impacting the world in some positive way.
(00:16:04):
I guess the downside is perhaps a negative way as well,
(00:16:07):
but we have the opportunity to contribute and give and do with far more reach than
(00:16:14):
we ever have in the past.
(00:16:16):
I can’t see that changing other than continuing to increase either.
(00:16:22):
One of the things I always say about this field is that you need to constantly be
(00:16:27):
learning because every day there are so many more things that become available,
(00:16:32):
tools,
(00:16:33):
languages,
(00:16:34):
changes to languages,
(00:16:36):
so many more things that you want or need to learn.
(00:16:39):
And even if we are continually learning, we’re falling behind every day.
(00:16:43):
So that can either be exhilarating.
(00:16:46):
or frustrating, depending on what your perspective is.
(00:16:48):
I choose exhilaration because I love to learn and I think many of us get into this field because we do.
(00:16:54):
It’s like that ever-expanding candy store.
(00:16:57):
You just can’t get bored because there’s so many things out there to try and to apply,
(00:17:02):
which leads to problems like we try to apply every solution possible that comes
(00:17:06):
down the pike to every problem and it doesn’t always fit.
(00:17:09):
But certainly we’re getting better and better,
(00:17:12):
better candies or toys or whatever that we can apply to certain circumstances and
(00:17:17):
find that fit,
(00:17:18):
which,
(00:17:19):
you know,
(00:17:19):
we’re in the best possible position we’ve ever been in.
(00:17:22):
And it’s only getting better.
(00:17:23):
So I would encourage everybody to keep learning, keep growing, keep enjoying the process.
(00:17:28):
Always think of yourself as the village idiot because there’s so much more to learn.
(00:17:32):
And that’s a good thing.
(00:17:34):
We’re just getting hopefully getting smarter as we go.
(00:17:37):
Yeah,
(00:17:37):
it’s interesting because when you go to Java 1 now,
(00:17:40):
really any Java conference,
(00:17:42):
if you’ve been around a long time like you and I have,
(00:17:45):
you see a lot of the older people,
(00:17:46):
but really most of the people there are young.
(00:17:50):
And I was talking to Bruno last night.
(00:17:53):
We were talking about our first experiences at Java 1.
(00:17:56):
For me, it was in 2000 at Sun.
(00:17:57):
He was talking about his experience.
(00:18:02):
But all these new people now coming in,
(00:18:03):
they have their own histories,
(00:18:05):
their own experiences that they are contributing to the larger Java community.
(00:18:12):
So Java 1 is being reborn here.
(00:18:16):
It’s coming back in October.
(00:18:18):
And so do you, how many Java 1s have you been to in the past?
(00:18:22):
You know, I’ve never actually stopped and counted them.
(00:18:25):
More than one?
(00:18:27):
Yeah, more than one.
(00:18:28):
I’m thinking around a dozen or not quite a dozen, maybe.
(00:18:33):
Yeah, I need to go back and do that.
(00:18:35):
Now that you mentioned that, I just never have stopped and thought about that.
(00:18:38):
I didn’t come in early, early Java 1.
(00:18:40):
I came in much later.
(00:18:43):
That’s a whole other story, a whole topic for another podcast.
(00:18:47):
But yeah,
(00:18:49):
some of my best and earliest memories,
(00:18:51):
interestingly enough,
(00:18:52):
are of Bruno,
(00:18:53):
you know,
(00:18:53):
with the VR Java man with the flag.
(00:18:55):
Right, right.
(00:18:56):
So many good things,
(00:18:58):
but I’ve been through several iterations of Java 1 with Moscone and hotels and
(00:19:02):
Moscone and Vegas now.
(00:19:05):
And it’s just, it’s always different, right?
(00:19:09):
So,
(00:19:09):
you know,
(00:19:10):
I know as developers and in technology,
(00:19:12):
we love change,
(00:19:13):
but yeah,
(00:19:13):
we hate change because we’re still humans and…
(00:19:16):
and all of that but but there’s always something new that you can uh find and grab
(00:19:20):
onto sure you you miss xyz because you you have great memories of that but but the
(00:19:25):
new stuff is is cool too so you find that that that new nugget that you haven’t
(00:19:30):
perhaps experienced before because it’s never been there before and it’s it’s
(00:19:34):
always something cool it’s always something new
(00:19:36):
Yeah, it’s really great.
(00:19:37):
I’m looking forward to it.
(00:19:39):
I don’t know about Vegas.
(00:19:41):
I haven’t been to Vegas in probably 25 years.
(00:19:45):
I can’t imagine it’s changed very much, but we’ll see when I get there.
(00:19:49):
Yeah, I went to a conference there a few years ago and
(00:19:54):
Vegas, like every city, it has its pros and cons.
(00:19:57):
But I will say this,
(00:19:58):
Vegas is just,
(00:20:00):
I don’t think there’s a city that’s more ideally suited for having conferences and conventions.
(00:20:05):
I just think it’s just brilliantly laid out for that.
(00:20:10):
There are so many things that you can do outside, I guess.
(00:20:13):
But realistically,
(00:20:15):
I guess from the other side,
(00:20:16):
if you never want to go outside of the conference experience,
(00:20:19):
you really don’t have to.
(00:20:20):
You can immerse yourself completely.
(00:20:22):
So it’s all in what you want.
(00:20:24):
And again,
(00:20:25):
you know,
(00:20:25):
like in San Francisco,
(00:20:27):
I would always find different restaurants,
(00:20:29):
new restaurants,
(00:20:30):
and try them in different things that maybe I wasn’t even aware of for a number of
(00:20:34):
years before or just hadn’t had the chance to swing over and eat there or something.
(00:20:39):
But, you know, with Vegas, there are all kinds of new and different experiences you can try.
(00:20:45):
But if you really…
(00:20:46):
One of the great things,
(00:20:47):
I’m diverting a little here,
(00:20:48):
but one of the great things about Java 1 historically has been that you can just
(00:20:52):
sit down and hack on some things with some friends and work through things.
(00:20:55):
And,
(00:20:55):
you know,
(00:20:56):
if you lose a whole afternoon just immersed in your code and talking to your
(00:21:00):
friends who are working through maybe a thorny issue or maybe just kind of a,
(00:21:04):
hey,
(00:21:05):
I wonder what would happen if I tried this,
(00:21:07):
you can do that.
(00:21:08):
You don’t have to go outside of that environment, and it’s right there.
(00:21:11):
So I’m kind of jazzed about it.
(00:21:13):
I hope it goes well.
(00:21:15):
We’ll see.
(00:21:15):
We’ll give it our best shot.
(00:21:17):
I think it’s going to be pretty awesome, but a lot of it is what we make of it.
(00:21:21):
So let’s do this.
(00:21:22):
Yeah, exactly.
(00:21:23):
It’ll be great.
(00:21:25):
okay well mark um looking forward to your session and we will see you in um
(00:21:32):
goodness gracious just a couple of months now in las vegas i will have links to all
(00:21:36):
your bio and all your social and everything in the show notes and people can
(00:21:41):
register for java one as well it’s coming up soon and we’ll see you there see you