All Episodes

July 3, 2023 62 mins
EPISODE DESCRIPTION:
Pragmatic and Agile Programming are about as essential to and foundational as it comes when being a software engineer. But for tips and concepts written over 20 years ago, how much have Pragmatic & Agile Programming changed in our modern world with greater diversity and new tech such as AI? How much has stayed the same?

In this Dev Life edition of the Angular Plus Show, we’re joined by author Andy Hunt of the Pragmatic Programmer & Agile Manifesto to get his direct insights into what it means to be a Pragmatic Programmer today and how teams and individuals can reach their maximum potential. Line your your rubber duckies up in a row and get ready! This is… The Dev Life!

LINKS:

https://twitter.com/PragmaticAndy
https://toolshed.com/
Pragmatic Programmer Twitter
https://pragprog.com/
https://agilemanifesto.org/
https://growsinstitute.com/

CONNECT WITH US:
Andrew Hunt - @PragmaticAndy, pragmaticandy@mastodon.social
Brooke Avery - @jediBravery
Preston Lamb - @PrestonJLamb

Follow us on X: The Angular Plus Show
Bluesky: @theangularplusshow.bsky.social  

The Angular Plus Show is a part of ng-conf. ng-conf is a multi-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. Developers from across the globe converge  every year to attend talks and workshops by the Angular team and community experts.

Join
Attend
X
Bluesky        
Read
Watch

Edited by Patrick Hayes
Stock media provided by JUQBOXMUSIC/ Pond5
Mark as Played
Transcript

Episode Transcript

Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:09):
Pragmatic and agile programming are about asessential to and foundational as it comes when
being a software engineer. But fortips and concepts written over twenty years ago,
how much have pragmatic and agile programmingchanged in our modern world with greater
diversity and new tech such as AI? How much has stayed the same.
In this Dev Life edition of theAngular Plus Show, we're joined by author

(00:32):
Andy Hunt of The Pragmatic Programmer andAgile Manifesto to get his trecked insights into
what it means to be a pragmaticprogrammer today and how teams and individuals can
reach their maximum potential. Line yourrubber ducky's up in a row and get
ready. This is the dev Life. This episode is sponsored by this not

(00:53):
Labs, a framework agnostic JavaScript consultingfirm. Our experts provide industry leading engineering,
architectural and training services to enterprises aroundthe world. Let us help you
reduce technical debt, improve your productsand services, upscale your teams, and
promote longevity and scalability within your systems. Learn more in request to complimentary codebase

(01:15):
audit at dolabs dot com or byfollowing us on Twitter at this Dot Labs.
Hey Preston, Hey Brook, how'sit going. It is June.
Things are going well. But hello, Andy, it's nice to have you
with us. Hello, thanks forhaving me. Yeah, So I have

(01:38):
to tell you I've been trying tofind some new music lately. I've found
some really great stuff. But Ijust discovered some stuff lately from a group
called Strange and Special Air Productions.Have you heard of them? By chance?
So Strange and Special Air is myrecord label actually, and under that

(02:00):
labell, I've got a couple ofdifferent bands that I play with, including
Cyanob which does sort of electronica ambientkind of stuff, Independent Memes, which
is more of a cross between say, maybe Steely Dan and Pink Floyd kind
of prog rock sort of thing.Art Event for classical, and the Flugal

(02:22):
teenis for jazz. Nice. Sowe're people can't see this, Our listeners
can't see this. But you're sittingin a studio and you have I can
see two keyboards of some kind.One looks like even like a double layer
keyboard. What instruments do you play? Synthesizers? As you see, I've

(02:43):
actually got four right here in thestudio. I've got another couple in my
mobile rig back at the house,and brass instruments, mostly trumpet and flugel
horn, which not a lot ofpeople know, and invariably they ask,
what's a flugel horn. It's it'slike trumpet, but it's got a bigger
bore and a conical boar, soit's got a more mellow, you know,

(03:07):
kind of a jazz sound of ChuckMangione was well known for playing a
flubahorn back in the seventies. Ruston, I think you said you play the
piano, right, That is agenerous description of it. I took some
piano lessons growing up, and Ican kind of play a few songs.

(03:29):
I wish that I had stuck withit a little bit more growing up.
And now my life is kind ofcrazy, so I don't find a lot
of time to sit down and play. But when I do, I always
I always enjoy it. But yeah, one of my bucket list items in
life is I really want to goto a great jazz club, like somewhere

(03:52):
in New York, just like aI don't know. You see him on
movies sometimes and I just think itlooks like a lot of fun to be
as awesome jazz club. But haveyou ever been to one at all?
Andy, Have you ever gone toa club and just kind of jammed out
to some jazz absolutely, um,and there there's a there's a couple,
there are fun that's It's probably notthe best jazz club I've been to,

(04:14):
But definitely a shout out to Andy'sin Chicago, because hey, I'm Andy,
right, So Andy's Jazz Club.Every time we go to Chicago,
I tried to make a point togo there because They've got nice T shirts
that have an Andy's logo with acouple of like nineteen twenties you know,
hipsters on it. Um. SoAndy's is great. And then back in

(04:34):
the day here in Raleigh, therewas a place called Kapper's. It was
just, you know, sort ofthis hole in the wall, no name
place in the middle of a stripmall. But they had some really big
names go through and you know you'reliterally sitting at a table like three feet
away, and you know the artistwould come down and chat with you,
and you know you can get theirautograph if you want, a fan boy

(04:56):
or fangirl on them, um,that sort of thing. And I I
really like that approach of having thatkind of intimacy with an artist that you
like and follow, as opposed toyou know, seeing The Who or the
Rolling Stones or you know, somemega act in a stadium with one hundred
thousand of your closest friends. Imean, that's fun too, but that's

(05:18):
a very different, you know,sort of experience. Yeah, yeah,
definitely. Well, it's fun tolearn about all of your musical talents.
And by the way, you arealso a published like science fiction author as
well, so very talented person.But truly an honor to have you on
the show with us today, Sothank you for being here. We've been

(05:40):
looking forward to this for a while. We do want to discuss the pragmatic
programmer and the Agile Manifesto, butwe thought it would be interesting to not
just talk about those topics, butto talk about how it's all changed and
how you feel like your ideas andinsights have adapted over the last twenty years

(06:00):
or so. So it'll be reallyfascinating just to get your insights on when
you initially came up with these ideasversus how you think it's changed in today's
world. But we always like toget to know our guests a little bit
more and play something of a game, or just ask a question of some
kind. So today we thought it'dbe fun though that, since it's now

(06:23):
been twenty four years since the PragmaticProgrammer was first released, if we each
went back and discussed what we wereinto twenty four years ago. We are,
yes, all that we're old enoughto be able to do this now,
but just like what worked some ofthe gadgets or technologies that you were

(06:45):
really into or using. And thiswould have been nineteen ninety nine, so
just to give you some context,but yeah, I was thinking about this
earlier, and I think if mymath is right, I think I had
just finished fourth grade, and solike some of the electronics and some of
the stuff that I would have beenplaying with at the time was probably the

(07:08):
Tomagotchi's, I remember those were reallypopular about that time. And then I
remember we had a game Boy Colorso played some game Boys, and probably
had the PlayStation one at that timethat we played video games on. But
I'm not like a huge video gameplayer, and I pretty rarely used the

(07:29):
computer, so I know we hadone, but we didn't use it very
much. I don't remember using itat all till probably like eighth or ninth
grade, like recreationally, maybe sometimesfor school, but so yeah, that
was kind of what I was doing. Yeah for me, I guess I'm
just a little bit older than you, Preston, but kind of the same

(07:53):
things. Tomagotchi, definitely the PlayStationand game Boy. As far as computers,
though, I remember that being aboutthe time that like instant messaging was
coming out and Napster. Napster wasreally big, so there was no such
thing as YouTube back then. Thatmay be weird to some people, but
there was no such thing as YouTube. So to get your music, you

(08:15):
had to go to Napster, andit was all like not approved, right,
Like you were not supposed to bedownloading music and using Napster, So
it was all kind of like onthe downlow, I guess you could say,
but that seemed to be what Iwas. I was really into just
getting into music, just you know, that's about the age when you're just
sort of discovering your own taste inmusic aside from what mom and dad and

(08:37):
big sister and big brother like.So I just remember being really into music
and instant messaging wasn't really a thing. There was no such thing as slack.
There wasn't like Google meets, andso a lot of it was just
like instant messaging. Text messaging wasnot really a thing. Hardly anybody had
cell phones at that point. So, yeah, it makes me feel so

(08:58):
old, and those were kind ofthe things I was into. Oh boy,
you guys make me feel really oldnow, all right, so I
gotta I gotta confess a few thingshere. Um So, by by by
around the turn of the century,say nineteen and two thousand and one ish,
I had been um programming commercially formoney for almost twenty years. Um

(09:20):
So that was twenty some years agonow, so I've been programming from was
forty years total. Um So aroundthe turn of the century, As you
guys mentioned, right, the netwas new. This was all very new
to everyone, and so, asluck would have it, I actually had
my own data center in my houseat the time. I had a full

(09:41):
size rack with its own air conditioning, and I ran This seems incredible today,
right, But I had my ownname server, I had my own
mail server, my own web servers, each on a dedicated box. I
had a couple of development rack mountdevelopment computers UH Lennox and Windows on a
KVM switch, so you could swapyour monitor and keyboard to any one of

(10:05):
the systems in the rack and I'dbe out in the office, you know,
out in the room um and switchyou know, you know, between
them, depending on what sort ofproject I was working on as a consultant.
And you mentioned Napster, I hadwind one Windows box that was dedicated
to playing MP three's no because Icould so, and so that was I

(10:26):
mean, that was a very differenttime, right, because you didn't have
AWS, right, there was nothere was no Google. We had alta
Vista for search. Um, youknow, you didn't have a lot of
the things that you have now.And you could get somebody to host you
know, your your name server,your DNS, your mail server, or
your web servers. But it wasat the time kind of hard to set

(10:48):
up and kind of expensive, tobe honest. So you know, I
got a couple at the time,like cheap four eighty six is um that
were you know, somebody was dumpingand Rack mounted them and use those as
as Linux space web servers at thetime. So the idea of kind of
doing that all yourself is really wild. You know, you don't even think

(11:09):
about that level of infrastructure today.Right, that's just all it's all in
the cloud. It's it's a configfile at best, you know. But
this was this was actual hardware withactual air conditioning. You know. I
built out a corner of my officewith two by fours some sheet rocket at
a miniature closet sized data center.All right, so needless to say,

(11:31):
you were achieving things a bit moreimportant than playing with Tomagotchi and your PlayStation.
But all right, so thank youboth for sharing. Always fun to
learn about about our guests, butthat one was particularly fun, just because
it's fun to see how things havechanged so much and really not that not

(11:52):
that long of a time. Soyeah, but let's get into this.
I want to get into the PragmaticProgrammer, the Agile manifestos. Let's do
this. Yeah, so Andy,like we've been saying, first of all,

(12:13):
we're very excited to have you hereand very grateful for you to take
some of your time. But Brickkind of mentioned this earlier, that we
wanted to talk to you a littlebit about the Pragmatic Programmer, and you
first published that back in nineteen ninetynine, but since then you've gone on
to publish many other books like ProgrammingRuby, Pragmatic Unit Testing, Learned to

(12:37):
Program using Minecraft Plugins, and thena few novels as well called Weatherly Hall.
I think I'm pronouncing this right,but Conglo Moura and Conglo Moura Found
and then as we talk about earlieras well, you also enjoy playing a
variety of instruments and contributing as aprogrammer, a consultant, and a speaker

(12:58):
across the US and Europe. Soyou've been very busy over the course of
your career, and I think thatyou've probably helped shape software development quite a
quite a bit with some of thework that you've done. So you mentioned
just a minute ago that you've beenprogramming for about forty years professional year.
So so how did you get intoprogramming and what are some of your earliest

(13:22):
memories of coding. So, theone of the very first things I remember
writing on my first computer, whichwas a sixty five zero two based system
with maybe four K of RAM,maybe eight K. I may have sprung
for the extra board to get theextra four K of RAM. I mean,
right, you know, I meanI get people with email signatures that

(13:43):
are bigger than that, right,But that was all we had, and
it was it was assembly language,maybe a little c basic later on,
but the very one of the veryfirst things I remember writing was a word
processor, and I wanted a wordprocess that let you include diagrams in it.
And at the time, yeah,I mean this was very rudimentary,

(14:05):
right, I mean I was,I was, you know, this was
this was back in you know,high school. I guess, um there
was no graphics drivers on the system. It didn't work that way. To
put something on the screen, youbasically wrote an askey character into a special
memory address. It was memory mappedvideo. So if you wanted to put
a capital A on the screen,you would poke a sixty five into this

(14:31):
memory location, you know, Xone thousand or something like that, and
an A would show up up onthe screen. And you could do the
same thing with like like you know, block graphics. If you wanted a
left corner, uh, you knowblock graphic, there was a there was
a code for that, and you'dstuff it in the memory. So one
of the very very first things Iever wrote was a very primitive word process,
so that lets you, you know, move around the screen and type

(14:52):
a document and put um, uh, you know, crude askey graphics,
using these graphic characters in it.And it was really simple because to save
the document, you know, allyou had to do was, you know,
copy that memory off to a placeon disk. But here's the fun
thing. At the time, tosave something to disk, you had to
say what track and sector you wantedto save the data too, and how

(15:16):
long the data was, So youhad to manage your own you know,
disc memory. And I remember whenthe first you know, this was long
before the you know mstos even orWindows um or even the trash trash a
d JRSAD operating system. And whenthose came out, and it's like you
see a disc call, it's like, we'll just give it some memory and

(15:37):
it will figure out where to putit on disks. And I was highly
suspicious, like, what are youtalking about? You know, this thing's
going to figure out where to stuffit on disk. For me, I
was highly suspicious. I'm still suspiciousforty years later, but that's just gotten
worse. But that just gives youan idea of how really, how primitive
things were when we when I firststarted hearted, you know, when when

(16:02):
I was in college, they werejust phasing out of paper, the punch
cards, you know, they'd stillhad like a punch card reader and a
punch card writer, but they werethey were phasing that out, but it
was it didn't really occur to meuntil later, just how early in the
evolution of computing all that really was. It's interesting to me, Like,

(16:25):
I guess, it's just fascinating tothink about how much work it took to
get things just up and running back, like you said, like you had
to be manually putting in all ofthis information and it just goes to show
like how much determination you really hadto have in order to get things to
work. But it makes you gratefulfor how well things work now. But
those are great stories. At whatpoint in your career did you start developing

(16:49):
your ideas for the Pragmatic program orlike, had you been you know,
had you been coding professionally for sometime by then, or was this earlier
on in your career. Yeah,so, the the Dave Thomas and I
started writing the Pragmatic Programmer Book aroundnineteen ninety eight or so, and so

(17:11):
so I'd been you know, inthe industry for what fifteen twenty years by
then, and so these were thingsthat both of us had sort of come
across in our career that we thought, you know, this is really important
and it's not something that you seein a college or university course. You
know, you don't see it inthe Addison Wesley books at the time.

(17:34):
So I had I had actually startedbefore we wrote a Pragmatic programmer. I'd
started a small newsletter and had athing called like Andy's Guide to Oom at
the time, starting to collect tipsand tricks of hey, this is an
important thing and you know we're notseeing it out there, and this is
something people need to know about.So um, you know, it came

(17:56):
out that the whole reason we wrotethe book. It actually started off Dave
and I wanted to just write likea little white paper for our clients we
were consulting at the time, andyou know, going out out in the
world, you know, back backin the pre pandemic days when you could
do such a thing. We wouldgo on client sites and you know,

(18:17):
help them out and you know,sort of coach them through what they were
doing wrong. And what we noticedwas across all of these clients, large
and small, all over the countryEurope, wherever they were doing the same
things wrong. They were misunderstanding thesame things about programming, so we figured,
well, we're just going to writea little white paper so before we

(18:37):
go into a client engagement, they'vegot a bit of a head start saying,
hey, here's the things you reallyshould be doing, and that grew
in to become the Pragmatic program orbook. It seems like the best ideas
usually come from experiences like that,where you don't necessarily set out to write
a book, but but that's whatkind of came out of it. So

(19:02):
maybe for those people, though,who have not read The Pragmatic Programmer,
can you kind of give us alittle overview about what exactly pragmatic programming is
and what that book is about.I'm going to try and keep this short
because we only have so much timeand we still have to talk about agile.
It talks about a bunch of things, but the most important approach,

(19:26):
I think is that these are kindof foundational ideas, tips or tricks,
if you will, but ideas thatare sort of foundational in that it doesn't
matter what kind of language environment you'reworking in. So these are things you
would need to know whether you're workingin PHP or Java or Rust or Elixir

(19:48):
or JavaScript. You know, thelanguage, the framework doesn't really matter.
Even the decade doesn't really matter.I mean we're twenty some years on and
it's the same things, so,you know, and a lot of it's
gotten quoted out in the world sincewe started. So the whole idea of
talking to a rubber duck, rubberduck debugging, right, that came from

(20:10):
pragmatic programmer. Um. And that'sthat's that's become a meme. You know
at this point, right, youknow, you see the rubber duck up
in the terminal. Um, thatwas us right, right. Um.
The dry principle, you know,the idea that any important concept should be
embodied in the code so that there'sonly one place you have to go to

(20:30):
change it. You represent it onceso that when it changes in the real
world, you only have one placeto go and change it. And the
dry principle gets quoted, you know, left and right. Um. When
my son was in college, hephoned the up one day. It's like,
Dad, you were in our coursetoday. It's like, well,
yes, that that's cool, right, you know, but but but that

(20:52):
that happens, um. Actually funny. As a funny side note, when
we first wrote the book back backat the turn of the century. We
use that as a kind of callingcard, going into clients saying, hey,
you know, we're hot stuff.We wrote a book, and within
maybe five years or so, wewould go into clients and we'd see our

(21:12):
book on their bookshelf, and thatwas like why they wrote, right,
and that that's kind to me.That's kind of like when you know,
you know you've made an impact,you know you've sort of made it's like
people know about you. You're ontheir bookshelf. You know, it's become
a thing. But but that's why, because it's not tied to, you

(21:33):
know, some particular point in timewhere this language is popular or this technique
is popular. I mean, alot of the stuff we talk about in
the book isn't particular to object orientedprogramming or functional programming or procedural or whatever.
It's just, you know, thisis kind of how people work,
how information flows work. It's it'syou know, very based level stuff.

(21:57):
And as such, it's the kindoff they don't teach in college or university
or boot camps. You know,they don't have time to kind of get
to these sort of foundational notions,these these sort of ideas, and once
you have an understanding of the kindsof things we talk about in Pragmatic Programmer,

(22:18):
you can use that to solve allkinds of problems that come up in
corporate life. So you know,even if you're working in you know,
one particular language, you know,we might talk. We might talk about
something that's not particularly applicable, butit will it'll make you think and then
you'll solve some problem you couldn't havesolved otherwise. You know, it's interesting

(22:38):
to me because especially at my newcompany. I've had a few different dev
jobs now and this new company atLimbol, it was one of the first
things they gifted to me, actually, to any new developer that gets hired
there, they give a copy ofPragmatic Programmer. It is that important to
our company and to our culture.And oh, bless them. I totally

(23:04):
appreciate that. Thank thank them forme. I will. Yeah, No,
They're an excellent team. I lovemy team, great company. But
I'm just curious, like, whywhy do you think that almost like one
of those like you said, schoolsdon't necessarily have time to teach this,
or boot camps don't have time toteach it. But to me, I

(23:26):
think it's more essential than that.I think it should be something that's included.
But why do you think that is? Why? You know this?
This is something that spans across languagesand framework, So why isn't it something
that's more foundational and essential that hitson a lot of problems with the industry

(23:47):
and our approach to education. Youknow, the problem with boot camps and
things similar things to that is theyreally teach coding. They don't necessarily teach
software develop elopment. And there isa big difference um a lot of colleges
and universities, especially in their computerscience curriculum, they are trying to produce

(24:10):
computer scientists, not software developers.Even if they have a software engineering curriculum,
it's not really as real world asit should be. And from and
I've talked to folks on like theaccreditation boards and curriculum development and stuff,
and most universities are deathly afraid ofbecoming vocational schools or what they consider vocational

(24:34):
schools. So anything that's actually usefulin the real world, like using get
or you know, working in ateam doing you know, test driven development,
these sorts of things, they aredead set against because that's actually useful,
so that that's really not Yeah,they don't feel that's part of their
their remit, you know, they'dmuch rather look at um, you know,

(24:55):
abstract data types and compiler parts,trees and this sort of thing.
So between the two of them,you've got you know, colleges who tend
to aim I guess, sort ofup market. They assume you're going to
teach or become a researcher. Andthen you've got boot camps who go kind
of low market, assuming all youneed to do is make it, make

(25:18):
it compile under PHP or Java orJavaScript or what have you. And there's
the middle of the actual professional softwaredevelopers who are not being served. Right.
It's sort of assumed that well,you guys will learn it out in
the world, maybe if you're lucky. But you know, the kind of

(25:38):
the traditional educational environments really don't addressmodern software development. You know, it's
shocking to me that even in almostevery computer science curriculum I've seen, and
maybe this has changed in the lastfew years, but from what I've seen,
they don't teach things at all likeGET or unit tests or TDD or

(26:00):
pair program or mob programming, youknow, it's like, this is the
stuff that actually works and makes ahuge difference and what you need to know
to be able to function in amodern software team, and they don't even
know how to spell it. Yeah, I can attest to that. UM.
I graduated from Utah State University witha computer science degree UM, and

(26:22):
we had a software development emphasis,kind of like you mentioned, but we
didn't do anything with with any sortof version control. I think we might
have barely touched on some some unittesting practices, UM, but we did
very little of that. And Ihave told my parents before, and I

(26:47):
have a couple of brothers who wentto boot camps and UM, and I
agree with what you said about howpeople are taught in boot camps, but
I think that at the very leastin my experience, I see my brothers
who came out of boot camp,and they were at least more prepared to

(27:07):
go get a job than I waswhen I left college, other than I
was lucky enough to I got ajob on a software development team at the
university where I was working and buildingsome little websites and some little web apps
with some professional developers who kind ofhelped me. But if I hadn't had

(27:29):
that, I like, I thinkit would have been kind of hard to
find a job doing what I'm doingnow because I just didn't really feel like
I was that prepared for it throughmy university classes. So it is kind
of an interesting conundrum that we havein education. In the old days,
you know, say even maybe tenyears ago or more, it didn't matter

(27:53):
that much. Maybe particularly it's like, Okay, well this is a problem,
and you know, we'll fix itsomeday. But times are different now.
I mean, software has eaten theworld. Every company out there is
a software company, whether they knowit or not, and so this has
become critically important. And yet whatyou have is these, especially the large

(28:14):
companies, You've got these incredibly inefficient, ignorant software teams that are putting out
stuff mostly based on luck. Well, okay, so I'm loving this because
we've established really how essential and howlike you said, foundational these ideas are
with the programndic programming. But thenwhat is agile? Can you explain that

(28:38):
for our listeners as well? Inmy opinion, almost nobody out there actually
understands it. And in one way, that's that's really sort of frustrating on
the plus side. You know,agile became a huge buzzword. Everyone has
heard of it, everyone thinks theyknow what it's about. There is actually

(28:59):
a plaque in Salt Lake City atthe hotel where we all met back in
two thousand and one and came upwith the Agile Manifesto. There's a plaque
at the hotel commemorating the event.So you know, I tell my kids,
yes, well, if nothing else, at least I'm on a historical
plaque. So you know, there'sthat. That's something when people tell me,
oh, yes, we're agile,and then they describe what they do,

(29:22):
they say it boils down to weuse Jarrah and we do half of
scrum badly, right, And ninetypercent of people who think they're agile kind
of fall into that category. Sothe very first point I want to make,
and make strongly, I can't possiblymake the strong enough. Scrum is

(29:42):
not agile. It's not even agood example of agile. Scrum is a
lightweight project developed project management methodology.That's all it is. And you know,
Schwaber and them all say can't workwithout solid technical practices underneath it.

(30:03):
So their vision when they invented scrumwas you would have something like Extreme Programming
XP underneath it, where you didTDD, where you did pair of programming,
where you did you know, thesesorts of technical practices, and that
message got completely lost. The wholepoint of agile and its emphasis on feedback

(30:25):
got lost. And you know,I've seen people do stand up meetings that
you know in scrum that last threehours and they become status report meetings to
leadership. That was that's not howyou do it. That's not the idea.
So back around um gosh, whatyear, probably around twenty ten,

(30:45):
twenty twelve, I'd have to lookit up. I wrote a book called
Practices of an Agile Developer with mygood friend Ven Kit's Supermuney and Vin Kit
and I. We're working on thebook and realized that at that point,
well even now, no one wedidn't make a definition of what agile was.
So I came up with this thatwe used in the book that said,

(31:08):
agile development uses feedback to make constantadjustments in a highly collaborative environment.
You can write that down, youcan needle point it. That's what agile
development is. It's all about feedback. It's about constant adjustments, not adjustments
every two weeks or every six months, or when you get around to it.

(31:30):
In a highly collaborative environment, thatmeans you talk to users. Users
are sitting in on the team.The team makes the decisions. You have
constant feedback. You are checking intoMaine multiple times an hour, not into
a long running feature branch, notusing these crap pull requests, which is
our disaster. But that's a wholeother story. But it's all about fast

(31:55):
feedback, fast adjustments. You know, somebody early on, and I wish
I could find the reference. Butback in the early days, somebody made
the analogy that agile programming, andindeed successful programming of any sort, it's
like you're in a cave, avery large cave with a very small flashlight.

(32:15):
You can go kind of slowly andpoke your toe out ahead of where
you're going, or you can runheadlong towards the wall. And what do
you think is going to happen whenyou run headlong? Well, you're gonna
fall off a cliff, you're gonnafall into a stream. You're gonna die.
But you poke your toe, youmake sure it's safe. You go
onto the next place. You pokeyour toe. You make sure it's safe,
you go on to the next place. That's what it's about. That's

(32:37):
why we use things like TDD.That's why we use things like pair programming
and mob programming or ensemble programming asthey call it. Now, you know
this idea of very small feedback cycles, constant adjustments, talking to everybody,
not going through a committee. I'veseen agile companies that have a change control

(33:00):
board. What the hell is that. That's insane. That's abs literally,
that's that's bedlam. I mean,lock them up. That's just nuts.
And unfortunately it's very common. UmSo, yeah, a little bit of
a hot button with me, butit's you know, it's all about taking
very small steps and getting feedback everystep of the way. You know,

(33:22):
you write, you write a bitof code, You have the test that
says what it's actually doing, notwhat you want it to do. You
get something, you know, builtup at a feature level. You put
it in front of an actual user, not a product owner or some you
know, high stuffed flutant whatever,but somebody who was actually going to use
it and say, hey, doesthis work for you? Why or why
not? You know, what canwe even do different? That's what it's

(33:44):
all about it's not that hard,but the message of agile got so corrupted
and so, you know, overwhelmedby the existing organizational antibodies. There's like,
well, that's fine, We're basicallygoing to end up doing exactly what
we've always done, but now we'regoing to call it agile. And that's

(34:05):
what safe is. I you know, safe is just the crappiest thing on
the planet. I actually have acouple of friends who are making good bank
by going around and cleaning up failedsafe adoptions. Safe if you don't know
it, Martin Fowler says safe standsfor shitty agile for enterprise, which I
believe that's the official definition. Ihaven't heard anything any better. So that's

(34:29):
interesting. It is. It's funnybecause I have worked at a couple of
companies where you said, usually whatcompanies mean when they say they're agile is
that they're using Gira and stuff likethat, and that's kind of what it
was, and so and I've seenlots of people talk about that on Twitter,
that like, people aren't really doingagile even though even though they may

(34:54):
think they are so. So aspart of your work in this a workspace
and helping people understand it. Youwrote the Agile Manifesto, and it's not
too long, so I'll HEARDing readit real quickly for those who may have
not heard it before. It says, we are uncovering better ways of developing

(35:14):
software by doing it and helping othersdo it. Through this work, we
have come to value individuals and interactionsover processes and tools working software over comprehensive
documentation, customer collaboration over contract negotiation, responding to change, over following a
plan. That is, while thereis value in the items on the right,

(35:37):
we value the items on the leftmore so. This might be kind
of hard, but can you kindof explain to people what you mean from
this Agile Manifesto what it means overall? I'd be delighted to And it's not
that hard. It's actually not rocketscience. It's actually pretty simple. The
two most important lines in the portionthat you cited there are the very beginning.

(36:01):
We are uncovering better ways developing softwareby doing it. This is not
the ten commandments written in stone fromon high. This is not the end
of how to develop software better.This was seventeen guys, and there were
guys, you know, old whiteguys. Seventeen of us got together and

(36:22):
said, all right, here's whatwe have figured out at this point in
our careers. And an important notehere, right, So, as I
said so, by the time aboutthe manifesto, I'd been in the industry
for about twenty years. I wasone of the youngest people, if not
the youngest people, the youngest personin the room. These were all highly

(36:43):
skilled folks. They'd been there,they'd seen it, they'd done it.
They knew where the pitfalls were,they knew what worked, they knew what
didn't work. That was the bestpart about this group that got together,
and so we came up with thislist that what was important individuals and interactions,
working software, collaboration, responding tochange. Now, because there was

(37:07):
seventeen of us, there was abit of a committee effect happening here.
And that's where you get these sortof pardon me bullshit phrases like that is,
while there's value in the items onthe right, we value right nonsense?
All right, who forget the right? Right? I mean, for
a first level approximation, just considerthat the stuff on the right is basically

(37:27):
evil. It has its place andthere you know, it's not completely evil.
There's times where you need that.But for the most part, just
pretend that the stuff on the rightis hot, flaming garbage, and what
you want is the stuff on theleft, and of the stuff on the
left, you can ignore almost allof them and focus on the first one.

(37:49):
Individuals and interactions. That's the game, and that's where we have failed
because we instead of working tree eatingindividuals as individuals. You know, Mary
is Mary, She's not the productowner or you know some other title.
Right. Anytime a team form,it's their first questions are, well,

(38:10):
what tools we're going to use?What process are we're going to use.
It's all about Jira, It's allabout rally. It's all about you know,
you know, any of the toolsthat are out there, and the
particulars of the process. You know, how are we going to do pull
requests, how we're going to dofeature branches, blah blah blah rubbish.
It's about individuals and their interactions.Hey, Sam is a power user.

(38:32):
When can we get Sam in totalk to them and and you know,
work with them and do this stuff. It's all about people and interactions.
That is the number one most importantthing. And the you know, sort
of organizational antibodies and organizational processes absolutelystomp on that because they want everything to

(38:57):
be repeatable. They wanted to bea repeatable process, so you can just
throw a six pack of developers inand pump software out the other end.
It does not work like that.It has never worked like that. It
will not work like that with AI, it will not work like that with
delithium crystals. Whatever, it doesn'tmatter. It is always about people.

(39:20):
Jerry Weinberg, you know, famousearly author, you know, really a
foundational author, sort of on thelevel of Fred Brooks, you know,
Diichster, that sort of thing.He claimed early on that there are no
technical problems, they're all people problems, and he was absolutely right. So
the very first item here is individualsand interactions over processes and tools, and

(39:45):
literally until we get that right now, it doesn't even matter about the rest
of it. I mean, therest is sort of gravy. It'd be
nice, yeah, we'd like workingsoftware, we'd like collaboration, yeah yeah,
but it really comes down to individualsand interactions. And we have not
gotten that right yet. We havenot internalized that as an industry, as
a prosps, as a method.You know, we're not there yet.

(40:08):
Oh yeah, I definitely agree withthat, and I see it even with
things like with interviewing and getting anew job, just how I feel like
the industry doesn't put enough emphasis onthe individual. It seems like it's more
about just solving algorithms than it isabout the individual and what you can do,
what you can contribute to the company. But you mentioned the manifesto was

(40:34):
written by seventeen white guys, andso you know, going back to that,
like, let's dig into how doesit apply then to an industry where
there's an increasing amount of women anddiversity, and what do you think that
it looks like today. How hasthat changed over the last twenty four years

(40:54):
or has it not? But howcan it still be applied? And really
what should companies be doing to betterfocus on the individual. That's a good
question. The problem is you reallyhave to you have to view software development

(41:15):
more like making a blockbuster motion picturefor instance, right, And there is
a certain amount of craft to that, Right. You have specialists who can
do the CG effects and the lighting, the cinematography and whatnot, and that's
you know, there's an art tothat, but there's also a lot of
sort of mechanical process to that youdo this, you do that, you

(41:37):
do the other thing. Okay,that's fine, But what makes a stellar
blockbuster movie versus just another CGI effectsreel? Right? It's the script.
It's the writing. And you know, does any Hollywood studio have a proven
formula to develop a blockbuster script?No. Marvel started off really well.

(42:00):
They had you know, some reallyfine scripts early on in their in their
blockbuster pipeline, and then they kindof lost the ball a bit. M
d C Comics with their superhero movies. Really never never got the script part
right. You know, they workedon the effects, they had all the
other stuff, but they couldn't getthat sort of magic ingredient um right.

(42:23):
And I think that's a really goodanalogy because the thing is, how do
you productize writing a script? Right? You can't really, because it's a
creative act. It all depends onthe personalities and the experiences of the writers,
the writer's room, you know,this this sort of thing. It's

(42:45):
not repeatable. It's you've got,you know, somebody who can write excellent
dialogue, like a say an AaronSorkin maybe who did you know? West
Wing and the social network things likethat, right, can write some very
witty, very fast, very veryinteresting dialogue and you can see the big
studio saying, well, it's great, let's have twenty of him. Well,

(43:06):
it doesn't work that way, right, You can't just copy and pace
creativity, you know, that's particularto this, this one particular person,
and that's how we get back tothe whole individuals and interactions thing. Right.
We're not doing the the CGI effects, if you will, We're writing
the script. And this, Ithink is the big disconnect, because being

(43:30):
software is about writing, right,It's closer to writing an essay or writing
a script, or writing a narrative, writing a story than it is you
know, some mathematical pursuit or someproduction pursuit. You know, well,
we're we've got the scalability versus viaKubernetes and all this kind of crap.
Yeah, that's all lovely. That'sthe engineering side of it. But it's

(43:52):
the creative side of it that's theimportant part. And creativity in general is
just not very well understood. Youknow. This is something that cognitive scientists,
neuroscientists study and we've got a lotof interesting ideas on it, but
it's not repeatable. It's not somethingyou know. You know, we can
teach some techniques, we can wecan offer some advice, but at the

(44:14):
end of the day, it comesout from, you know, a very
unique, particular confluence that expresses itselfin this one person or this set of
people. And that's what we don'tharness or don't honor, because corporate America
wants software development to basically look likea Plato machine where you throw a bunch

(44:37):
of Plato in the side, turnthe crank and this extruded form comes out
the other side and you can shipit. But it doesn't work that way,
and it's never worked that way.But this is the big misconception that
we're sort of up against. Andthat's that's very interesting. I had not
really thought about software development in thatway, and so you've got me sitting

(45:00):
here just thinking a lot as Ilistened to you talk. So my job
is done, I can take offfor the rest of the day. Well,
I think that a lot of peopleare I think a lot of people
are going to be the same,and so I'm really excited for people to
hear this and hopefully as we heartalk like this, and if people can

(45:25):
you know, hear that and reallylisten to it, maybe we can start
to make some of these changes thatyou've talked about. Yeah, So,
are there any anything in the fromthe book from Pragmatic Programmer, but specifically,
like in the first chapter you talkabout thirteen tips for being pragmatic and

(45:45):
finding success in your career. Doyou think that any of those tips have
evolved or at least your your viewon them have evolved over the past twenty
five years since you wrote the book. That level of chip, you know,
things like um, you know,investing regularly, your knowledge portfolio,
you know, continuous learning, thinkingabout quality up from this sort of idea,

(46:12):
they're all exactly the same as theywere ten years ago, twenty years
ago, forty years ago, becausethe tech has changed, but people haven't.
We're the same species that we weredecades ago, and we'll be decades
from now. So that level oftip is exactly the same, exactly as
applicable now as it will be twentyyears from now in the age of you

(46:35):
know, AI and lithium crystals andwarped cores and you know, whatever else
might come along. We're still thesame as people, so that part doesn't
change. That's still just as importantas it was, you know, before
one. A bunch of things thatdid change. So Dave Thomas and I
just just last last year, YearBefore Last released the twentieth anniversary of the

(47:00):
Pragmatic Programmer, and we had toanswer that question exactly. It's like,
well, you know, let's goback and change what needs to be changed.
And the bulk of what we changedwere mostly technological references. You know,
we would refer to nifty new experimentallanguages like Eiffel. Nobody's heard of
Eiffel these days, right that thatit was, it was interesting, it

(47:22):
had a place in history, butit died to death. So we replaced
that with modern interesting languages like rustor um hillickser, that sort of thing.
So there were there were technological changes. Most of the people's stuff,
like I said, we left alone, but we had to add some things
that we didn't have to worry abouttwenty years ago, mostly about concern about

(47:45):
adversarial users and you know, uh, state actors and you know, you
know, actors trying to break intoand take advantage of your software and using
it to hurt people. Um,you know, sort of the ethics ethical
considerations of your software. We werenot evolved enough as a community as a

(48:07):
profession. Twenty years ago, thatwasn't as much of a concern, and
obviously today that's a huge concern.Right if you're writing some you know,
social media software, that's us itused for genocide in some part of the
world, or used to you know, rat out journalists and have them killed,
or you know, any of thesesort of evils that you you know,

(48:29):
you read about in the news.We're responsible for that, but that's
on us. We've provided that capability, and that's something we need to really
be aware of. UM. Backin the day, it was a little
more straightforward. It's like, well, you know, I'm working for you
know, software that launches nuclear missiles. Okay, well that's you know,
pretty straightforward. You can make anethical decision that that's that's something you want

(48:52):
to do or not. But thesedays it's a lot more complicated. Um.
There are a lot more threat actorsinvolved. Anything you put on the
web, everybody's going to get inand try to break in, try to
circumvent it, try to use itfor ill needs. And that's a very
different environment and it's something that againnone of this is taught in colleges,

(49:15):
university. Maybe if you've got asecurity minor, or you're taking a specific
security boot camp. But for themost part, this is something that most
developers aren't really aware of and absolutelyneed to be That's probably, I think
the most important thing that has changedin the last few years, simply because

(49:37):
software is now so ingrained in ourculture, in our work, in our
lives. You know, it isinescapable. You know, I don't know
if you really realize, but likeso many things you need to do these
days, just to be a participantin society, you have to have a
smartphone. You just have to.You know. That's how you get your

(50:00):
tickets to see the show. That'show you get your your COVID appointment,
that's how you get you know,you pay your taxes, you know,
whatever it might be. It hasreally become a requirement to be a functional
citizen. And that's a pretty bigstretch from you know, even ten years
ago. I really like that whereyou're pointing out how so much of the
pragmatic programmer really hasn't changed and won'tchange because it is about the people rather

(50:24):
than the tech. So but let'sget into the how. Then I'm tying
this into my current position, mycurrent company, I have to go back
to my company and really give thempraise because when I compare it to the
other jobs I've had. One thingthat Limbol does really well is the humanize
things, and it goes back towhat you said earlier, where it's focusing

(50:45):
on the individual, and I feellike that has helped me to do a
lot of the things that when Iread Pragmatic Programmer, it just naturally falls
into place when when my manager showshis passion, when he shows interest who
I am, and when I'm givena little bit of space to just be
Brooke, be me, I feelmore invested in the company because they're showing

(51:07):
interest in me as a person andthey're also interested in my outside skills.
It's not just what programming skills canBrook do or not do, it's what
else does she have? What elsecan we have her show and share and
contribute to the team, to thecompany. That's when I get more passionate.
That's when I want to sit downand even after hours, go and

(51:30):
plug away at the computer because Ifeel I feel that same passion, I
feel that same interest. So thatgoes back to that question of how do
you Andy, how do you feelthat companies can't effectively do everything that you've
shared on the episode today where we'refocusing on the individual and not just getting

(51:52):
lost to tools and processes and thetech, but actually on the individual.
So isn't it fascinating that everything youjust described is the first line of the
manifesto? Individuals interactions are more important, and absolutely is. And a big

(52:13):
part of that, I think,um, is you know, as you
said, corporations really want to tryto dehumanize things because we have this sort
of industrial age mindset that everything shouldbe a factory, you know, production
line, and that was you know, maybe true in the industrial age.

(52:35):
But we are not in the industrialage anymore. We're in the information age,
or some may say the disinformation age. But that's an entirely another that's
a whole another hour long podcast.We'll get to that later, um,
But in the information age, right, it's it's it is about humans,
and it's about all the you know, the wide range of our experience and

(52:58):
our intuition and our learning. AndI think this is probably a good quote
to end on the important part isyou have to be a continuous learner and
the company has to support the notionthat everybody is a continuous learner and that
you need to learn. The lackof learning opportunities in corporate America is just

(53:23):
devastating. Programming is all about learning. It's about you're learning the requirements.
You're learning how your TeamWorks, You'relearning how the system under development begins to
react and act. It's all aboutlearning. And yet most companies are dead
set against that. They don't wantyou to learn anything. You're just a

(53:44):
cog, dehumanized cog in the machine. So there's this great quote from THH.
White in the book The Once inFuture King where Merlin is teaching young
Arthur, Arthur who will grow upto become King Arthur of Legend, and
it goes the best thing, repliedMerlin, is to learn something. That's

(54:07):
the only thing that never fails.You may grow old and trembling in your
anatomies. You may lie awake atnight listening to the disorder of your veins.
You may miss your only love.You may see the world about you
devastated by evil lunatics, or knowyour honor trampled in the sewers of baser
minds. There is only one thingfor it, then to learn, learn

(54:30):
why the world wags and what wagsit. That is the only thing which
the mind can never exhaust, neveralienate, never be tortured by, never
fear or distrust, and never dreamof regretting. Learning is the only thing
for you. Look what a lotof things there are to learn. It's

(54:51):
true, I mean, it's obviouslytrue for individuals. That is part and
parcel of our mission as developers iscontinuous learning. But what we're missing out
on is that's also part and parcelof what an organization needs to do.
The team needs to learn continually.The organization needs to learn continually, and

(55:13):
that's the missing ingredient. Um.That's the sort of stuff I've been I've
been working with my friends in growsmethod, grows method dot com, and
that's the kind of stuff that we'vebeen looking at. To answer your question,
what you know, what do wedo to get around this is to
reemphasize the idea of you know,individuals as individuals not cogs, and emphasizing

(55:38):
this, you know, understanding thatDryfuss model of skill acquisition, understanding systems
thinking, understanding this need to focusto centralize on continuous learning. That's really
I think the only way out.When you say that it should be more
of an emphasis, what does thatlook like to you? Um, it's

(56:00):
everything. I mean certainly, youknow formal courses on some new tech has
has its place, has its meaning, but it also means just you know,
well, this is curious, thisis strange. Let me write a
prototype, let me play with that, let me explore that, let me
experiment with that. One of thethings we do with the Grows advice is

(56:22):
try to promote the idea that experimentationshould be a first class part of any
method because for these sort of softwaresystems that most people are developing, the
reason we're developing is because it's neverbeen done before. If it's been done
before, we shouldn't be writing it. We should be buying it off the
shelf. There's the first thing.And if it is something novel, then

(56:45):
this is an exploratory missision, right. And yet you see companies saying,
well, you know, it's it'slike Lewis and Clark going across the US,
you know, leaving in January,like, well, we want to
know where you'll be on the twentysecond of June. Who knows, right,
I mean, you have no idea, you're going off in unexplored territory.
That's like the whole point. Sowe have that that wrong attitude,

(57:09):
that wrong approach. So what companiesneed to do, what that needs to
look like, is saying, allright, well, you know, we
are going out on the surface ofMars. We're going out on an alien
planet. We don't know what we'regonna find, but here are the things
we're going to experiment with. Here'sthe things we're going to explore. And

(57:29):
everything we explore, every prototype wetry, we're going to learn from it.
Well, this worked, that didn'twork. Let's pursue this a little
bit more. Let's pursue this otherthing. But this idea, it goes
back to that, you know,that central notion of constant feedback. All
right, we don't know the answers. We're running through that cave with our
tiny flashlight. So we explore,we try, we try this, we

(57:52):
try the other thing. That isthe I think the central paradigm that we
need to embrace, because what happenswhen you're experimenting with these things and you're
trying these different things, you're learningfrom it. The whole exercise of fast
feedback, the reason we do TDDis to learn. The reason we do

(58:14):
pair programming is to learn. Thereason we have a user, an actual
user in front of us, isto learn. That's the central paradigm,
and that's what we're missing. Ithink, well, thank you so much.
This has been great. Like Isaid, I've learned a lot sitting
here listening. I'm excited for usto get out there before we wrap up.
Do you have any other final thoughtsor advice that you want to share

(58:35):
with our listeners? Just one inthe in the in the show notes you
sent me, you you'd ask aninteresting question about you know, what can
you do to make make these practicesthat you read in things like Pragmatic Thinking
and Learning or the Pragmatic Programmer orthe edge of you know, what can
you do to actually have them becomehabits? And the best advice I give

(58:58):
there for anything, if you wantto play a musical instrument, if you
want to learn a new programming language, you know, whatever, whatever you're
involved in, is this notion ofdon't break the chain. So set aside
some time every day, half hour, twenty minutes, an hour, whatever
you can afford to work on.Whatever this project is, that you want

(59:19):
to embrace and mark off on aphysical calendar every day that you do it.
The idea being don't break the chain. Just touch it every day for
however long it is. Our brainsare sort of like dynamic ram. You
have to refresh it every so oftenor it just falls off the edge.
So anything that you want to committo that you really want to do,

(59:42):
you know, do it every day. Doesn't matter how long. But just
touch that notion every day. Workat it. You know, ask questions,
be curious, go down the rabbithole, look up things, try
things, experiment, but do itevery day and mark it on the calendar
and make sure you don't miss aday. Don't break the chain. Such

(01:00:02):
good advice. I appreciate it.I know it's not something that I'm perfect
gut touching it, touching my goalsand aspirations every single day. Some days
I am just tired and it's easyto not practice something. But I love
that advice, and like like Preston, I'll echo what he said. I

(01:00:22):
feel really inspired listening to everything you'veshared, So we definitely appreciate your time
and your willingness to come and shareyour thoughts with our listeners and talk about
how the Pragmatic programmers has changed insome ways not changed over the years,
but also getting into agile and sharingyour thoughts there. I especially love this

(01:00:44):
emphasis on learning and to me,that that right there alone gets me excited
because that is what programming should be. It should be fun and curious and
that, like you said, exploratoryand I love that so thank you so
much. And if anybody would liketo connect with Andy, he is on

(01:01:05):
Twitter and you can find him atit's at pragmatic Andy. It's a perfect
name. And then Andy, isthere any other way that you would be
interested in connecting with people? Uh? Sure, I was gonna say.
I'm on Mastodon as well as PragmaticAndy at mastodon dot social. My homepage
on the web is toolshed dot com. That's where you can find more about

(01:01:27):
my various projects, my science fictionnovels, my music, endeavor's links to
the grows method material, bunch ofarticles and thoughts through the years. If
you like the sort of thing youknow, come on it's all up there
for free, read away and learnsomething new and do something cool with it.
Nice. Yeah, well, thanksagain, And also everybody, if

(01:01:49):
you want to come and join ourcommunity meetup. We meet once a month
every it's the last Thursday of everymonth, or if you're interested in the
Spanish meetup, we meet on thesecond Tuesday of every month. But you
can find us at Angular community dotnet. So thanks everybody for listening and
we'll hope to catch you in ournext episode. Thank you for listening to

(01:02:14):
the Devlife an encomp podcast. Wewould like to thank the ngcomp organizers,
Joe Eames and Aaron Frost, oursponsors, and our podcast editor and audio
engineer, Patrick Hayes. You canhire him and find him everywhere on social
media at pat John Hayes. Thispodcast was mixed and mastered by spoonful of
Media. You can find out moreinformation about their work and the services that

(01:02:37):
they offer by going to spoonful ofmedia dot com.
Advertise With Us

Popular Podcasts

Stuff You Should Know
Dateline NBC

Dateline NBC

Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com

The Breakfast Club

The Breakfast Club

The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!

Music, radio and podcasts, all free. Listen online or download the iHeart App.

Connect

© 2025 iHeartMedia, Inc.