Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Become a patron For just five dollars a month, you
get access to a private RSS feed where all the
shows have no ads. Twenty dollars a month will get
you that and a special dot NetRocks patron mug. Sign
up now at Patreon dot dot NetRocks dot com. Hey,
Carl and Richard here with your twenty twenty four NDC schedule.
Speaker 2: Will be at as many NDC conferences as possible this year,
and you should consider attending no matter what. The Copenhagen
Developers Festival happens August twenty sixth through the thirtieth. Tickets
at Cphdevfest dot com.
Speaker 1: NDC Porto is happening October fourteenth through the eighteenth. The
early bird discount ends June fourteenth. Tickets at Ndcporto dot com.
Speaker 3: And we'll see you there, we hope.
Speaker 1: Hey, guess what it's dot net rox. I'm Carl Franklin,
and I'm Richard Campbell, and Billy Hollis is here. Billy,
you can chime in anytime, because I think you can.
Speaker 2: Pass the threshold.
Speaker 4: I appreciate that I do, and I might, but you know,
I know you guys have early show things you need
to do, so I'll want you to go ahead and
do that.
Speaker 2: No your first rodeo.
Speaker 1: Yeah, well, Billy, I don't know. I kind of think
you're really gonna love my better no framework. And there's
two of them for today, so by all means, feel
free to jump in. After we roll the crazy music,
let's go.
Speaker 4: What do you got?
Speaker 1: All right? So I have a link to a Reddit
rant and it's all about somebody who's ranting about zamal
or WPF. Right, so here you go WPF zamal frustrations. Bill,
You're gonna love this. I love that this is good
and this is from three years ago. I am attempting
to broaden my c sharpabilities by making different UI projects.
I've had two experience with examal, once at making a
simple phone app, another just now while trying to make
a personal project. Both have been incredibly infuriating. The first
time I would just assume I was being dumb, but
now I feel as though examal is just a steaming
pile of dog shit nice. Anytime I edit a file,
dot zamal er dot c S Visual Studio loses its
fucking mind and throws the most ridiculous errors that I
have nothing to do with the problem. And I think
that's more about visual Studio and no about examble. But
half the time some magicalxamal dot g dot cs file
breaks for no good reason in parentheses. No, it's not
the common problem name spaces being wrong. Cleaning in or
rebuilding the solution does not remove those errors. I have
to let it happen, clear the file, and save it
over again again. Nothing else in the change is just
saving over these filed generated files fixes it. Then when
I go to launch the project, it will not bring
up the main view seventy five percent of the time
without changing my code. Just some seemingly random combination of
cleaning and rebuilding allows it to start again. I'm way
better with back end stuff, so maybe I'm doing something
horribly wrong. I read the documentation, searched for solutions to
my particular errors, and check every detail, but still feel
like examble is an uphill battle. End of rant. And
then he goes on and people try to talk him
off the ledge. But Billy, I thought.
Speaker 4: You, well, Zambo is an uphill battle.
Speaker 1: I thought you'd get a kick out of that.
Speaker 4: Learning how to use it effectively is hard. It's the
C plus plus of enterdetechn of versation.
Speaker 2: Just waiting with a zero pointer to move everything.
Speaker 4: But you can do things with it that are difficult, impractical,
or in a few cases impossible to do with other
common technologies. And once you do learn how to do it,
and you learn to switch your mind and how to
think about it, then you can create experiences for the
users that have enormous value. It's worth it, but I'm not.
I've never been one to say that you should just
jump and dizamble and start using it. And no, it's
it's it's a real uphill struggle. I mean, look, I
made a lot of money training people and examble for
many years because I constructed an approach to help people
switch from the way they think about programming in regular
code see sharp or whatever, which is an imperative way of.
Speaker 1: And as I said, I think this guy's problem was
clearly one hundred percent visual studio.
Speaker 2: It wasn't you know. I read a little further down
the line there he was using MVVM cross, So I
wonder if he wasn't using it well, because you know,
you have to approach those libraries with their intent. So
I suspect he may have been just fighting with MVVM.
And let's face it, when you mess with something related
to the library, it's gonna spew terrible messages like you
were gonna have it.
Speaker 1: All right, So I have something else that I want
to bring up in better no framework. I actually have
two things. So Zamal for Blazer came out last year. Now,
Zamal for Blazer is the brain child of Giovanni Albani,
who's the guy behind open Silver, and it's also based
on open Silver. So this is basically unleash the power
example in your Blazer applications. Yeah, so it and open
Silver was sort of an open source version of silver
Light that Giovanni started. In fact, we interviewed him twice.
Speaker 2: Yep, yeah we he interviewed him twenty delivered.
Speaker 1: It exactly in twenty twenty and in twenty twenty one
when he delivered it, and so so this is this
is interesting stuff. So if you're you know, you want
to get on the web and silver Light was the end,
I'll be all for you. And you liked Xamal in
the browser, uh, Zambal for Blazer, Zamal Dash four Dash
Blazer dot com checking out.
Speaker 4: That's been on my list to check out for a while.
Speaker 2: Yeah, it sounds like a show in the making, isn't it.
Speaker 4: I've done most of my stuff in that space with
the Uno platform, yeah, and that has worked out pretty
well in general. They was a real road there over
the last five or six years to get that complete
and stable, especially for the web. Some of the early
stuff they.
Speaker 2: Did, yeah, you know, did a lot of twist and turns.
They came into the game as a UWP platform and
realized they needed to transform and did yeah, like quite
an accomplishment really.
Speaker 4: So they're an interesting alternative to Zammering now for multiplatform stuff,
and so I've been spending time with that. But yes,
I'd like to take a look at Zambal for Blazer
because I really do hope that the responsiveness of the
Blazer engine will be the way to get a lot
of the experiences I want to see and just normal websites.
Speaker 1: And you know, I'm I'm not gonna stop on the
whole visual studio challenge thing. I often had problems like
that even with MAUI in visual studio, with xamble, you know,
overriding and generating files and then being out of sync
and stuff. It's better now. But one of the things
that's cool about the web platform is the whole rendering process.
Speaker 3: Right.
Speaker 1: You don't typically have those problems because but the end
product you're looking at is just pure markup right in
code or whatever. So anyway, that's a that's my rant.
Who's talking to us?
Speaker 2: Richard grabbed a calm on top of Billy's last show
when we did back in December twenty two, episode eighteen
twenty two. Coincidental numbers. By the way, I believe this
is your twenty fourth episode, Billy, oh man, I wow,
do believe we owe you like a sack of submarine
though this point. You were a guest on episode three three, Yeah,
you know, and here you are now on what is
this episode nineteen fifteen?
Speaker 4: So I can't believe people aren't just tired to listen
it to me.
Speaker 2: Well, I'm not, you know. I call you routinely because
I see the work you're doing. I'm like, oh, dude,
I want to talk about that, right, Like that's the reality.
Speaker 4: Always doing something new. I'm too easily bored to keep
doing the same self.
Speaker 1: So exactly true.
Speaker 2: Still, so that last episode was Thinking High Level Design,
which I thought was really enjoyable. We had a great
conversation there, and the audience seemed to agree because lots
of messages and this one's from Ismo who said this
sounded like a fun episode of discourse with Billy, Carl
and Richard. It really got some wheels turning into discussion.
One particular part of the episode that stood out for
me is when Billy mentioned the idea that companies quote
have designers, but they don't know how to implement design
thinking and produce great high level design. Similarly, I find
we could apply the same logic to most enterprise architects.
They know how to organize and dive deep into code
and maybe how to output some pretty nice cloud diagrams,
but we seem to fail spectacularly in putting all the
pieces together to make a very well put together pieces
of software. High level design thinking can fit this, if
only we could get out of our own way.
Speaker 4: I can't argue with any of that.
Speaker 2: Well, my immediate thought is, you know where do most
architects come from? This is my only promotion path as
a developer, So you're sort of driven into the architectural role,
whether it's a natural fit for you or not, and
you rarely get additional training. And so this idea of
being that architectural leadership, of really being you know, responsible
for the shape of your project, I just don't know
that anybody takes that on intentionally. You have to eventually
realize it needs to be done or you don't. And
it's a weak spot in the whole thing.
Speaker 4: There isn't really an education path for it, right, Yeah,
So somebody has kind of have some natural talent and
try things out, maybe they have a mentor if they're lucky.
But the supply of enterprise architects who are actually good
at what they do is so limited that it's it's
hard to find a mentor and do things. You have
to solve real problems to do it, and we really
don't have anything a lot. We have less than ten
percent of the expertise in our product atensure that we
need in this profession.
Speaker 1: Well, and going back to design aptitude, I have a
story from my own family. My daughter Emmy in as
a junior in high school. Turns out she had ridiculous
artistic talent, right she was doing three D models, and
she met with one of her mentors who said, you
should go to in for industrial design. So she went
to Rhode Island School Design, which is Risney's prestigious design
school in these coasts, and Risney and got a degree
in industrial design. And I said to her, hey, you know,
can you help me with like some some web stuff.
She's like, I don't want to do web stuff. Hey
can you help me with some graphics? And that I
don't want to do graphics, you know, she's like, she
was like, I want to do industrial design. Guess what
she's doing.
Speaker 4: Now, what's that?
Speaker 1: Web design?
Speaker 4: Web design?
Speaker 1: Yeah? All right, well she's doing it on the side,
but yeah, she.
Speaker 4: Has That's just that's the easy way to get into design.
And it is a look. I go to a lot
of meetings of meetups for designers, for visual designers, and
I talked to a lot of people at conferences and
things like that, and we've reached a point now where
those people, for a lot of the decision makers in business,
those web designers, that's what design is. Yeah, as far
as executives are concerned, that's not really healthy. Because that's
why I started to talk more about design thinking instead
of just design because the term design is so overloaded.
Speaker 2: Yeah, so sure so is well, thank you so much
for your comment, and the copy music co Buy is
on its way to you. And if you'd like a
copy of music go buy right a comment on the
website at dot at rocks dot com or on the facebooks.
We publish every show there and if you comment there
and to read on the show, we'll send you a
copy of music go buy.
Speaker 1: And yeah, music to code buy is still going strong. Yeah,
people are still loving it helps you stay and focus
while you code or do anything deep work. It's the
term I heard today. I like that talking about work.
All right, So let me formally introduce Billy Hollis in
case you've been sleeping under a rock for the last
twenty years. Billy is a software designer and developer with
a contrarian streak that often challenges conventional wisdom in the industry.
Is that true, Richard.
Speaker 3: No mo.
Speaker 2: If you need to to testers for every developer, you
must suck as.
Speaker 3: A developer.
Speaker 1: End quote. He has a consulting practice in Nashville, Tennessee, USA.
He and his team focus on user experience design, which
is ux advanced user interface development. Rules based architectures and
healthcare systems. He teaches classes for design thinking and UX
design and technical classes on zamal for win UI and
Zamle for WPF. Okay, there you go, your official bio
for today. Billy, you go.
Speaker 4: Yeah, And what the bio never says, because there's no
good way to put it in there, is that what
I really am is a generalist. And I decided that
all the way back in high school that that's what
I was going to be. In an economy where everybody
tells you to specialize, I already decided I was going
to be a generalist.
Speaker 2: When I first met you, and at least twenty years
ago now you were much more an app architect personality.
I watched you evolve into someone who cared deeply about design.
Speaker 4: Well, you watched me expose it. Yeah, perhaps, says but
I cared about it before that. It's just that nobody
else in the industry did, so I didn't talk about
it then.
Speaker 2: Well, and the tech also changed, Like you were there
first when zamble emerged, and you were long before Microsoft
knew what the heck to do with that, you were
already gone in a way.
Speaker 4: Well, that was the reason I embraced it so much.
Is that sensibility about doing design? Remember my first book
in nineteen ninety nine has the title Design, Specification and Objects,
which kind of helps you understand that I was moving
in that direction even earlier. But yeah, nobody cared about
it until some of the technologies came out to be
able to do some of these interesting things.
Speaker 1: Nineteen ninety nine when the word objects was novel was novel.
Speaker 4: Yeah, and the iPhone was one of the break points
to put people into a new way of thinking to.
Speaker 2: Learn the words.
Speaker 4: So that's why I began talking about it more. I
cared about it before that, and I've certainly learned a
huge amount of the last fifteen years. But yeah, I
always cared more about it that I think than most
people in the industry.
Speaker 1: So you're thinking these days about how to make design pay?
What do you mean by that?
Speaker 4: Yeah, well, see, that's that's because the entire area is confused.
I talked about this. You go to a typical person
running a software development team and he somebody tells him, man,
you need a designer, and he goes to HR what's
what's what are they going to get? They're probably going
to get a web designer, because that's just what the
industry kind of thinks. Well, the term design thinking is
to help break loose from that, because from my perspective,
that kind of visual oriented design is the lowest step
above not doing design at all.
Speaker 1: Hamburger menu or no Hamburger menu.
Speaker 4: Yeah, I don't mean to say it doesn't any value,
because it does. Nobody wants an ugly application or website,
and proper layout and good cosmetics do in fact increase
the quality and value of websites and of apps. But
when you start getting into interaction now, the potential for
design to do things goes up. And there's a spectrum
that goes all the way up to business process re engineering,
designing entirely new ways for a business to operate. Design
thinking embraces that entire spectrum. And I want people in
the industry to kind of understand what level are you at,
because what level you're at now determines what kind of
people do you need to get to help you Billy.
Speaker 1: Sometimes you know this the simplest decision, the simplest decision
should it go here or here, can make the difference
between some process that takes an hour and a process
that takes ten to fifteen minutes, the simplest decision.
Speaker 4: There's a famous article that's that's still relevant called the
six million dollar Button. Yeah, you've probably seen that article
one time or another. Thad if you google that, anybody
who's listening can google that and get the article on
how moving a button save six million dollars?
Speaker 1: Are banks the worst? Bank websites the worst? In your opinion?
I mean in my opinion. Richard's nodding in, So I
have a local bank, and I wouldn't trade them for
the world. They're the best because they're local. Even when
I go to like the virtual ATM, like the people
that come on screen, Oh hey, Carl, how's it going.
How's the band right? Like? I feel connected to this bank.
And yet the process for doing ach payments, which is,
you know, direct deposit payments, requires you to go to
a screen see a list of the last payments that
you did, that all the way down to Texas, you know,
And to start a new one you have to scroll
all the way to the bottom and hit new nice.
And then after you do a new one, it goes
to the bottom again, and so you have to sort
by date and then sort by date again to get
to what you just put in so you can edit it.
And this is the dumbest fucking thing I've ever seen.
And it's a bank.
Speaker 4: Well, yeah, banks are some of the worst offenders, and
there really isn't much excuse for that. My eighty eight
year old mom does online banking and they keep changing
the site. Now. Look, she's smart and she did eventually
learn to do her online banking. In fact, she prefers
it now. Her mobility is more limited than it used
to be, so not having to trot down the bank
is a big help for her. But I mean when
she calls me once every year or two, they've changed
the page and I don't understand what.
Speaker 1: Yeah, oh, they made it easier, mom, They and they didn't.
Speaker 4: Make it easier, that's the problem. In many cases, they
just changed it for the sake of change. Now the
banks are learning and they are getting better. My bank
US Bank actually does a pretty good job with their
website and just an excellent job with the app that
they put on the phone, So they're kind of learning this.
But yeah, I hear complaints about banking sites and apps
all the time.
Speaker 1: I guess if it works, that's enough for them. Right,
because people are going to be able to do and
it doesn't matter how frustrating it is for them, they'll
do it.
Speaker 4: That was a quote that I coined way back in
probably twenty eleven, was that for most of the time
in this industry, just making something possible was enough that
people consider themselves successful. But it really shouldn't be it. Also,
you also should consider making it easy as part of
their success.
Speaker 1: And enjoyable even shall we even go that far?
Speaker 2: Yeah, delightful, but yeah, okay, we talked about the six
million dollar button. The real question always is you're delaying
writing code, messing around with the design stuff. Let's just
get to work.
Speaker 4: Yeah, And my perspective on that is, and having been
involved in a ton of projects both with and without
design up front, all the way back to see stuff
in the eighties and the late seventies, I have never
seen a project where designed doing design up front wasted
time or took more time until you finally got delivery.
And the reason is it eliminates a lot of blond alleys, right.
I mean, if you don't do design, you're going to
end up doing things that you take to people and
they go, now, this isn't what I needed, or this
isn't good now, or I hate this and then have
to do rework on it. So the idea that you
need to start coding first, I mean back end stuff.
I guess maybe even there though, I think the back
end is sometimes more affected by what goes on with
the user than a lot of developers tend to think.
Speaker 1: But developers, and they do, dare I say, test their
apps in you know, in development, they have to test them.
So the idiot that designed that page had to fill
the screen with dummy data and scroll all the way
to the bottom. You would think he said, hey, I
got an idea, let's put these buttons at the top
of the page. He would probably.
Speaker 2: Had three records, like he never considered that somebody would
have more.
Speaker 1: Probably right.
Speaker 4: Yeah, but you've got that psychology, Carl, And I've got
it too that I see these flaws and that irritate me.
I have an emotional response to these flaws. But I
can tell you that a lot of developers don't.
Speaker 1: My wife that my wife uses an app and she
can't figure out She's like, some damn programmers screw this up.
Speaker 4: And I think that's that's good. Yeah, especially for developers
they ought to be offended by poor design on behalf
of the users. But the fact of the matter is,
I'll run into a lot of developers that just oh, scroll, okay, fine,
I mean, they're paying me by the hour, does it
matter to me how much I scroll.
Speaker 1: Kelly's mother is a Southern bell from Lake, Missouri, right,
so anytime anything screws up, she will always say, some
man probably designed this.
Speaker 4: I will say that in general, while the difference isn't great,
the women in this industry do pretty well at design,
and maybe somewhat better than the men. Now, there are
men who do a great job, but there are more
men who just aren't any good at it at all.
So the women win on average.
Speaker 2: I think, And I wonder if it's just a lack
of awareness, like you're not noticing that this UX could
be better well.
Speaker 4: And that's why some of the very first stuff I
ever started talking about in seminars and such for UX
was about the principles of how the brain works now
the visual system works, because that sensitizes you to things
that if you know why something doesn't work, well, why
don't people like to scroll? Well? That does not work
in concert with the visual and cognitive systems. You're constantly
having to refresh and absorb new material, which which causes
cognitive effort as well as wasted time. So when you
start to learn some of these principles about how the
brain and the eyes work, now you tend to notice
things more that don't work in concert with them, and
thereby slow people down and frustrate them.
Speaker 1: Do you do a lot of reworking of legacy apps?
Speaker 4: Billy Well, I personally don't do a lot. I do some,
and that's probably fifteen to twenty percent of my work.
But in terms of people want being interested in it,
that's a very high, highly ranked topic because, let's face it,
lots of teams have these legacy apps that are there
are many millions of dollars invested in and they have
yet to experience the pressure to replace that moved new technologies.
Typically a platform change, a dramatic business change causes new
people to move to new platforms, and that's when they
typically involved me. But most people aren't in that situation.
So I've been doing a session lately on ux designed
for legacy apps. That's been pretty popular. I've done it
at several conferences.
Speaker 1: That's good. I have a customer and I looked at
this legacy app that I was upgrading. I said, how
old is this? And they said, oh, since about episode
eight hundred.
Speaker 2: Twenty thirteen is something like that stuff like that. So
I've still got your list of shows up there. So yeah, yeah,
it would have been about twenty thirteen, twenty twelve.
Speaker 4: I basically remember that because episode six hundred was the
one that introduced using the joke you talked about their
Richard where I was going on about some of the
people whose heads in the cloud, about how you do
development and all the extra testing and all the stuff
that goes with it, and we did that on stage
in San Diego, yep and twenty ten, I think, and
I remember Richard falling off the chair when I too
punched the line of that jair.
Speaker 1: You couldn't revive me. So tell us about so tell
us about this talk on legacy apps designed for legacy apps.
Speaker 4: On legacy apps. Yeah, it came about because of something
interesting that I hadn't planned it because since I don't
normally do that work, a lot of my talks are
based on the work that I've actually done. In this case,
though I do sessions for people for free to sort
of introduce them to the whole idea of design. And
that's partially because we don't have sales when we don't
do traditional marketing, so that introduces me to people. I mean,
the primary way that I find new people to work
with is the conferences and going to and doing sessions
and talking to people in depth there. But I hit
upon another way a few years back, when the virtual
stuff became very easy to do, is well, if people
want to lunch and learn, well, let's put me on
the screen man, I'll I'll talk for forty five minutes
about some topic. And I had a list of them,
and I had somebody that asked me to do it
looked at my list and nothing really lit them up,
and they said, well, we're stuck with this legacy app.
What advice would you give us about applying design? So
I wrote a whole new session on that and it
was it was very successful, and I started doing it
at conferences too, and it gets it gets bigger audiences
typically than my sessions on how you redesign an app from.
Speaker 1: Scratch step one, burn it down.
Speaker 4: That's a problem inte. And so I started thinking about
it and thinking well, what if you are stuck in
kind of a legacy world. First of all, I understand why,
because trying to change out an entire application that runs
a business is an enormously risky proposition. Yeah, and its
expensive too, But I think, honestly, I don't think it's
the expense that drives people away from it. Mostly I
think it's the risk, because it's an existential threat if
you get it wrong. So improving the legacy app, well, okay,
would you want to improve legacy apps? So I made
a list of the areas that I had seen that
I thought worked well. Search was very high on the list.
A lot of legacy apps have very poorly designed search
because it was designed twenty years ago or whatever. And
our database technologies are better now we could do full
text indexing and all that kind of stuff, where twenty
years ago we couldn't. And it surprises me how many
corporate apps still require you to search by entering information
in different fields. If I want to search for address,
I have to enter something in a field for address,
Whereas the world has gone beyond that, haven't, I mean, everybody.
Speaker 1: Just time and have these programmers ever heard of link?
Speaker 4: Yeah? So or re search is an obvious candidate, and
it's not so much just that you change so that
you enter into a Google sell bar. It's more about
how you expose the results. Because right now developers just
dumping in a data grid and that's okay actually for
so for some interaction cases, especially if people are going
to kind of sort and massage the data a lot,
then data grid's okay to do that. But we've got
card views and all the stuff and graphics that we
can put in there.
Speaker 1: I'm working on an app right now, Billy, where we
leave it up to the user to decide whether they
want to see stuff in the grid or in cards.
Speaker 4: Oh, that's I'll be interested in the results of that
simple And part of it is how well designed are
the cards, of course, But in general, if the cards
are well designed, I find that people tend to prefer that.
Because this gets back to some of the neurological things.
The part of our brains that works with graphics and
shapes and color is much older in evolutionary terms than
the part that reads and it interprets numbers, and.
Speaker 1: Certainly that reads spreadsheets. Yeah, that's kind of new.
Speaker 4: So in essence, there's an ease of absorbing the material
when you're leaning on graphics and such. For example, if
you've got, oh, you've got five categories of returned results,
and you've got a graphic for each one, the eyes
will be able to use that graphic to zero in
on the one they want very quickly. And it actually
feels good because anything that helps your brain offload cognitive
effort feels good. It's at a subconscious level, but people
tend to be attracted to and become attached to those
kind of views if they leverage graphics, well, now, if
they do allows e job and the graphics are just
as hard to figure out as the text, then you
don't get any benefits.
Speaker 1: I like the card idea because you know, when you
put a border around something, it's a thing. You know,
it has a boundary, it's a thing. Whereas it can
just be some space around it and it's still a group,
it's still a thing. The line in a grid is
much more difficult for the brain to understand, much more,
much more.
Speaker 2: But aren't you getting to a point here where you're
trying to punt on the design and saying let the
user define how they want to see things.
Speaker 1: Well, that's yeah, well in this case. In this case,
there were users that wanted a table and there were
users that wanted cards. So we were we had this
you know, design meeting. They were yelling back and forth
and stuff, and I'm like, hey, we can do it.
We just do in a JSON file.
Speaker 2: Yeah, it'll be okay.
Speaker 4: Say, I use that approach quite a lot because you
do get into confrontations typically because the range of users
is such that they are advanced users and there are
simpler users. And I really don't like the idea of
hamstringing everybody because some power users need some things.
Speaker 2: Yeah, and definitely you get that split between the novice
users that are going to use that out once a
week and the person that's in there four out of
eight hours of even working day, and they just they
want all the shortcuts. They want to be as efficient
as possible because they're in an out of there so often.
Speaker 4: So that's real. That's very smart to do that, Carl.
And because it does short circuit a lot of the resistance,
you get to change because there is there is status
quo bias among people that people tend to like what
they're comfortable with, what they're used to, and overcoming that well,
first of all, you have to do some good work
and come up with a good design. Just trying to
make minor changes typically doesn't really work very well to
get those people off the button for the old stuff.
But if you come for something really new, then they're
more likely to see that and realize that that's better.
But yeah, in general, you are going to have in
many cases two groups and you just can't reconcile between
the two.
Speaker 2: And they're both valuable and important, you know, I would
say occasionally, I've certainly seen apps where nobody spends enough
time in it to be good at it, right, where
the leadership leading you all the time models what everybody
ends up using. Because it's like I go to this
thing once a week, I go into this thing, you
know once a month. Nobody's ever going to be.
Speaker 3: Good at it.
Speaker 4: Yeah, And unfortunately, because there are parts of the app
that are used quite a lot, that's where you tend
to put your investment because that's where your payback is.
So those parts of the app very often or not
as well designed because you just don't have time to
do it.
Speaker 2: You can't tune everything up, tune up the thing's going
to give you the biggest return.
Speaker 1: Do you remember, Billy, And we got to take a break,
so I'll make this quick, but do you remember I
wrote this tool for Windows Forms that was sort of
like UI Beginner, Intermediate, and Expert mode levels and you
could tie those to the different you know, visible properties
of controls, and so the user could say, I want
to be in beginner mode because they're just learning the app,
and so it kind of guides them through the easy stuff,
going to intermediate shows, a few more features, expert shows,
humor reaches. I really like that, and I've used that
metaphor ever since for.
Speaker 4: It's a It's a great metaphor, and it works even
better with modern technologies where you've got dynamic layout. Yeah,
that responsive layout. The problem in more static environment slighted
Windowsforms was okay, now I'm leaving holes in the screen,
and some don't like that, but yeah, I think that's
an excellent approach. You just don't want to clutter a
screen with stuff that somebody is not going to use,
and so that's one really good architectural way to sort
of give it enough flexibility that you're accommodating a wider range.
Speaker 1: And the one thing that you have to be careful
with with that kids, is that you have to make
the option to go to the next level discoverable enough
so that people don't get stuck inside where is all
this stuff?
Speaker 4: Yeah? In general, I mean that's that's a great example
of configuration. We put a lot of configurability in our apps,
and configurability is one of the ways that you do
try to bypass a lot of these blockages, these these
where people are button heads about the way. In fact,
I've seen cases where people where a team would thrash
for six months over something fundamentally fairly simple y to
them both likely, Yeah, stop stop arguing about it.
Speaker 1: Yeah, just Raightbode, it's a radio button.
Speaker 4: So we do a lot of configurability. In fact, I
think a good architecture for applications ought to have some
poplines for configurability built into it. That it ought to
be really easy to implement configurability in the UI instead
of having to close up some code to do it.
I mean, you're in your your little your thing to
sort of tag the stuff at what level is an
example of that kind of configurability.
Speaker 1: All right, And with that, we're going to take this
very brief pause for these very important messages. And I'd
like to remind you that if you don't want to
hear these messages, you can become a five dollars a
month patron at Patreon dot dot netroocks dot com and
you can get a feed that is ad free. All right,
now here comes the annoying part. We'll be right back.
Did you know you can lift and shift your dot
net framework apps to virtual machines in the cloud. Use
the elastic beanstalk service to easily migrate to Amazon e
C two with little or no changes. Find out more
at aws dot Amazon dot com, slash elastic beanstock. And
we're back. It's dot net rock some Carl Franklin's my
friend Richard Campbell. Hey, and we're talking about our friend
Billy Hollis, the right Reverend Billy Hollis, And uh he's
got some good ideas about design, about the designed for
legacy systems, and uh yeah, and and all those little things.
Speaker 4: Some of the some of the other areas besides search,
data visualization. I mean, we got all this wonderful ability
to do data visualization with our modern UI technologies, but
how much data visualization do you see in the typical
corporate app. I mean they might they might get a
charting package and do a few pot charts in bar
charts and that's about it. Whereas a custom designed data
visualization can sometimes not only speed people up and keep
them from making mistakes, but it can also communicate to
the user, Hey, I understand where you live and work,
and I've developed this software for you. They tend to
have an unconscious favorable understanding of what you do if
you accommodate them in those kinds of boys. So data
visualization is very underused. I mean I see dashboards and
they've just got the most common looking stuff. It's just
a whole bunch of line charts.
Speaker 1: From the fact we were done with pie charts. Apparently
pie charts haven't died yet.
Speaker 2: Yeah, well pi charts were always bad.
Speaker 4: Yeah, but somebody wants a dashboard. Somebody, some decision maker
wants more. Okay, we do a dashboard. Now what do
we put on it? Well, they don't think about that,
and that's really too bad because dashboards, by their nature,
ought to be very dynamic. You ought to be able
to do new wiges for a dashboarding time you want.
And and when I've seen that when companies adopted that
at acute. Now you get some really really useful dashboards,
things that contain Oh okay, here's the top five things
that you need to worry about right now, you know.
Speaker 2: Hell, And that's where visualization is like the sort of
up into the right graph because okay, if but it's
going up to right, good things around them, it's going
down to the right, it's bad thing happening.
Speaker 4: But certainly data visualization is one of those design things
that you have to take into account. Sort of a
typical you have to do some sketching. Really, if you're
going to do a good data visualization, you start with
pencil and paper.
Speaker 2: Do you like tools like Pigma? Like where do you
sketch up your your app?
Speaker 4: I'm fine with almost any wireframing tool, and Figma is
very popular right now. My partner Gary Bailey, who's does
quite a lot of that work. In our case, locks
of Balthsenic and I think they're like that just for
Balsenic over Pigma. Psychologically, Balthsenic looks like a sketch and
Figma does not. And when I takes people, I want
them to critique them. What if they look like a sketch?
Psychologically they go, oh, yeah, I guess it's just an idea.
Figma looks more like a finishing.
Speaker 1: For pollsamic with a queue.
Speaker 4: So I'm not as fond of Pigma as a lot
of people are. But what Pigma does do, and I
think the reason why a lot of web designed kind
of people take to it is you do get something
that's very representative of what's actually going to be put
on the page, whereas balsamic does not do that. And
since those people are more concerned with the esthetics and
the visual stuff, Figma tends to be the tool that
they go to. But the basic idea for all of
these is don't start with them. Don't walk up to
an electronic tool to design your screens. Get a pencil
on paper, man. Go out there and think about how
that thing's going to be laid out, and try two
or three or four different ideas for how you do
it so you can compare them.
Speaker 2: Sorry, pencil, paper, pencil.
Speaker 4: Yeah, that technology has been around for two thousand years now.
Speaker 1: Random access. I like the resolution, great battery life ever run,
and the storage capacity that's always believer in the whiteboard too.
Speaker 4: That yeah. Basically, when when I teach classes on how
to do design for to mostly to developer teams. I
emphasize use any media you want as long as it's blank.
Don't do lined paper that flips and switches in your head.
Speaker 1: And when you're done with your design on the whiteboard,
take a picture.
Speaker 4: Take a picture.
Speaker 1: Just guess what the cleaning crew is coming in and
it's going to be tomorrow.
Speaker 4: Yeah. So, especially collaborative de nown with two or three people,
whiteboards work work really well. But you know, one of
the options that that has been particularly popular among the
people that that I've worked with in recent years is
butcher paper. Butcher paper amount, I think, well, it comes
in rolls. So you think about the tables that are
in the typical conference room, unroll about six or eight
feet a butcher paper.
Speaker 2: Everybody got a corner.
Speaker 4: Everybody's got a piece of it, and and everybody kind
of so that that gets past the thing of see,
some people are like to kind of sit back and
let other people do all work, all the sketching. So now, okay,
you got your piece, don't tell me what you want
me to sketch. Go ahead and sketch it yourself. And
then when you when you want to store the finished drawings,
you roll them up, put a rubber band around.
Speaker 1: Now, are you talking about the light green butcher paper
or the barbecue but wrapping stuff? Because I figured that's
what you would pick, is the pink paper.
Speaker 4: It's the pink pat No, no, no, you want white paper. Yeah,
you don't want any psychological whatever predisposing people in any direction.
Why is the best color that we can We can
put a link for the show in the product I
use on Amazon if you like an Amazon link that
reclinds to the roll of butcher paper. It's about one
hundred and fifty feet and I think about fourteen inches wide.
That's great, And so yeah, that that's a really good,
really good option and for teams. But yeah, I like
a lot of whiteboards, especially in the early stages where
you're trying to figure out a little bit more about
the flow. But yeah, there are lots of ways to
do it as long as you use blank media and pencils.
Colored pencils are nice, yeah, and colored markers are nice.
They you emphasize some things.
Speaker 2: But blank paper very good.
Speaker 1: And again take pictures of it and end up in
the garbage someday.
Speaker 2: Well, like I said, it rolls back up again so
you can you can keep it compact.
Speaker 4: Yeah, that's the not that's one of the reasons I
love butchet paper easy to pack up and take home
and and unroll when I need it. So yeah, that
has worked really well, and I I don't think I've
ever had a team that used it before I came in,
but they all like it after it.
Speaker 1: I tried pizza boxes once but the pencils didn't work
in the three spots and.
Speaker 4: They so, yeah, you have to do a lot of
sketching for data visualization. And then the other area that
that for legacy apps. I tend to suggest to people
is to do some work on workflow because you think
about these apps that have been developed twenty fifteen, twenty
years ago, they tended to have that model of basically,
the app replicates what's in the database, the menu replicates
what's in the database. There's a lot of crud screens.
Getting data in and out is the primary thing that
the app is doing. So you think about workflow with
an app like that, you've got five steps in a workflow,
you probably have to go to five different places in
the app to do it. And understand that that we're
talking about those principles, those cognitive etc. Principles. One of
the basic standard principles is that short term memory is
limited and cognitive effort is limited. You stress people out
if you make them think too much. So think about
now workflow and a legacy app. If you've got to
bounce around to five different places to do steps, you're
having to store in your short term memory where you
are and what you have to do next, and expend
the cognitive effort to kind of remember where all these
things are. Well, leave that in place, don't take away
any of those things, but you can develop an ad
on that steps people through the steps and link straight
to the thing that they need to do and tracks
where they are.
Speaker 1: You do stand up comedy too right? I do because
I feel a routine coming on. You know, you could
mimic Jeff Foxworthy. You might have bad design if if
if you find yourself pulling up notepad between screen A
and screen B, you might have bad design.
Speaker 4: And I actually did say I was doing user observation
and saw a woman she would work with a record
and write down the non digit ID on her pad
so that she could come back to it later what
she was doing on the fly. Was constructing a recently
U used list on paper, right, and what man, let's
let the computer keep up with that. Why are we
making her do it?
Speaker 1: At least let them use the clipboard for crying out.
Speaker 4: So, yeah, workflow is a great way to add a
lot of value. Think about this. If you help people
with workflow, not only do you reduce training for people
coming in because they can walk through all the steps,
but you also prevent errors because most old applications don't
have guardrails to keep you from doing things.
Speaker 3: Out of order.
Speaker 2: Yeah, and you could they just fail, Yeah.
Speaker 4: They just mess up. And so if you build a
separate thing for workflow, you can build those guardrails in
so that don't do step three before you've done step two.
Speaker 2: I've been a big there's been a few piece of
software now I've found that as they build a breadcrumb
trail at the top of the screen below the menu
of you went here, and then you went here, and
you went here, and you here, And I found myself
occasionally seeing that bricko trails jump back four steps. Yeah, yeah,
make a change, yeah, you know, be able to get
back down again.
Speaker 4: And then what does that what kind of ripple effect
does that have so you can design extra pieces to
take that into account, and people love that stuff.
Speaker 1: Yeah. Yeah.
Speaker 2: The other one that I've always delighted is don't lose
my work. Like I typed a bunch of stuff in,
then something failed and so forth, and then you get
back there. It's like after this over and you get
back there and so oh it's still there.
Speaker 4: I am going to give the Windows team a thumbs
up on something in that area, because number one, I
don't lock the idea that they update and reboot so much. Yep, Okay,
they promised us a long time ago they wouldn't do that,
can't do it, and now they can't figure it out.
But what they did figure out is that pretty much
any app that they controlled, they've got ways to save
the state. Even notepad no nopad used to just man,
if you reboot it after an update, whatever was in
that notepad was gone.
Speaker 2: Well lock the update, block the reboot, right, So yeah,
so so.
Speaker 1: They when there's eleven they added the memory tabs.
Speaker 4: But yeah, well then it works on THEE when just
ten updates as well. That if it now nowadays, I
guess they backport it or something. But now if they
if they update, do a forced update because of a
force reboot because of an update, then when I come back,
all my notepads are back, they're fine, And thank you Microsoft.
Speaker 2: A good feature, and it's a great thing to think
about in your software too. Like you talk about, yeah,
design that pays, it's like how much work saved that way?
How much frustration saved that way? They're not that much code.
Speaker 1: Yeah, And if if you're doing let's say a Blazer
server application, you can use protected browser storage anytimes somebody
mutates the state, just save that to protect your browser
storage and bring it back when you load up if
it's there. That's one of the or give the give
them the hey, last time you were working on this,
do you want to resume where you left off. You
can even bring them to the page they were on
and the data that was on that page.
Speaker 4: Like yeah, well, Carl, I think you and I tend
to be tuned into that because we started out in
desktop native, where having a lot of state is pretty easy,
and so you get accustomed to leverage again. Whereas people
that begin doing stateless web applications, which kind of the
browser requires a certain amount of state listness, they don't
tend to leaver reage state as much. They just don't
tend to think that way, and so yeah, they should.
We've got ways of doing the state now, and they
need to kind of twist their mentality because that is
such a useful thing for the user.
Speaker 1: Sure is. Yeah, And the application state talks that I
do and Blazer are still the most popular ones because
you know, people coming from different web technologies, that's a
thing that they're not used to. Yeah, in memory state.
Speaker 4: And another thing about all sort of connected to all
the stuff we're doing. We're talking about with legacy apps
and getting a workflow right and such is something that
I noticed a couple of years ago, and now that
I'm attuned to it, You know how it is, You
notice something once and then you start seeing it in
other places. And I've seen, oh at least six or
eight examples now of this. I struggled to explain it
really concisely, but I'll try. I call it generational turnover
because you think about and it's unique to this point
in time because we've all been in the industry long
enough that we know we went through that period when
a lot of businesses were automating. They were switching from
basically paper into computers for the first time, typically very
data related apps. I did my first one in probably
nineteen seventy nine, and of course it really picked up
steam in the mid eighties, and by the mid nineties
you pretty much had to be automated or you weren't
competitive as a business anymore. But you think about how
those apps were done. I mean, we didn't have the
computing power, or the expertise or the money to build
what we would now call it an enterprise app. And
most of these companies are pretty small anyway. So what
got built, well, a piece of the app that you
built a piece of the business, an app for that,
and then maybe another piece for another app for another
piece of the business. And so the systems that came
out of that in the nineties and early two thousands
tended to be pretty granular, data oriented pieces. Everything was
done kind of piecemeal. How did the business function? Somebody
in that business, typically a small number of people, knew
how to take all of those things and implement the
real workflow in the businesses. And we talked about four
They were holding the workflow in their head. They knew
when to move from app to app, and they knew
all the domain knowledge to know when to bypass the
app or get around limitations in the app. They knew
all of that stuff. Most small to medium businesses had
that cadre of people. If they were successful, that probably
meant that they treated those people pretty well and they
hung around for a long long time. Let's do some math.
If a business automated in nineteen ninety that way, and
they've got people that know how to make all this
current stuff work, but that means that there's a whole
lot of information in their head that's required to make
it work. If they were thirty, let's say thirty years
old in nineteen ninety, how old are they today? There
are sixty four I've seen in half a dozen plus
businesses a small group of people who are key to
the operation of the business that are all approaching retirement
at the same time.
Speaker 1: Wow.
Speaker 2: Yeah, there's a lot of skill about to walk out there.
Speaker 4: There's a lot of people walk yeah. I mean these
people are going to go to a retirement party one
day and then that expertise walks out the door that
night and doesn't come back.
Speaker 1: And this the millennials will take over and write it
on the lampstade.
Speaker 4: Yeah, well manh sorry, it's good. Even the best motivated
millennial is going to come in. It would take them
years to build up all that domain knowledge to do this,
and the business is going to take some pretty serious
hits if you don't prepare for this. So a couple
of our clients, that's actually the project we were doing
was taking this string of things that were all built
separately in that the people helped knew how to how
to put together, and replacing that with what you would
call an enterprise system. Even though I mean, I mean
the people at SAP truck tell you that they can
do this, and for some businesses, I think they probably
can if the business is data and accounting driven enough.
But if you've got proprietary business processes, then now you've
got a whole lot of work to do it. You
can either hammer SAP into doing it, which is very expensive,
or you can go get somebody to write the replacement system,
which is is better if you do it right, but
carries a lot of risk. But businesses need to be
sens does this. I was doing that session on design
for legacy apps at a conference and talk a little
bit about that because see The idea is you stretch
the legacy app too far. There's a whole lot of
risk involved there with them, and there are various risks
with the legacy apps being stretched too far, but one
of them is generational turnover. And I kind of went
through with him about the same thing I just with
it with you. I had a guy come up to
me after the session and he said, the insights you
just gave me is worth more than I paid to
come to this conference. He's going to go back and
start doing checking things out. Who are these people that
the business depends on that maybe the top executives don't
even know who they are, and how close are they
getting to retirement? And what's our plan for dealing with it?
Are we going to create a new app? Are we
going to try to transplant that expertise into other heads?
It's it's solved in a lot of different ways, but
a lot of small even up to pretty large businesses.
Because one of the businesses we did this for there
is a multi billion dollar business with five factories. So
people ought to just do a checklist thing in your business?
Are you in that boat? Because a lot of businesses
are I talk to an executive for a large bank.
That is, they've got all these technologies and all the
people who know how to make them work. They've got
to either change out the technologies or get somebody new
to keep them running, right, because those people are just
about to retire.
Speaker 1: I mean, we're all older people here, so and I'm
not there's no secret, right, we've been around a while.
Have you ever encountered somebody who says, you know, we're
going to abandon the whole application idea in favor of
a series of TikTok videos.
Speaker 4: I don't think I've ever heard anything.
Speaker 1: That ridiculous it's coming.
Speaker 4: But way it probably is.
Speaker 2: I mean there's another aspect of this, which is that
the folks that have been doing this, operating that software
for a while are used to the foibles, used to
the problems, yeah, the bad ux of it. Yeah, and
that new folks coming in are going to have a
demand to This doesn't have to suck right like that,
This could be better.
Speaker 4: Yeah. You think about, say, a twenty four year old
coming in for their first job looking at one of
these twenty five year old corporate apps, and they sit
down the first day in front of that thing. What
does that do to their connection to the company they
just started working for. I mean they don't even they
don't even own a laptop or a desktop. All they
know is tablets or whatever. Yeah, the emotional impact of
that is not to be discounted.
Speaker 1: Nope, sure thing.
Speaker 2: Yeah, that's an interesting point in evolution, and it's the
demand is going to get huge as we lose this
knowledge base walking to the door.
Speaker 4: Yeah, and there is the problem is there's just no
clean way to do it. To solve this problem. I mean,
we went into a multi billion dollar company and architected
everything in their production process, from forecasting they needed through
the entire supply chain to scheduling workers in the factories.
And I don't want to sound arrogant and entitle here,
but the number of teams that can go in and
do that there just aren't that many. They're just are not.
So the risk is very, very high when you pick
a team to do that. And so I don't like
being in these decision makers shoes because it's very career
affecting if they get it wrong. And both in I mean,
we've talked various times on donet Rocks about the limitation
of design talent. We don't have enough. We have that
visual design talent, but the interaction design talent and the
other types of design talent are pretty short. But as
I mentioned and earlier, the limitation on enterprise architecture is
really high to if you're going to do enterprise level
workflow the architecture for that. I've done it, and I
know what the architecture involves, and I'm going to be honest.
The average person, even a large company with architect in
their title, even enterprise architect in their title, are not
up to doing it. I don't mean to sound arrogant
about it, but they're just not. I've talked to these people.
Speaker 1: So basically what you're saying is most architects are full of.
Speaker 4: One of the large banks, a different I've talked about
before has over two thousand people in their technical area
with the word architect in their top on their business card.
How many of those people are actually architects?
Speaker 1: You suppose? Well, how many can actually do the work?
Speaker 4: How many can actually do the work.
Speaker 2: Yeah, it's a different thing, but you know, again, the
titles are one thing, works another.
Speaker 1: Yeah, so yeah, sure, I would like to apologize to
all the architects that listen to dot net rocks. That
wasn't talking about you. We're all cool here, right, yeah.
Speaker 4: Well, of course the best architects, of course they listen.
Speaker 1: To do well, you're absolutely right self selection, right.
Speaker 4: Yeah, so there, you know, we've got a filter there,
but the number who are really good at it, it's
I'll see this, for example, in the proliferation of micro services.
Our services are a good solution for some places, but
in a lot of cases they're using this excuse for
not doing architecture. It's just oh, we won't do we
won't do achitecture, We'll just do you the little things
all over the place.
Speaker 1: Billy, you just blew my mind. I mean, we've been
struggling with this whole micro services versus the you know,
the monolith, the modular monolith thing for what a couple
of years now, because people who went down the micro
services road got disillusioned with it. And you just nailed
it on the head people that some people that do
microservice is an excuse to not do proper architecture up front.
Speaker 4: Yeah. Well, it's one of my one of my most
popular slides these days is uh, you know the distracted
boyfriend me.
Speaker 1: Oh yeah, yeah, yeah, okay, right, So boyd.
Speaker 4: He's got his girlfriend there, but he's looking over his
shoulder up and he's walking with But I did one
of those, and the girl walking away is labeled with
writing code and his girlfriend is labeled with architecture ux
design talking to users because developers blow that stuff off.
Speaker 1: And she's looking at him like, I'm going to give
you such a smack.
Speaker 4: I'm gonna So that kind of captures the psychology. We
should probably put a link up for that.
Speaker 1: That's really good, yes, and that to.
Speaker 4: Us that slide too, it's popular, very good.
Speaker 1: So what's next for you, Billy? What do you want to.
Speaker 4: Well, I have a project that I'm starting on to
do kind of a big chunk of an application, but
it isn't replacing an entire one entire one in some
in the engineering space, and I'm looking forward to that.
That's that's some interesting new stuff. I really like the
people that I'm that I'm starting to work with too,
and and so that is kind of a modest sized project.
It isn't as big as the ones that I normally do.
And then I am in general moving toward smaller projects.
And I mean, I don't know how many people really
realize how old I am. But I'm reaching the point
where I won't be doing the large projects that much longer.
And what I found out. You know, I've talked to
people at conferences sometimes will repeats over the years, and
they go, yeah, we'd like to bring you in, but
you know, we haven't gotten our ducks in a row
or whatever. Folks, you're running out.
Speaker 5: Of time that front porch and that picture, and it's
the dead line. It's it's the deadlines that I'm ready
to kind of move past. So I expect to be
doing still some of the large projects the next year
or two, and then after that I'm going to move
to smaller projects for another year or two, and then
I mean I will never stop working, but getting on
the planes and going out and seeing people and taking
control taking command of a redesigned project, which again, the
supply of people who can do that is just critically short.
I mean, look, you guys have been in one of
the most prestigious communities in the Microsoft space for almost
as long as I have the Regional director community. How
many of those guys, and most of those guys have
that special capability to get in front of a group
that includes CEOs or whoever high level people.
Speaker 4: And facilitate the way through to a solution. I mean,
you talk about some of the contentious issues there, Carl,
some of the things that come up trying to arrive
at a solution that everybody's going to be happy. A
big chunk of my work over the last five years
has been serving in that role with companies that got
stuck in one way or nothing, that are thrashing or whatever,
because as an outsider, you can come in and you
can kind of it doesn't bother you as much to
make people mad because.
Speaker 1: Right, and plus you have no you have no skin
in the game, right, right, you're getting paid a rate,
so for your authentic I.
Speaker 4: Expect to keep doing that for a while, mostly because
most of my clients who use me, they'll call me
in every couple of years to get them through some project,
to facilitate. They'll get all the important people in the
room and we'll spend three or four days just kind
of getting they hammered out. Right, And Richard, I know
you've done stuff like that with groups, and the number
of people who could do that is so limited that
my clients are probably going to be still be begging
me to do that in five or six years.
Speaker 1: I tell you what, I love my small business customers.
I love working for small businesses because there's just so
fewer layers and politics. I mean, Richard's kind of a
pulled creature, but I don't like that at all. Kind
of well, yeah you are, yeah, you're right. Not kind
of absolutely thrives in a political environment, but not me.
Speaker 4: So if I were you, if I were bossing some
of the people here about they talk because you talked
about people becoming architects because that's the promotion path way. No,
they should be building a talent stack and learning how
to facilitate is a potential layer in that talent stack.
Speaker 2: No, No, And it's the thing is people who want
to move in that space, We've got to do a
better job of letting them be good at it, letting
them be able to learn. Again, I feel the same
way watching folks bounce between PM and direct dev where
it's like I love someone who wants to do both jobs.
Like sometimes you want to write in the code, sometimes
you want to help other people write the Yeah, yeah,
Like both are rewarding gigs. It's just do we give
room for folks to be able to change and to
you have to get up to speed and give them
appropriate projects. You can't be linear. It's not a linear process.
Speaker 4: But yeah, we don't. As you said, we don't invest
as much in helping people move in that direction as
we should. And if I were to suggest the very
first starting point, it would be learning how to listen better,
because in general, human beings are bad at listening. Developers
are human beings.
Speaker 1: So most sorry you say something, goodness, wife, I got
a dope slap.
Speaker 4: So there are various resources for that. That might be
another link if I can remember, put it on there
to get some some listening resources for people. There's a
book called The Charisma Myth that has an entire chapter
on listening with some exercises. Wow, that I think is worthwhile. So, yeah,
we need to help people move in that direction. Now
I'm going to be kind of again candid about it,
just as I was with some of the architectural stuff.
Some people don't have the call it presence. I guess
to be in that group and keep control of it.
It's it's kind of an born thing. And so you
want to if you're going to move in that direction,
you ought to you have to have that that inner
confidence that you can talk to people on their level,
even if no matter where they are, that you can
talk to them as equals, listen to them, but also
tell them when you think they're wrong, and work through
disagreements and such. Some people just worry too much about
other people's feelings and so they it's very hard for
them to step into that facilitation role. But if you
can do that, and I don't mean that you have
to be a jerk. I don't feel like I'm a jerk,
for example, but you do have to be able to
challenge people this. That's a phrase, just a free tip
for people who are in this that when they say
something you disagree with, don't say I disagree with that,
Say I challenge that. Notice the different psychology there.
Speaker 1: If I'm not saying I'm.
Speaker 4: Not wrong, you're saying I'm not sure that you're right
about that. So let's let's invot some more discussion of it.
Speaker 1: And it helps to have a sense of humor, Right, Billy.
Speaker 4: I'd like to think so yeah, I think so too.
Speaker 1: All right, well, we've wasted another hour and four minutes
of your precious life. I have always a waste it
was great listening to this lousy show. No I'm kidding,
So thank you, Billy. It's been great as always.
Speaker 4: You're welcome. I got to talk about a lot of stuff.
I was interested in it, and I hope people find
some value.
Speaker 1: I look forward to our next in person meeting as
well as our next dot net rocks meeting. So thanks
again and we'll talk to you, dear listener next time
on dot net rocks. Dot net Rocks is brought to
by Franklin's Net and produced by Pop Studios, a full
service audio, video and post production facility located physically in
New London, Connecticut, and of course in the cloud online
at pwop dot com. Visit our website at d O
T N E t R O c k S dot
com for RSS feeds, downloads, mobile apps, comments, and access
to the full archives going back to show number one,
recorded in September two thousand and two. And make sure
you check out our sponsors. They keep us in business.
Now go write some code, See you next time.
Speaker 4: You got Ja met Van
Speaker 1: And