[MUSIC] Hello, welcome to Picture Recoding with Erik Aker and Mike Mull.

Hi, Mike.

How are you doing?

>> Hey there.

Doing pretty well.

>> Mike, I want to tell you about this feature in a magazine I used to read regularly.

The magazine is called Surfer's Journal.

It was published on this really high quality paper, and they would have these gorgeous photographs.

It almost looked like just rich color.

They were bound like a thick bound, like a hard bound book.

They weren't hard bound, but it was thick.

You could almost eat these photographs.

Then they have this literary style for the articles that they would write.

I used to read this magazine called Surfer's Journal.

In the Surfer's Journal, they would have this regular feature every so often.

The feature was called "Best I Ever Saw."

I always liked this.

What they would do is they would talk to someone in the surfing world, a pro surfer, photographers, or other people, and they would ask them, "What's the best surfing you've ever seen?"

Some of these, they stuck in my head that I remembered them afterwards.

The one I think that's most memorable for me is this one about a surfer named Andy Irons.

He died young.

He was born in 1978, and he died in maybe 2010.

He had some mental health issues and drug problems and stuff, but he was this amazing surfer.

There's an author of this tribute who says, they ask him, "Who's the best you ever saw?"

He says, "Andy Irons."

The author is a photographer.

His name is Pat Stacey.

He describes this incredible photo that he took.

A lot of action sports photos, they tell the story.

You see somebody in movement, in the air or something, and you can imagine the movements that led up to that, like the momenta, the inertia that got them to that moment where the photograph freezes at in time.

But sometimes you'll see a photo that is...

It's like it's hard to reassemble the story, the moments that led up to that.

And this photo is like that.

This surfer, Andy Irons, is in this amazing pose.

And you can see the trail that his surfboard took on the wave to get to the pose, but it's hard to reconstruct it because the line is so...

It doesn't seem to line up easily with reality in my imagination.

So it's a weird photo.

It looks frozen in time in an unreal way, and it's difficult for me to reassemble the action in my mind.

But the photographer says, "I never saw him do a turn like this again."

There's another one about a famous surfer from Hawaii named Tom Carroll, and he was really good at surfing this huge wave in Hawaii Pipeline.

And the author of that one says, "He was so good at surfing this wave that other people would get out of the water to watch him."

That caliber of surfing is rare.

I sent you the Andy Irons one.

Did you see that photo?

I did.

I couldn't really make sense of it either.

It looks almost like he was going backwards or something.

I think that's why it's such a brilliant photo.

It snaps this moment in time, and then it's really hard to reassemble the moments just prior to it in your head.

So here's the thing.

I didn't want to just talk about surfing today.

Every time I ever read this feature in the Surfer's Journal, it's called "The Best I Ever Saw," I always had this kind of fantasy in my head as I was reading it.

And the fantasy is, "What if somebody came to me and asked me what's the best you've ever seen in your field?

What would I write?

Who would I write about?

What would be the moment that I wrote about?"

I mean, I guess I could say, I could wonder too, like, what if somebody wrote about me in this way?

What would they say?

But in my head, in the fantasy, it's always like, somebody comes to me, they want me to write, "What's the best you've ever seen?"

And I have to come up with a moment in time and a description.

It's really interesting to ask people, "What's the best you've ever seen in your field?"

So that's what I wanted to ask you today.

I want you to tell me the best you ever saw at work as a software developer.

Well, I'm somewhat relieved we're not talking about surfing.

Since, as I've said before, everything I know about surfing, I've learned from either you or the movie "Point Break."

So, you know, if either you or Keanu Reeves can't do it, then I can't talk about surfing.

So...

Probably everybody who would bother to listen to us is also relieved that we're not talking about surfing.

No, we're talking about the best you've ever seen.

That's what I want to know.

Do you have anything that comes to mind?

Yeah, a few things.

Give me one of them, and then I'll hit you with one.

So, well, I kind of wanted to have a little prologue here.

If that's okay.

So, one thing I wanted to say was, I think maybe you and I treat the topic a little bit differently.

Okay.

Okay.

And, you know, maybe that will just come out in our descriptions of things.

But I think, you know, in my mind, I'm kind of imagining this experiment where you take various developers or programs and you put them alone in a room and say, "Solve this problem."

And the best people are the people who solve that problem the best.

It's like a competitive exercise.

Yeah, I suppose.

I mean, I guess, you know, the key difference, I think, is that I'm focusing less on my relationship to these people and more on what they could actually do.

So.

Oh, yeah.

For me, it's not a relationship too.

It's like, you don't have to know the person.

You just have to be there at the moment in time.

You snap that photo in your mind's eye and you go, "This is the best I ever saw."

What are the qualities of that best I ever saw?

That's what's interesting to me.

Yeah, I think they are hard to list, you know, and to a certain extent, I think their qualities that, you know, are things that you would expect.

One thing that's kind of interesting to me is that to be good at the profession, people need to be pretty smart, but being pretty smart is not sufficient for some reason.

So I've known extremely smart people who just didn't code well.

But I'll give you one example.

I'll give you my first example, and I think this maybe displays a characteristic that I see in the people that are really good in the profession.

So there was a point where I was working at this company and there was a hackathon and a number of people from our company decided to go to this hackathon.

It was a Python thing.

I don't remember who sponsored it, but it was, I think it was one of these cases where a company was like sponsoring it and they were saying, okay, you know, build a web app, but use our technology.

Anyway, one of the people from the company that I was working with, you know, who everybody sort of recognized as being one of the key developers in the company, he pretty easily won the hackathon.

And a large part of the reason, I think what he did was not especially surprising or creative, it was just that he knew all the steps to do it in his head and he was prepared to do it with, you know, the tools that he had at hand.

And so he made a surprising amount of progress in the amount of time that was available to people on the hackathon.

What would you think, you said he won.

Do you remember what they judged results on?

No, I think it was just, there were like a panel of judges and they looked at the, you know, people did demos of the final result when they, you know, when the time had expired and after the judges seen all the demos, they picked the winner.

Oh, so like dismount form, things like that.

Yeah, exactly.

You know, did they keep their legs together while they were doing that flip in the air and stuff like that?

How big was the splash?

Right, exactly.

So, you know, this person just did something extremely complete and pretty full featured for the amount of time that was available.

And so I don't know exactly what property to describe this is, but there was a sense in which he was just the most prepared and the most handy with the tools that he had in hand.

You know, I don't know if it was something that he specifically, you know, was practicing to get prepared at or if he just had a better memory of these things than other people.

But I do think it's something that's kind of consistent across people who tend to be very productive and do solid work, is that they come to these problems with a lot of background and a lot of preparation and can make more progress than most people can in a shorter period of time.

That's interesting.

That's like a 10X engineer.

They make 10 times of progress because they're so well prepared.

Yeah, I really don't like that concept.

And I guess we can discuss that if you want to, but I don't really...

I don't like it.

So, I don't believe in the 10X engineer because I don't think there's like one skill set that you can master.

So, I think there are people who are really good at cranking out code.

I think there are people who are good at architecture.

I've seen people who I would consider to be very advanced and very valuable to the organizations who actually did a lot of stuff where they took code away.

They eliminated chunks of code that were not necessary or they improved things by using a better data structure or a better approach.

And so, I'm very reluctant to...

For one thing, I don't think you can say...

I think it's difficult to measure productivity.

And so, if you're just using that as like a line of code count or something like that, I think it's probably a bullshit idea.

10X deleter, maybe.

Yeah.

In any case, I do think that, all that said, there is a sense in which people who are really good do tend to make progress on an equivalent problem faster than other people do.

Although, maybe I do also think there's probably a sense in certain projects where it's not immediately obvious.

How to make progress, you mean?

Well, those are the go for a walk or take a shower type of problems.

Is that what you're talking about?

Yeah, exactly.

I was trying to think of a surfing anecdote.

I could slip in there to make a comparison.

Sometimes it's not obvious which wave to take, Mike.

You sit in the water waiting for a wave, and the first one that comes may not be the one you wanted.

Yeah, exactly.

Knowing pretty much nothing about surfing.

Sometimes the best rides are because you waited for the best wave.

Yeah.

Let me give you one.

So I started at this company, and I ended up being there for a long time, many years.

In the first two weeks, they gave me this monitor, and the monitor, it didn't work.

And so I was like, I just took it back to the IT department.

Hey, this monitor doesn't work.

Oh, okay.

And they gave me a new monitor.

That one worked fine.

And eventually, I recruited and hired someone.

I had worked with that at a previous company, and this person did a lot of cloud infrastructure stuff.

And the first day he was there, I went over to his desk to walk him through some processes and tell him about what things were going on.

And this is someone who did a lot of infrastructure as coach.

You can imagine Ansible, Salt Stack, Terraform, stuff like that.

And he had that same monitor that they had given me.

Six months before.

And it wasn't working.

And I went, oh yeah, that monitor is broken.

And he went, yeah, it seems like it's not working.

And he just, he, I was trying to talk to him, and then I walked away.

So like an hour later, I went back to his desk.

He had three monitors at four HDMI cables, and he was like swapping out all these cables with all these different monitors and keeping track of which ones worked.

And he finally figured out that the monitor was fine.

But they kept giving that monitor to people with the same HDMI cable.

And he had two bad HDMI cables out of four and three good working monitors.

I just was kind of stunned that he had spent an hour figuring out that the monitor was fine, that we had bad HDMI cables.

He just kept trying different variations of cables and monitors until he figured out what was good and what was it.

And I had just been like, this doesn't work.

Can I have another one?

And this is a characteristic of this person as I've worked with him over the years.

You could give him a problem.

And he just sort of pushes and pushes and pushes and pushes beyond what you would think where people would often give up on stuff.

He just keeps pushing.

And I kind of respected that.

I would call this tenacity.

And you know what's funny is we actually reached out to some of our friends and some of the people we work with.

And I ended up getting responses from, I think, maybe five people.

And I asked them, hey, what are the attributes you think of the best developers you've worked with?

And our friend Bob, he said tenacity was one of them.

He said, I said, Bob, one of the best characteristics of the best software developers you've worked with.

And he said tenacity.

They stick with it until they understand what's needed and they get it working.

What do you think?

Tenacity?

I definitely agree on that one.

There's a sense, I think, in which you and I have a slight variance in opinion on this particular thing.

You're almost trying to differentiate the way we come to these things.

You are different.

That's what you want to tell me.

Well, I think I'm probably normal and you're different.

Oh, OK.

In biology, they talk about lumpers and splitters.

This is not a tech term.

It's like you're lumping species together or you're trying to split them apart.

Say no, no, those are different species.

I just always assume that I'm the normal one and other people are weird.

So anyway, so this goes to a slightly different thing.

But my feeling has always been, so I'm largely self-taught.

And in the process of being self-taught, did not have a lot of people helping me.

So I started out in places where the senior engineers were not the kind of people who were going to sit down with you and work through things with you.

And so I had to develop a certain amount of tenacity because I had to figure out problems for myself.

And you're saying it's like a core table stakes requirement.

Well, maybe.

I think what I'm saying is that having tenacity is a good quality of good engineers.

But I also think that it is something that you can and should try to develop.

So I guess what I was saying about you and I disagreeing on this is that I think you're the kind of person who, if you see somebody drowning, you're going to throw them a life preserver.

And I'm the kind of person who, if I see somebody drowning, I'm probably going to let them drown.

You're going to high five them?

Like that.

Good job learning.

Keep learning.

Yeah, I just, I have this maybe misguided notion that letting people sink or swim is probably good for them.

So.

There was something hidden kind of in what you said too.

Like you have to cultivate this skill.

You can cultivate this skill.

If I ask you, what's the best you ever saw?

I want to hear more of your stories, but are the attributes that expressed in those the best I ever saw stories, are they like innate?

Is this like you're just born a creative genius, or are the things that can be cultivated?

Well, tell me another one and we'll try to judge what's going on in there.

Because the first one could be cultivated.

Being prepared was the first one, I think.

Yeah, I guess there's a part of me that wants to think that all of them can be cultivated, but realistically, I suspect there probably is some basic type of intelligence you have to have.

There's one instance where I worked with a person.

This goes back a ways and the example will demonstrate that, but at the time I was working on Windows desktop software, and it was mostly in C and C++ at the time.

Probably in the late 90s, Windows had kind of, they'd come to this standard called the Microsoft Foundation classes for their user interface toolkit.

And sometime after that in the 2000s, they kind of built this comm framework around it.

So at this time, and maybe like 2002 or so, people were using this Microsoft standard to do Windows desktop programming.

I was working with this guy at the time who, he was kind of our team architect and had really deep understanding of the fundamentals of this stuff.

And one day he came to me and he said, "I've been working on this thing and I want to show it to you."

So he starts demoing this thing for me.

And basically he had built his own user interface framework on top of Windows.

And my first reaction was, "Wow, that's really impressive.

You kind of have duplicated something that it took a team of engineers at Microsoft to do.

That's pretty cool."

But the more we looked at it, the more we got into what he had actually done, it turned out that in a lot of ways, what he had built was actually better than what we had available for Microsoft.

Why is that?

Well, one thing that was pretty interesting about it was it had this concept, he had added this concept of plugins.

So you could write certain pieces of an application and put them into a component, which would have been like a com component in those days.

And you could add them to your application just by basically adding some configuration text.

And it was something you couldn't really do easily with the existing Microsoft framework.

And so in certain ways, it was actually exceeding what Microsoft was offering.

And we actually did end up adopting it for some of our commercial products at that company.

You know, it still kind of stuns me to this day that he was able to do that as sort of a side project.

And the completeness and maturity of it was kind of astonishing.

So I'm not quite sure what properties or what qualities you could boil that down to.

You know, clearly there's some exceptional intelligence there.

But I think what I saw there, which is kind of common across really good developers, is that he had kind of internalized the concepts in this thing that he was trying to duplicate.

And so he wasn't just trying to write a clone.

You know, he had figured out sort of the patterns and the optimizations that they had made in building this thing.

And he had done those things, but in a slightly different way of his own devising.

And it just, it was very impressive.

And still in my nearly 40 years of doing this, one of the more amazing bits of work I've seen.

I liked something in what you said and disliked something in what you said.

I dislike the emphasis on intelligence or special intelligence.

I think intelligence is this not measurable property.

We like to talk about it.

Sure, it exists, but it's fuzzy and it changes.

And you can get better at things and worse at other things.

I really just don't like focusing on intelligence.

I know there's the fixed mindset and that kind of adaptive mindset.

I like to talk about pattern recognition, because I think that's a thing that, maybe pattern recognition is too big of a phrase, but you had said he had seen the patterns.

And I actually think that that's something that comes out a lot in our field.

And people who are really good, they identify patterns early.

They figure out how things are related to other things.

They adapt things that may not even seem that similar, but somehow have a similar pattern.

I think there was someone I worked with around 2014.

And this was around the time I started trying to experiment with Docker.

It had been out a couple of years at that point.

And I went to this person at work and I said, "Hey, I've been experimenting with Docker.

Have you used it?"

And the reason I asked this person is he was always working on new, weird things and just trying things out.

He wasn't necessarily shipping them or adopting them or whatever, but he was trying stuff out.

And I thought, you know, this person might have comments on how to help me ground.

Like, am I going to use this tool?

If I use it, where does it fit in?

Do I want to...

It's really easy as an engineer to be like, "Well, I already have ways to solve those problems.

I'll just throw away this new tool or not even address it or whatever."

And it's nice to have other people to bounce ideas off of like, "You used it.

What do you think?

Where does it fit in?

Does it fit in?"

It felt really new to me at the time.

I was trying to understand how it worked.

He said, "Oh, yeah.

I've been building packages with that for production."

And I was like, "What?"

It was so new to me.

It didn't occur to me that people were already building production in my sphere.

You know, they were already building stuff for production.

It turned out he had quickly grasped the utility of it.

And he figured out he could clone his repos into this clean.

He could make a Docker image which would clone his repos and spit out these packages, which then he could deploy onto virtual machines in the cloud.

And so like, he would split up a virtual machine, load this image, Docker image, run the container to produce a whole number of packages, and then tear down the virtual machine.

And I was kind of impressed with this.

It was like really easy for this technology.

There was no one out there who said, "Hey, this would be a good use for this."

He just sort of like tried it out and immediately went, "Wow, this could make this clunky stuff I'm doing to provision all of these, like be able to build all these packages."

It would make it a lot easier.

And there's sometimes we talk about like innovator type, but I think underneath that innovator type is similar to this pattern recognition.

You see, it's like what did Feynman say.

I'm carrying around all these problems.

And every time I hear about a new solution, I apply it to the problems I have in my head.

I think that there's, is that a bad Feynman quote?

Did he say that?

Something like that.

That's not one that I know, but it sounds like him.

Well, so I think that there's patterns underneath that, recognizing patterns is really key to creatively connecting things that don't seem like they should otherwise be connected.

And if you want somebody to write about you in a best I ever saw software development feature, I would bet you'd have to be pretty good at pattern recognition.

Yeah, I think that that's something you can probably identify across everybody who's good in the profession.

I guess one, maybe point of disagreement with you is I would argue that that probably is an aspect of intelligence and maybe something that people innately have in greater or lesser degrees.

So that's an innate one.

You can't just learn pattern, pattern recognition.

I have no idea.

Can't practice it.

Can't cultivate it.

I have no idea, to be honest.

When I took English classes in college, we would read books or poems or whatever.

And we would practice ultimately this, like looking at patterns.

You could be in a class and you could read a poem and you could have a professor say, well, you should look at the verbs in this poem.

Because there's not a lot of them and they're key to what's going on.

And then you remember in the future, oh, if I focus on the verbs, I can sometimes see beyond this aesthetics of the words.

So you can learn pattern recognition, I think.

You could teach it.

Yeah, I feel like there's probably some aspect of just the way your brain works.

This is not a software example, but I had this college roommate who went into mechanical engineering and he had this amazing ability to visualize things in his head.

I could tell when he was describing something, he was like, he had this model in his head and he could kind of rotate it around.

And I just do not have that faculty.

I remember when I got to quantum mechanics and as an undergrad, I found that I was probably better at it than average.

And I think one reason was because I didn't have to make any attempt to visualize what was happening.

Well, you're better at it than I am.

I will tell you that much, what it's worth.

Do you have other examples?

Best you ever saw, Mike.

Best you ever saw.

So you're a part of my career.

I worked in, I guess, what would now be called high performance computing.

And I worked with a lot of people who were doing computational chemistry stuff and protein crystallography and various things like that.

And one of the people that I had, he didn't actually work at the same organization I did, but he was just down the street and I would interact with him occasionally.

And down the street?

Yeah, this was on a campus.

Yeah, up what in, what in in San Diego terms would be called the Torrey Pines Mesa.

Oh, okay.

All right, so down the street.

All right.

That could be because it's down the hall or something.

Same company, down the street, got it.

So like you've got University of California, San Diego, you've got, you've got Scripps Clinic and you've got Scripps Oceanography and you've got Salk and, you know, all these places that are kind of on the beach or on the Mesa.

You want to go to lunch together and stuff.

Sometimes.

But yeah, there was a lot of, you know, collaboration and particularly on the stuff that I was working at, there was, you know, various places like Scripps Clinic has had its own supercomputer and I worked at a supercomputer center.

So anyway, so there was this guy down the road and he was, he was well known in the protein crystallography world and he had written this program that was used to visualize protein structures and everybody used it.

You know, he, he didn't really, this was kind of before the days of things like GitHub and common open source stuff.

So the fact that everybody in the industry used it was kind of telling because, you know, the only place, the only place you would have found this program was by interacting with this guy or meeting him at a conference and seeing the work that he had done or something like that.

And so, you know, I had a chance to look at his code and work on it a little bit.

And at first I was just like, I don't get this, this does not, you know, at the time I was really into capital S software engineering and, and thought that things had to be organized in a particular way and things had to, you know, variable names had to have a certain format and I was looking at his code and it was like, this is nothing like, you know, what people are telling me to do in the software engineering books.

But nonetheless, you know, everybody used it, it worked well.

And I, I remember reading through the code one day and just sort of having what I can only describe as an epiphany.

And I just realized that I understood what was going on, but also that he had chosen the right abstractions.

And I can't really describe what it did without getting into really technical stuff, but he, he sort of had picked the right level of abstraction for everything to make it easy to work with and adapt to other situations.

And, and once I saw it, it was like, oh, yes, I get it now.

And it's one of the rare occasions I've had that in my career where I see a, see a piece of code and don't understand it at first and then, and then develop an understanding of it.

You know, you always go through these archeological progress processes where you, you know, trying to figure out code and usually, you know, sometimes you're impressed and sometimes you're not, but this was the first time where just kind of like this coin dropped in all the pieces fit in place for me.

So this is one of the things that I have kind of come to think is essential having either the skill or the taste or something to pick the right level of abstraction because I have worked with people who have done, who have gone in the wrong direction in both ways.

You know, I remember people in the early days of object-oriented software who just really, really, really wanted to make things as abstract as possible.

Yeah, as adaptable in general as possible.

Yeah.

And you'd end up with these, you know, deep levels of object hierarchy with several levels of abstract based classes and just, you know, you couldn't, you couldn't, couldn't work your way back through it.

And I, I've seen.

It couldn't make sense of it.

Yeah, I've seen that too.

Yeah.

And of course, everybody's seen like a, you know, big ball of mud sort of thing where it's just a total lack of abstraction.

But this guy just really nailed everything.

And I just understood sort of in a sudden rush why, why it worked as well as it did and why people were so eager to adopt it for their own work.

Again, I don't know if this is a skill you can cultivate.

I think it's maybe you can sort of guard against going one way or the other.

But there may be just a certain extent to which people have to internalize the subject really deeply to understand what the good abstractions are.

Picking the right abstractions.

That's a really interesting snippet of the best I ever saw.

That's a good one.

So years ago, I had a boss and this person used to always surprise me with their depth of knowledge on various topics.

So one day I asked him about this database I was reading about at that job.

We had a huge elastic search clusters.

They had 50, 60 nodes in them sometimes and they were all these like massive AWS instances and huge amounts of company data.

And I had read about a newer data store.

It seemed like it could handle stuff in a comfortable way.

Maybe it'd be cheaper for us to run.

And he said, oh yeah, that's another LSM tree, just like elastic search and others.

And I was like, oh, he'd not only heard about it, he'd quickly researched how it was built, realized how it fit in the market, types of problems it was good for.

And it wasn't just that.

It was like, this is the only person I've ever worked with.

Aside from you, Mike, who would read academic papers in order to piece together foundational knowledge for the work we were doing.

This is a super busy person at work, just always meetings, working at teams and two continents, loads of responsibilities.

And this person found time to read academic papers.

And I was like, geez, this is a really high bar.

I don't think I'm going to make it to that bar.

So it was like a depth of knowledge thing.

Like, yeah, I see where you're coming from.

And I'm going to try to go deeper.

And in this case, maybe there's academics.

LSM tree, obviously not hugely academic topic.

It's a pretty common topic nowadays.

But just in general, it was indicative of this person's approach to evaluating things.

And it changed how I thought about evaluating similar things.

I realized that's the way that you should be evaluating stuff.

Shouldn't be evaluating based on, obviously, hype or the community or these other factors are relevant, but they're fundamentally, you have to really understand the design of these things.

And the best way to do that is to go and have real foundational academic understanding, understanding of the academic literature.

Yeah, that's a good one.

I've seen that a number of times over the years as well, where I remember a guy that I worked with at the very beginning of my career.

He was actually still a graduate student and he was working on this program that was basically a ray tracer.

But he was the one person, he was a computer science graduate student and he had just done these things that would have never occurred to me in terms of the data structures he was using and the algorithms that he was using.

And I think it really had a big effect on me at the time in terms of being tenacious and being innately smart is sometimes going to be trumped just by people who have a better knowledge of how these things have been done over the years and what the right way to do them is.

I couldn't tell you why I get so comfortable with the innately smart thing.

I just don't trust it.

I don't trust that.

I don't trust it's evaluatable.

I think we are always kind of prejudiced or biased when we try to say, oh, that's a smart person.

I don't think we are very good at judging that at all.

Yeah, I mean, I will concede that point.

You know, I tend to think stuff like IQ tests are mostly bullshit and there's also a certain extent to which, you know, after 40 years, I can tell you that having a 200 IQ is going to be less valuable to you in the long run than being tenacious.

People who actually get like one of my sort of, this doesn't have anything to do with the topic necessarily, but one of the things that I've realized over the years is that working code almost always trumps a good idea.

Oh, I've seen that too.

Just yeah, whoever builds it first is the position we're going to end up with is what I always say for that.

Yeah.

If you build it and ship it, that's probably what's going to be used.

Okay.

Exactly.

Do you have any more best you've ever seen anecdotes for me?

This is similar to the one that you just described.

This was a person I worked with and I know you've said a couple of times now that you don't like the innately smart thing, but this guy was innately smart.

He was always doing things that just sort of annoyed me because they would occur to him so much more rapidly than they would occur to me.

This anecdote is a demonstration of that where we were working with this client and there was this one particular problem that we were trying to solve.

I was working on it and I was struggling with it.

Then one day I realized that really you could recast the problem as solving a system of linear equations.

I was super proud of myself because I was thinking, this is like real math.

This is a good solution to this thing.

I'm pretty clever.

But there was one problem with it, which was that there were cases where to do this solution, you have to invert a matrix in their cases where the matrix would become singular.

So the solution wouldn't work.

Does that mean when the matrix becomes singular that the robots take over and destroy all the humans?

Yes, exactly.

It has to do with the singularity.

Got it.

That's where that comes from.

Anyway, I was talking to him about this and he said, "Oh, well, that's no big deal.

We'll just use single value decomposition and we can get around that problem."

Do you want to take a 10-minute detour and try to give me an understanding of what that means?

No.

There's this linear algebra concept there, like an algorithm called singular value decomposition, which is specifically designed to decompose a matrix that can become singular.

And it helps you get around certain problems with solving least squares, finding least squares solutions and things and so forth.

And it was just, to me, the lesson there was, well, one of these guys was, I think, pretty smart.

But also, he had this background of stuff where when a problem was described to him, it's kind of like you were saying about Feynman, you've got this set of problems in your head.

And when you hear a solution, a new way to think about it, you start to apply it to that problem.

He just seemed to be able to...

He did this a number of times over the years that we worked together.

It just was like he had this encyclopedic knowledge of stuff that whenever you were stuck on something, you could kind of go to him and he would find a way around it for you.

That's a nice co-worker to have, a nice peer to have, unless they're jerks.

Yeah, he was not exactly what you would call neurotypical, but he was not an asshole by any means.

Oh, that's great.

That sounds like a good person to have.

I have one more, and I don't know how you're going to like this one, but mine, if somebody came to me and they wanted me to write, "What's the best you ever saw?"

I would write mine about you.

You might hate this.

Sorry in advance.

So, as we were working on that revenue forecasting product many years ago, we were trying to predict revenue for the Russell 1000, the top 1000 companies by Market Cap and the stock market.

And there were all of these models that had come from our friends in the economics part of the company.

That was pretty heavy stuff.

They had written heaps of code, and you had translated it in Python, and there's just a lot of moving parts in different stages to this model, had stages.

And I remember being kind of a bit adrift at C when I was first looking at the code base, but you were like, "We need to make this go faster.

It's too slow."

At the time, I think we calculated it would take seven days to produce these predictions for all the companies they wanted to produce it for.

So, that's not right.

You remember that, right?

It was like seven days.

I think that's right, yeah.

You said to me, "We need to make this faster."

One way you could start doing that, and you had asked me to help you, was to look at vectorizing these particular functions or like arithmetic functions or something like that.

We could jit compile them or do other things.

And I think you might have said you should look at using Numba.

This is all in Python.

So, Numba is a jit compilation tool.

You can use it for arithmetic functions.

You can call it over and over again.

So, I took a look at it, and I'm pulling functionality out that it's mostly just refactoring.

You have these Numba-decorated functions, which are really basic.

They're adding, subtracting, multiplying, and dividing numbers.

And it's really like most of the reworking is like how I call into that, because I'm pulling this stuff out of some other places and calling into them and pulling them back out.

And after we started doing this, I was shocked.

I ran the profiler and I was shocked.

We figured out we could go from running this thing from seven days to 24 hours.

And that was a big deal because we were running it on only as large AWS VMs, like six, seven, eight of the things.

And there was all these stages things would go through.

And we were going to save a huge amount of money by going from seven days to 24 hours.

And I remember running that thing and being like that whole machine and being like, wow, when I run H-Top, I could see that there's eight CPUs on these AWS VMs and every single CPU, 100% for the entire 24 hours.

That's a pretty cool program.

But here's what's impressed me about this and why it was the best I ever saw a moment.

Obviously, you were intimately familiar with this program.

You had worked on it, but you just sliced through the noise very quickly.

Just go straight here and start there.

And then we'll see how good that does.

And then we'll move on.

And yeah, we could do more profiling.

And I did more profiling and started finding other things.

But I liked your ability, I call the security, like slice through the noise, zero in on what matters.

And I think you had done that in other areas too, where you would be in meetings and there's a lot of extraneous information that comes up, whether it's evaluating technologies or trying to come up with solutions, or people just saying business stuff, like things that may not even be relevant.

And you always had this ability to like, okay, I've received all this information, and I'm going to throw away all the in-utile stuff, like stuff that doesn't help me achieve the purpose.

It's like acuity, just slicing through the noise and seeing the stuff that matters.

I always liked that.

Did I make you uncomfortable?

Did I ruin it?

A little bit.

But thank you.

That's nice of you.

I feel like I'm obligated to tell one about you now.

No, you're not obligated to tell one about me.

No, no.

Yeah, I've always, so I guess my counter to that is that, so I once had a colleague describe me as being pathologically introverted.

That sounds like a thing that should be cured, Mike.

You should go to a reeducation camp for that.

Yeah, which again, makes it kind of weird that I have a podcast.

So when I was younger, I think it was a bit of a disadvantage.

I would always get these like annual reviews that said, Mike's doing solid work, but he needs to communicate more.

No.

We got to get him to open up more about his personal life, that type of thing.

Yeah, I guess the idea was I needed to, I was learning stuff and needed to share it with the group and needed to talk more and so forth.

So what I'm getting to is I think when I was younger, this was looked at almost exclusively as a negative, as a mark against me.

And as I got older, the fact that I didn't talk seemed to become more and more more valuable until there was some point probably in my 40s where people started to say, you know, whenever Mike says something, it's probably going to be really important.

And so I have this sort of belief, I guess in the back of my head that people sort of overvalue the things that I say because they, you know, like at some point in my late 30s, early 40s, people started calling me Yoda.

Most people I've worked with do not think about what they're going to say.

This is an introvert trait.

Think about what you're going to say before you say it.

Most people do not take that out to the degree that you do.

And I am on the opposite end of the spectrum.

One time you told me that the Cray, the supercomputer that you had worked with, that it had been wired so that the CPU and with the cache, like the wire distance was as short as possible.

And I blurted out, oh, that's like my brain in my mouth.

Yeah, although to be fair, I think that I don't think as I think that works out well.

I mean, you, you obviously are one of the better communicators I've worked with and it works out well within the groups that you've worked with.

But I think the thing that bugs me and you do not do this is that I've worked with people over the years who will say the first thing that comes into their mind.

But a lot of times that thing will be something they don't know to be correct.

And they are very confident about it, even though they don't know it to be correct.

And, you know, I even worked with one guy who was to be fair, a very sweet guy who, you know, considered this to be a virtue.

You know, he was, he very explicitly said, you know, sometimes I just make stuff up and try to sound as confident as possible.

Oh, not a virtue.

Not a virtue.

You know, he thought of it as being sort of a leadership skill.

And so.

Well, back, back into the breach, dear friends.

So we asked five people, I mean, I, we asked a, well, I asked a few people, our friend Bob said, tenacity is an attribute of the best developers I worked with moments of brilliance.

He said, focusing on simplification.

He said, great at listening and understanding.

And he said another thing which I thought was interesting, kind, fun, easy to communicate with another person.

We asked, he said, the best software devs I've worked with were relentless in getting the task done, but with the highest quality.

It's like they found it offensive to have bad code.

And a couple of other people, one of them said, I think the thing that stands out for me always, especially in senior developers, is approachability.

I thought, whoa, approachability.

He said, in the past, I've found the best as very approachable.

They don't put walls around them.

They want to talk and solve problems and hence want to be open.

Tech is a thing that a lot of people can learn to master, but building a community is difficult.

He said, to me, the best devs are just, they're better humans.

Wow, that's an interesting statement.

Someone else said, it's someone who enjoys explaining things to new people.

They maintain curiosity as well.

And then finally, someone else, strong communicator and maybe technical prowess correlated with artistic talent and a near obsession with programming computers, other tech.

There's some themes in there.

The one that surprised me, that came up again and again, was this approachable kindness, empathetic, good communicator, maybe it's different from the empathetic.

Someone actually said, I think the best devs tend to be cheerful and happy.

It's like, huh?

Nobody else said that.

Yeah.

Here's what I want to do someday, Mike.

I would like to interview people we've worked with, people who we identify as, oh, this is someone who's pretty good.

I want to ask them, what's the best you ever saw?

I like these stories a lot.

I like the idea that there are maybe some patterns in, I don't know, it's very satisfying to me to read in the surface journal, what's the best you ever saw?

And to see through someone else's eyes, what they rated, what they respected, what inspired them.

Those, for some reason, I find those stories really compelling.

I think the examples that you gave illustrate what I was trying to say, sort of at the beginning, which is, I think a lot of people, when you ask them this question, they think about things that they think about people that did a good job, but also people that they liked working with.

Clearly, the ability to communicate and the ability to foster community and to be just to be nice to people, all those things I think are extremely valuable.

And the contrast to that that people, I think, immediately jump to is the sort of brilliant asshole idea where you have this guy who can do a man or woman who can do amazing code, but is just intolerable to be around.

And I think there's sort of a middle ground there where there are people who are very good at this profession, but who just are not normal people.

I kind of think you might be describing yourself a little bit there, huh?

Like the slightly grouchy quality software engineer.

Maybe a little bit.

I don't want to sound like I'm self-grandizing or choosing.

No, I didn't mean to accuse you.

I was just kidding.

I wouldn't mean to accuse you.

But I didn't mean to accuse you of that.

By the standards that I'm thinking of, I am super, super normal.

I've worked with some people who are just very out there.

I hesitate to even give examples because these things that these people did were so strange that should any of them ever listen to this, they will immediately be able to self-identify them.

Okay.

So that sounds like what's the worst you ever saw is a feature there?

No.

I mean, again, these are people who are very good at the job, but they were not the sort of person who would mentor anyone.

As an example, there was a guy I worked with once who everybody agreed was brilliant.

And one of the things that he liked to do was he would like to bring in food for the office.

That's a nice feature.

Exactly.

So he would bake things and he would bring them into the office and leave them in the kitchen.

And he would get frustrated because nobody would eat them.

And the reason that nobody would eat them was that he was so strange.

People were just concerned about what he might have put in them.

That's too bad.

I feel bad for that guy.

I feel bad for that person.

I did too.

I was like, I really wish somebody would eat your cake, but...

But you wouldn't eat the cake.

Even I was a little bit wary of...

I mean, this is definitely the kind of guy who probably had a collection of snakes at home or something.

This is a guy who probably had...

No offense if you have a collection of snakes at home.

This is something.

This is probably somebody who had mice in his freezer.

All right.

Best I Ever Saw.

Here's what I want to do someday.

I don't know if we're ever going to do this.

I would like to go out and interview some of the people we've worked with, people who were good.

Maybe we have people on the show in the future.

They don't have to be in our field.

We could just ask them, what's the best you ever saw?

Hopefully, we'll make them prepare that for or make them think about it for a bit.

I think it's an interesting question.

I like that.

All right.

Thanks for hanging out with me today, Mike.

You're welcome.

This has been Picture Me Coding with Eric Aker and Mike Maul.

Mike, I will see you next week.

Yeah.

See you next time.

Bye-bye.

Bye.