Programmer's Bookshelf: Cliff Notes Edition
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 24 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46562 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 20209 / 24
2
5
8
10
11
13
15
16
17
19
20
23
24
00:00
Linker (computing)RhombusShape (magazine)CodeMusical ensembleProgrammer (hardware)Computer animationJSONLecture/Conference
00:26
SoftwareVideo gameFamilyBitSoftwareCASE <Informatik>Software engineeringComputer animationLecture/Conference
00:51
Table (information)Software developerPerspective (visual)Degree (graph theory)Web 2.0Client (computing)Level (video gaming)Projective planePosition operatorSoftwareOffice suiteFormal languageSelf-organizationComputer scienceSoftware engineeringComputer programmingTask (computing)Product (business)Multiplication signDigitizingProgrammer (hardware)Online helpStaff (military)Information technology consultingComputer animation
03:30
Programmable read-only memoryBookmark (World Wide Web)Programmer (hardware)Classical physicsSoftware developerDemosceneBitComputer animationMeeting/Interview
03:56
SoftwareCollaborationismDesign by contractBoiling pointAuthorizationOpen sourcePoint (geometry)BitProgrammer (hardware)SoftwareEnterprise architectureGroup actionMassProcess (computing)Multiplication signTouchscreenCode refactoringCollaborationismComputer animationLecture/Conference
05:31
Programmer (hardware)Programmer (hardware)AuthorizationComputer programmingComputer animation
05:53
Programmer (hardware)Computer configurationSound effectSheaf (mathematics)Different (Kate Ryan album)Perspective (visual)Electronic program guideProgrammer (hardware)Context awarenessOffice suiteCodeComputer animation
06:39
CodeDependent and independent variablesNumberMereologyFrustrationGame controllerComputer-assisted translationSoftware developerSelf-organizationSource codeExterior algebraProcess (computing)Computer animation
07:33
Formal languageDependent and independent variablesChemical equationSpeech synthesisProgrammer (hardware)Type theoryPressureCore dumpBlogTerm (mathematics)OvalSoftware developerSoftwareComputer animation
08:48
SoftwareEntropie <Informationstheorie>Representation (politics)Physical systemEndliche ModelltheorieWindowCodePoint (geometry)Decision theoryAuthorizationStress (mechanics)SoftwareEntropie <Informationstheorie>Sheaf (mathematics)Physical systemCartesian coordinate systemStrategy gameType theoryProgrammer (hardware)Line (geometry)Moving averageMultiplication signDifferent (Kate Ryan album)BuildingInheritance (object-oriented programming)Single-precision floating-point formatMultiplicationTelecommunicationSoftware developerDevice driverKeyboard shortcutWordFunctional (mathematics)Standard deviationPressureReverse engineeringExtreme programmingResultantLevel (video gaming)Web crawlerComputer animation
12:10
Decision theoryTerm (mathematics)Sheaf (mathematics)CuboidComputer-assisted translationUniverse (mathematics)Reverse engineeringSampling (statistics)Programmer (hardware)Multiplication signDecision theoryComputer architectureSpherical capComputer animationPanel painting
13:13
ExistenceCode refactoringDynamic random-access memoryCommodore VIC-20Revision controlPoint (geometry)Computer programmingComputer animationMeeting/Interview
13:35
Fibonacci numberCode refactoringProcess (computing)Physical systemSoftwareCode refactoring
14:01
Code refactoringSoftware maintenanceAsynchronous Transfer ModeComputer programCodeCartesian coordinate systemBitLibrary catalogOrder (biology)Different (Kate Ryan album)AuthorizationSoftware testingPattern languageComputer animation
14:36
Code refactoringFeedbackSoftware testingState of matterMathematicsMereologyCommitment schemeNumberPoint (geometry)Solid geometryMessage passingSuite (music)1 (number)CodeLecture/Conference
15:00
Programmer (hardware)QuadrilateralPoint cloudCodeComputerCode refactoringSoftwareBoiling pointLine (geometry)Multiplication signCodeTunisCode refactoringMathematicsOrder (biology)SoftwareDecision theoryPattern languageDisk read-and-write headWindowRight angleComputer animation
16:52
CodeProgrammer (hardware)Code refactoringSource codeDependent and independent variablesData managementScheduling (computing)Boss CorporationRight angleComputer animation
17:33
Code refactoringCodeCodeGoodness of fitPoint (geometry)NumberConnected spaceDependent and independent variablesDecision theoryProcess (computing)Code refactoringMultiplication signTrajectoryHTTP cookieWritingSoftware bugVector spaceComputer animation
19:11
CodeCode refactoringSoftware testingSoftware bugCode refactoringCodeWeb-DesignerSheaf (mathematics)Bookmark (World Wide Web)Software testingParameter (computer programming)Social classFree variables and bound variablesSuite (music)Price indexTraffic reportingBoundary value problemSolid geometryPattern languageSurfaceSoftware developerMereologyBit rateFrequencyWebsiteElectronic mailing listComputer animationLecture/Conference
20:44
Library catalogPattern languageCode refactoringBitCycle (graph theory)Drop (liquid)Library catalogData structureTrailCode refactoringSpecial unitary groupConfidence intervalControl flowCodePattern languageSlide ruleCartesian coordinate systemSoftware testingMechanism designSoftware design patternSheaf (mathematics)Multiplication sign
22:50
Boiling pointBitContent (media)Presentation of a groupComputer animation
23:23
Programmer (hardware)Closed setAuthorizationVideoconferencingLevel (video gaming)PlanningProgrammer (hardware)Form (programming)Proof theoryBootingNumberComputer programmingSeries (mathematics)Computer animationMeeting/Interview
24:31
Programmer (hardware)Mathematical optimizationQuicksortTask (computing)NumberTime zoneCodeMeeting/Interview
25:19
Open sourceSoftwareDependent and independent variablesTable (information)SpacetimeSoftware developerLevel (video gaming)Point (geometry)MIDIProgrammer (hardware)Metropolitan area networkRight angleInformation securityComputer animation
27:09
BuildingVideo gameBoiling pointFormal languageSoftwareSoftware frameworkProgrammer (hardware)Shared memorySoftwareHacker (term)Multiplication signFormal languageSoftware developerComputer animationMeeting/Interview
27:40
Software design patternComputerComputer programmingFormal languageSoftware testingTime domainComplete metric spaceExecution unitSoftwareDifferent (Kate Ryan album)Reading (process)Computer animation
28:03
Sign (mathematics)TwitterComputer animation
Transcript: English(auto-generated)
00:21
So hi there, welcome to this remote edition of the Programmers' Bookshelf. I am Lisa Bakker and I am coming to you from Arlington, Virginia, and this would be a picture of the family that I would be missing so much from Portland, but I'm not missing them at all because they're downstairs. So I am a senior software engineer, but that didn't always used to be the case.
00:44
So I thought I'd introduce this topic by giving you a little bit of a background on how books came to play an important role in my life. So I, like many of you, did not graduate with a computer science degree. I had more of an organic career path. I wanted to do dance programming,
01:01
which is not the same as computer programming. So I got an internship at this place, the Kennedy Center for the Performing Arts in Washington, D.C. I worked there and then to stay and staff, I took a position in the office of the CIO and the web folks that worked with him needed a little help. So I started helping out on the web.
01:23
Some of you may know that working in the arts doesn't pay a lot. So I also waited tables on the side and I worked in a crab house. This is important because crabs, Maryland crabs specifically, are seasonal and they're only available in the summertime. So that means in the winter I was really bored. And so I read manuals because back then software came with manuals.
01:44
So these were good for getting familiar with how to do basic tasks and what was available in a language or a framework. And it helped me get better at helping with the web folks. And so I started getting promoted and that meant I could stop waiting tables. And I also started working on more complicated projects.
02:03
Now, back then, I didn't have any mentor I could turn to. I didn't have any senior developers I could talk problems with through. So it became kind of difficult to figure out how to deal with all this. So in the early 2000s, several important books had just come out and they became my mentors.
02:21
They encouraged me by validating my approaches. They supported me with how to communicate with programmers and non-programmers. They helped me structure my thinking and be able to approach these more difficult problems. So fast forward to today. I am a senior software engineer at Dockyard. We are a digital product consulting agency.
02:41
And as you can see here, I get to work with some pretty awesome clients. I also work with some amazingly smart people, some of which you're hearing from at this conference. Some of these people that I work with, they have really fancy computer science degrees and some of them don't. They all bring an interesting perspective and they all treat their work as refining a craft.
03:01
This reminded me of my old books. So I decided to go back and take a look. This time there was a new level of inspiration. Not only were they validating my approach, but they reminded me why I stick to that approach in the first place. And that it's worth fighting for that. Even when I'm faced with a challenging project or a challenging person, perhaps.
03:22
These books inspire me to stay motivated and to keep reinventing myself in tech, which as we know is a requirement in this career. So here we are, the Programmer's Bookshelf. So we're going to go through two classics that I chose today based on their relevance currently and also based on the impact they had on my own career.
03:42
The first is the Pragmatic Programmer. This approaches software development as a craft and it's my favorite. And then Refactoring, which gives more focused technical advice and specifically around sane refactoring principles. So a little bit of a history here. Back in 1999, enterprise software was really large and really complicated and really expensive.
04:06
Everyone had Gantt charts and like Microsoft Project and these horrible waterfall approaches. But there was this subversive culture of open source that was starting to appear. And this work, The Cathedral in the Bazaar, brought that to the masses and really made people understand how this could be viable.
04:24
It kind of contrasted the idea of this pristine waterfall approach with a few people in a room as building a cathedral versus like the raucous, diverse methods of distributed open source as the bazaar. Even though the author is no longer relevant, this work is freely available and I strongly suggest reading it partially to know your history,
04:43
but also because it gives really good advice about working in teams and open source. So anyway, our books, Refactoring in 1999, somewhere in there I started. And then in 2000, The Pragmatic Programmer. Finally in 2001, The Agile Manifesto. So let's pause for a second on that.
05:01
The Agile Manifesto, this is the entire thing here on the screen. Don't try to read it all, but focus a little bit on the middle there. The point is this, we were in a time of transition and the emphasis in the industry was moving from super hardcore planned out, long processes with heavily documented and a lot of risk
05:20
to collaboration and faster delivery and responding to change as the priority. So fast forward to recent, last year the refactoring was revised and so was The Pragmatic Programmer. And then here we are today at a remote conference in 2020. So The Pragmatic Programmer.
05:41
It was considered by many to be one of the most influential programming books. It was written by Dave Thomas and Andy Hunt, who were also contributing authors to The Agile Manifesto. It consists of a hundred different tips within sections that are organized into like broad topics. Each section is really short and digestible
06:00
and cross-reference to the other sections. And each section gives you challenge questions at the end, kind of thought questions that you can work through. So what does it mean to be pragmatic? A pragmatic approach is to keep a larger perspective and it's to see and solve an immediate problem while still thinking about it in the larger context. So I mean, when I think about The Pragmatic Programmer as a work,
06:24
it's kind of like this mentor in my office that guides me to having really elegant and maintainable code, but being pragmatic about delivering kohud. So we're going to go through a couple of sections today, highlights from a pragmatic philosophy and a pragmatic approach. One of the overarching principles of this book is personal responsibility.
06:44
You are responsible for your career. You're responsible for your code and your deadlines. This also means you're responsible for dealing with problems when they come up. You have to raise your hand when something is no longer possible and you're responsible for suggesting an alternative, not just giving up and being defeatist.
07:00
Excuses like the cat ate my source code. They're just not going to fly. Stated another way, tip number three says, you have agency. So the scenario here is a frustrated developer who's kind of stagnating in their job. Maybe they feel technology is passing them by. Maybe they're underappreciated, underpaid, part of a toxic team, like you all know the scenario.
07:21
The tip here is to remember that you are in control. Martin Fowler, who we'll get to soon, said you can change your organization or you can change your organization. Speaking of responsibility, the industry puts a lot of pressure on us to continue learning and changing,
07:40
and it's our responsibility to keep up. Knowledge and experience are the most valuable assets for software developers, but they are expiring assets. So pragmatic programmer tells us to think about this as an investment portfolio. And they have an investment advice, of course. So invest in yourself regularly as a habit. These are like the small things,
08:01
listening to podcasts, reading blog posts, going to meetups, speaking at meetups. Diversify, so this book sets a goal of learning a new language every year. Totally wish I would have kept up with that, but it's not too late. Balance, keep a balance in your portfolio. Don't put all your technical eggs in one basket.
08:21
It's fun to play around with the new shiny things sometimes, but make sure you keep up with the core too. High risk and low risk, but maximize your return. So sometimes keeping your eye on those new shiny things that can provide a huge reward when one of them proves out to be a useful technology. And then rebalance, don't sit on your laurels.
08:42
Reevaluate in terms of where you want your career to go and what types of things you enjoy working with. So moving on to software entropy. This is one of my favorite sections. Entropy refers to the amount of disorder in a system. It's in other words, software rot or tech debt. So the idea here is that one broken window over time
09:03
in a building can lead to a sense of abandonment. And as a result, you start seeing more broken windows or litter, graffiti, and eventually maintaining that building becomes too much of a hassle and the owner gives up and it's officially abandoned. Kind of a self-fulfilling prophecy. The idea with this in software,
09:21
the lesson is to fix these broken windows as you find them. So fix problems as you find them. And even if you can't, due to the stress of time, at least make an issue in your backlog with a comment and come back to it. A poor decision, even if it wasn't a bad decision at the time, if you leave it unaddressed in your code, it can lead to more and more ill-fitting solutions.
09:43
The flip side of this is code that is so pristine that it inspires you to be a better programmer. A story in the book is about a friend of the authors who had a really fancy house and super expensive art. And one day there was a tapestry that was hanging too close to the fireplace. So a little fire started and the fire department came, but they looked around
10:00
and before they went straight to the fire, they rolled out a mat because they didn't want the hoses to get the carpet dirty. I mean, it's kind of extreme, but it makes sense in software. Like in one hand, you've got code that's lots of broken windows and it's pretty easy to start thinking, well, I mean, it's all lousy anyway. I just need my code to fit in, like who cares? It can make you unhappy and unmotivated
10:21
and lead to worse software, obviously. On the other hand, you have code that's so beautiful and so well tested that you don't want to mess anything up. So even if there's the fire of a raging deadline, you don't want to be the one to make a mess. So moving into the pragmatic approach section, DRY, don't repeat yourself. This phrase was coined by Dave Thomas
10:41
and the concept seems really obvious and easy, but it's often overused and misunderstood. I still see people arguing today about whether DRY is a good thing or a bad thing. The key point here is that DRY refers to a single piece of knowledge, not individual lines of code. And it's also worth noting,
11:00
and this is addressed as well in pragmatic programmer, some people see comments as duplication of the code, but your comments are the why of your code. Whereas the code explains the how. So pragmatic programmer goes into a couple of different types of duplication and gives strategies for each, but I'll just go through the types here.
11:21
So imposed, this is when it's forced on us by like standards or languages, having to define a model in multiple places or something. Then we have inadvertent duplication. So this is when, yeah, you just made a mistake early on and you ended up with some stuff duplicated and you need to go back and fix it. Impatient duplication, this gets the best of us, right?
11:42
Like you have time pressures, you copy a function, you just change a couple of lines that you need to change and then you like commit it and run away. Those shortcuts, they make for some long delays and it's hard to have that discipline upfront sometimes. Then there's inter-developer duplication. So this is, you know, one person doesn't know what the other person's doing.
12:02
We need frequent communication, and code reviews is a good way to keep an eye on everything that's going on in the application you're working with. So the reversibility section reminds us that there's always more than one way to implement something. And because of that, we have to kind of guard ourselves for changing our minds in the future.
12:23
The challenge question in this section asks us to consider Schrodinger's cat. The idea is you probably know is that there's a cat in a closed box and there's a 50% chance it's been killed. So before you open up the box, there's two outcomes and they each exist in your own universe. And when the cat is dead and when the cat is alive, you don't know until you open the box
12:41
which universe you're in. So no under coding for the future can be so difficult. How many alternative universes have you created with the decisions in your code and in your architecture? How hard will it be to support them when you open that box? So I bet most of you have heard of rubber ducking, the approach of solving a problem
13:02
by talking through it in simple terms to anyone, even a duck, originates from a story in the pragmatic programmer. Like there's so many great topics in this. It's like I said, my favorite, but we just have time for a sampling. So let's move on to re-bactoring. Written in 1999, like I said, and revised in 2019 by Martin Fowler and Kent Beck.
13:21
There are two programming legends. They're also original signers of the Agile Manifesto. I'll point out that in the original version of this book, all the examples were in Java, but now in the revision, they're all in JavaScript. So totally accessible to all of us. So refactoring is the process of changing a software system in a way that doesn't alter the external behavior
13:43
of the system, but just changes the internals. When you refactor, you're kind of improving the design of the code after you've written it. It's this fine process here for getting soap that has slipped out of the bathtub, has possibly gone through a few refactorings, but hasn't changed the external goal of getting the soap back.
14:05
So, excuse me. This book starts with a whole chapter as an example. It's a small application that handles billing for a Shakespearean theatrical troupe. The authors kind of walk through different steps they need to do to improve the code in order to add some new features.
14:21
It's a bit more in-depth than a to-do example, but a little less than the real world. And then there's some chapters on the principles of refactoring, on bad smells and building tests, and then a catalog of refactoring patterns, which is the bulk of the book. So in refactoring, you start with a solid test suite. That's always step number one.
14:41
And then you make a small change, make sure those tests still pass and commit, repeat. The point here is to keep a very short feedback loop and always keep your code in a workable state. Unfortunately, with Ember's emphasis on tests, that part should already be in your practice.
15:01
So going through a tricky portion of code involves reading that code, gaining some insight, and then using refactoring to get that insight from your head back into the code. This readability is called code archeology. This is what you spend a lot of time on, particularly if you're looking at something that was complicated and written a while back
15:22
by you or someone else. Some can say that spending a lot of time focusing on the readability of the code makes it harder to performance tune. But in refactoring the book, they say it's easier to performance tune well-written code. So why would we refactor? To fix broken windows, right?
15:40
And eliminate the duplicated code that we talked about. Readability is a big one that I just mentioned. Taking the time to give a little reevaluation of the software before you commit it with your code and making sure it's easy to read can save that poor soul in the future as usually you. Fowler says that he likes to take everything in the code.
16:01
He likes to put everything into the code so that he doesn't have to remember anything. We refactor to find bugs. When you clarify the intent of the code, it makes it a lot easier to see when something is wrong and doesn't line up. And then the primary thing is speed, right? So this code archeology burden really slows us down
16:21
and refactoring makes it so that it's much easier to add new features. It's especially easier than working around older patterns that don't apply anymore. So as we kind of alluded to, software is never done, right? So we need to remember no decisions final. In order to add capabilities, we're gonna need to tweak the existing code
16:42
so that it can accept the changes more. Refactoring is making that hard change so that you can make the original requested change easier. So some people think that refactoring is just cleaning up bad code. And a technically savvy manager would encourage refactoring
17:02
as a constant improvement to the source code. But what if that's not your boss? Martin Fowler's advice is to just go ahead and do it anyway and don't tell them. His thinking is that this is a schedule-driven manager, right? Who wants the feature completed quickly. And if you know that the fastest way to do this
17:21
is to make a small improvement first, then do it. Because putting that knowledge back into the code makes everyone around you faster too. So it's your responsibility to your fellow programmers and to your future self to speed them up. Now, similarly, there are times when you shouldn't refactor. For example, if you have code that you only really use instead of actually modify,
17:43
it kind of becomes almost like an internal API. And that's kind of how they suggest treating it is as an API. So just making sure you fully understand all the connection points rather than going down the rabbit hole. It's not always worth your time to refactor code that you hardly ever touch.
18:00
You're not gaining a whole lot from the archeology process there. This happens a lot. You have a small thing that you're going to change, but you realize that you kind of like to refactor something in the process to make it easier. And that refactoring becomes huge. Sometimes for the team trajectory, it's better not to make that huge refactor.
18:21
Although caveat, if you keep seeing that same thing over and over and over, then it's worth the time. Finally, the decision to throw it out and rewrite, it's very subjective. So subjective that in the book they mention it and that's it saying completely outside the scope. So finally, the book offers to avoid refactoring
18:43
in the name of clean code or good engineering practices. Anything that sounds like a moral explanation because the point isn't to make your codebase sparkly clean and show off how elegant you can be, but it's to make adding features and fixing bugs faster. So a tech lead has the responsibility
19:01
to use refactoring to improve the codebase and to guide the team on when to refactor. Given the number of judgment calls, it's actually a really good opportunity for mentoring. So next we go into the concept of code smells. A code smell, like the smell from a diaper, is a surface indication that usually corresponds
19:23
to a deeper problem. It's quick to spot, you can smell it, and it doesn't always mean there's a problem, but generally it means you should take a deeper look. The book goes on to elaborate on 22 possible code smells from duplicated code to large classes or long parameter lists.
19:41
Each section includes an explanation of the smell as well as some suggested refactoring pattern solutions. Code smells can be pretty easy to spot if you know what you're looking for. So on his website, Martin Fowler suggests having lead developers pick a smell of the week and then having junior developers find them and pair on the solutions.
20:01
So the next part in the book is devoted to tests. And as I mentioned before, that solid test suite is a prerequisite for refactoring. It's a short section, but it's kind of useful with regards to like the philosophy of testing. And there's some good tips about the frequency, about writing tests at the beginning of a bug report
20:20
to expose the bug prior to fixing it, writing incomplete tests as placeholders and boundary conditions. But my favorite piece of advice out of there is not to let the fear that testing can't catch all the bugs stop you from writing tests that will catch most of the bugs. So don't give up because it's not perfect. Just keep improving things.
20:41
That's what refactoring is doing. So the bulk of the book, like I said, is a pattern catalog, kind of like a design pattern catalog. And rather than going through what these patterns are, that's for you. I'll just give you a sense of how they're structured. So they all start with a name and that's to give a common vocabulary.
21:02
And then they have a summary. And rather than being a written summary, it's usually pictorial and a little bit of code, just give you a quick idea of what we're dealing with. Then there's the motivation section. So this describes why the refactoring should be done and some circumstances where maybe it shouldn't be done.
21:20
Then we have the mechanics. These are step-by-step instructions. And what you may or may not be able to see on the slide is that it's kind of like, do something, do something, test, do something, do something, test. So it really emphasizes that short testing, committing cycle. And then finally, there's an example. And these are those silly textbook kind of examples,
21:41
but they give you an idea. So I would suggest kind of going through, familiarizing yourself with the motivations of each thing so that you know what's in there. And you can come back to the details when you actually want to do it in your actual application. So finally, there's a little pragmatic advice at the end of this book that I really like.
22:01
Let's say you're going along, you're refactoring, you're making things better, everything's great. And then you start to feel wrong. You just lose your confidence. It could be it's the end of the day and you're tired. It could be that you're realizing that maybe it wasn't the right way to go after all, and you're feeling kind of like you wasted time. Whatever the reason,
22:20
Fowler says that you just stop and take a break. If what you have still makes sense, then go ahead and commit it. Remember, you kept everything in a workable state. But if it doesn't, that's fine, like move on. You've learned a lesson and you probably know the code better than you did before. So he says it's kind of like walking on a really narrow trail above a really steep drop. And as long as you have enough light and confidence,
22:42
then you can keep going. But once that sun goes down, you better stop and wait for the sun and your confidence to come back. So is there a place for a book still? I mean, how many people still read books? Are they just this vintage, quaint, handcrafted artisanal learning experience?
23:04
Martin Fowler tried to address this a little bit in the profits to the revised edition and concluded that it's still kind of the best way to present long form content. Not everything works in a Medium article, right? But I do see some people slicing up their books and putting them into Medium articles anyway,
23:21
and it can work. I actually had the interesting experience recently. I was at a conference a few weeks ago and Dave Thomas, one of the authors of Pragmatic Programmer, was giving the closing keynote. So I got up my nerve and I went and I sat down with him at lunch and this fuzzy picture is the only proof I have.
23:41
But I asked him about like the place for books and how to make this kind of longer form next level learning accessible to people now. We talked about video series, boot camps, even sock puppets. But you know, how do you teach experience? Like stories help.
24:02
But you know, I still see these books as my mentors and they didn't teach me how to program. They taught me how to be better. But then lo and behold, I got to his keynote and this was there, how I'm becoming a programmer, becoming a better programmer. So he kind of laid out a three-step plan.
24:21
So in a homage to the Pragmatic Programmer, we're just gonna run through this real quick. He said, be happy, keep learning, and do good in the world. So step number one, get happy. Remember back at the beginning of this talk, tip number three, you have agency. So don't be so resistant to change that you make yourself miserable.
24:40
Like find a place where you enjoy your work and find work that you enjoy doing and where you're appreciated. A happy programmer is a more efficient programmer as well. You know, joy is an asset and most of us really have fun coding. So humans tend to get the most pleasure in a task in some sort of like optimal challenge zone.
25:02
So this is where it's like a stretch for us, but not impossible. A task where we feel a sense of achievement. The problem is that if we stay in the zone too long, we start getting comfortable. Remember, your knowledge portfolio is full of expiring assets. So this leads us to Dave Thomas' step number two, keep learning.
25:21
What separates a junior developer from the mid and senior level developers? I mean, it's experience. But what does that really mean? This is something we talked about at the lunch table and experience means that you failed, right? It means you made mistakes. It means you were uncomfortable. You were a newbie. You made a mistake and you learned from it. Was it really that bad?
25:41
That's what we call experience. What we need to do is to make failure fun, right? Keep learning, keep expanding. Being diversifying your portfolio means being a newbie and being uncomfortable. In his talk, Dave Thomas said that if you don't know what's going on, you're on the right path. So I feel like I'm on the right path.
26:03
Finally, I think open source is a great place to deal with this also as a mentor. There's such a large ecosystem that there's always something for people to work on. It could be you need a more newbie challenge if you are looking to expand into something a little different and a whole community of people to guide you.
26:24
Now the third point was do good. In the post space to the pragmatic programmer, they talk about another seminal work which is the mythical man month, which again, you should also read that by Fred Brooks. And he says that programmers work only slightly removed from pure thought.
26:40
We build castles in the air from air creating by exertion of the imagination. So we can make anything really, but this comes with the responsibility of doing what's best for our users. So it's our responsibility to protect users by thinking about security. It's our responsibility to prevent a valid experience
27:00
to all of our users by making accessibility a priority. We should build our software the way we wanna see the world. So the final tip of the pragmatic programmer, it's your life, share it, celebrate it, build it, have fun. So it's pretty much all the time I have.
27:22
And while there's sometimes some dated material in these books, especially with regards to stereotypes of early hacker culture, these principles really translate across time and languages. And it's not just software design principles, but also principles of people, career development, motivation, and even ethics.
27:41
So if you already have all these books and they're just sitting on your shelf collecting dust and you've never read them, or you read them many years ago, or they're in your Kindle, maybe you never heard of them before today, but I hope that you will go out and find one or two to start your reading yourself. Some of them are really long, but like the Agile Manifesto, as you saw, is just a couple of paragraphs and it made such a huge difference.
28:02
So see what inspired everyone. So with that, I am Lisa Bakker, signing off, and I hope you enjoy the rest of your remote experience. You can find me anywhere as Eshda DC, and I'm happy to chat about any of these in Discord or Twitter. Thanks.