 Welcome to this remote edition of the Programmers Bookshelf. I am Lisa Backer 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. 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. Had more of an organic career path. I wanted to do dance programming, 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, DC. I worked there and then to stay in 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. 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. 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. Now back then I didn't have any mentor I could turn to. I didn't have any senior developers I could talk, problems went 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. 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. 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 are hearing from 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. 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. 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 programmers bookshelf. So we're gonna 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. 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 seeing refactoring principles. So a little bit of a history here. Back in 1999, NRE Press software was really large and really complicated and really expensive. Everyone had Gantt charts and 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. 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's no longer relevant, this work is freely available and I strongly suggest reading it, partially to know your history, 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. 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 on the industry was moving from super hardcore planned out long processes with heavily documented and a lot of risk 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. 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 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, it's kind of like this mentor in my office that guides me to having really elegant and maintainable code, but being pragmatic about having delivering cohort. So we're gonna go through a couple sections today, highlights from a pragmatic philosophy and a pragmatic approach. One of the overarching principles of this book is personal responsibility. 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. Excuses like the cat ate my source code, they're just not gonna 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's passing them by, maybe they're underappreciated, underpaid, part of a toxic team, like you all know the scenario. 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 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, 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. Like 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. Re-evaluate 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 another word, software rot or tech debt. So the idea here is that one broken window over time 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, 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. 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 spider started and the fire department came but they looked around 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 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 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, individual lines of code. And it's also worth noting, 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 different types of duplication and gives strategies for each, but I'll just go through the types here. 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? Like you have time pressures, you copy a function, you just change a couple 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 up front sometimes. Then there's inner developer duplication. So this is, you know, one person doesn't know what the other person's doing. We need frequent communication between developers 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 our changing our minds in the future. The challenge question in this section asks us to consider Short Ender's Cat. The idea, as 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. In one, the cat is dead, in one, the cat is alive. You don't know until you open the box which universe you're in. So no undercoding for the future can be so difficult. Like how many alternative universes have you created with the decisions in your code and in your architecture? Like 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 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 read back during. Written in 1999, like I said, revised in 2019 by Martin Fowler and Kent Beck. There were two programming legends. They're also original signers of the Agil 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 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. 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. 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. 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. And fortunately, with Ember's emphasis on tests, that part should already be in your practice. 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 by you or someone else. Some can say that spending a lot of time focusing on the readability of the code can make it less, makes that harder 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? 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 of 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. He lets to put everything into the code so they doesn't have to remember anything. We refactor to find books. 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 and refactoring makes it so that it's much easier to add new features, 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 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 as a constant improvement in source code. But what if that's not your boss? Martin Feller'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 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. That's similarly that are times when you shouldn't refactor. For example, if you have code that you only really use instead of actually modify, 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 a code that you hardly ever touch. You're just not, you're not gaining a whole lot from the archeology process there. This happens a lot. You have a small thing that you are going to change, but you realize that you kind of like to refactor something in the process to make it easier. And that refactoring, it becomes huge. You know, sometimes for the team trajectory, it's better not to make that huge refactor. Although caveat, if you keep seeing that same thing, over and over and over, and 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 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 code base like 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 to use refactoring to improve the code base and to guide the team on when to refactor. Given the number of judgment calls, it's actually a really good opportunity for a mentor. 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 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. 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. 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 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. That's what refactoring is doing. So the bulk of 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. 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. 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, 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 wanna do it in your actual application. So finally, there's a little pragmatic advice at the end of this book that I really like. 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. Like you just lose your confidence. It could be at 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, 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, 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? 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 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. 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 how do you teach experience? Like stories help, but 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. So, you know, 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. 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. Joy is an asset and most of us really have fun coding. So humans tend to get the most pleasure of an attest in some sort of like optimal challenge zone. 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. 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? That's what we call experience. What we need to do is to make failure fun, right? Keep learning, keep expanding. Being a 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. 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're looking to expand into something a little different and a whole community of people to guide you. Another third point was do good. In the post-face 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. 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 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. And while there's sometimes some dated material in these books, like especially with regards to stereotypes of early agriculture, 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. 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 Agilmanifesto, as you saw, it's just a couple paragraphs and it made such a huge difference. 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 Ashda DC, and I'm happy to chat about any of these in Discord or Twitter. Thanks.