Discussing "Clean Coder" by “Uncle Bob” Martin

um and I couldn't stop thinking about Wayne Jarvis which is this like uh character from Arrested Development Jarvis so like anytime he start talking about professionalism like Wayne Jarvis would narrate that part of the book for me um which is just so Wayne Jarvis is this like yeah this attorney on the show and he's just like Oh I'm a professional and like he would always say this of like why he would or would not do something um and so it just made me think of that because really I don't know you should check out some clips on that maybe we can put it in the show notes it's really and if you haven't watched the rest of development there's about an 80% chance this podcast turns into rested development rewatch podcast when we run out of software engineering books so you know you get ahead of [Music] that hey everyone welcome to book overflow this is the podcast for software Engineers by software Engineers dedicated to reading the best technical books in the world in an effort to improve our craft I am Carter Morgan and I'm joined here as always by my co-host Nathan tupes how are you doing Nathan doing great hey everybody great well we are excited this week a couple housekeeping notes right at the top please if you're watching us on YouTube like comment subscribe just engage with the podcast it really helps us out boosts Us in the algorithm if you're following on Spotify or anywhere you can leave a rating leave a festar rating it's a big help and uh follow us on that platform too we keep track of our followers pretty uh diligently and we also respond to our YouTube comments so if you want to engage with this podcast in any way leave a comment uh we love hearing from from you and another great announcement our interview with Mark Richards the author of fundamentals of software architecture is live Nathan how was that experience do you think yeah that was a lot of fun I I think that Mark Richards being just the beginning of a really cool pattern where um we're going to start reaching out and talking to the authors to dive in deeper to the subject matter um so again if you have comments in the videos we'd love to relay those over to the authors as well so if you see something you have additional questions or want deeper insights take that opportunity and um and we'll try to we'll try to give you a voice absolutely we are not uh count your chickens before they hatch people but we can say that we have some exciting things working through the pipelines um and that we can confidently say that Mark Richards is just the beginning like Nathan alluded to so please if you're liking our discussions of the book please keep following along we love it but also um we are really excited about this Mark Richards interview it was such a blast to sit down and talk to him about reading the book and we also got an exclusive scoop about what's to come but we'll leave that as a hint and a reason to check out the actual interview well we are so excited about the direction this podcast is taking it's been such a blast uh doing it and we are excited about the book this week this week we read the clean coder a code of conduct for professional programmers and this is by Robert C Martin colloquially known as Uncle Bob let's do a quick author introduction Uncle Bob he is Nathan would you say he's one of the most famous names in kind of the software engineering publishing Malo yeah his name definitely comes up a lot and his uh strong opinions um are Al also come up a lot yes so background on him Robert Cecil Martin colloquially called Uncle Bob is an American software engineer instructor and author he is most recognized for promoting many software design principles and for being an author and signatory of the influential agile Manifesto he's authored many books and magazines he was the editor-in-chief of C++ report Magazine first chairman of the agile Alliance we learned this in the book but he is he joined the industry at 17 and is self-taught no college for Uncle Bob and he is most famously known as the author of clean code a handbook of agile software craftsmanship now we should mention off the top we did not read clean code we clean coder which is different and I'll give a a summary of the book this is the Amazon blur programmers who endure and succeed amid swirling uncertainty and non-stop pressure share a common attribute they care deeply about the practice of creating software they treat it as a craft they are Professionals in the clean coder a code of conduct for professional programmers legendary software expert Robert C Martin introduces the disciplines techniques tools and practices of true software craftsmanship the book is packed with practical advice about everything from estimating and coding to refactoring and testing covers much more than techniques and is about attitude Martin shows how to approach software development With Honor self resect and pride work well and work clean communicate and estimate Faithfully face difficult decisions with Clarity and honesty and understand that deep knowledge comes with a responsibility to act lots of great stuff in this book lots of hot takes we'll discuss but Nathan what were your general thoughts on the book this is the most extensive set of General thoughts I have on any book um and so happy to hop on this first of all I wanted to say I found this book really entertaining so it was fun to read agreed there's lots of anecdotal stories um the the history of you know his software engineering goes all the way back to like pdp8 days which um I know of these machines but I've I've actually never seen one um and uh I'm I'm pretty sure it was the PDP 11 that like Unix was first created on it was one of the PDP machines so yeah back in the day pretty cool it also the book provides a lot of solid advice from a season to Pro and I think that that's there's this air of authority that he's coming from and a lot of it is these here's this mistake I made here's this character Arc and here's a way that you can act this professional I thought that was a really it's a clever pattern and it's one that's really engaging I do fear if you read this book really early in your career you could take it as gospel and that if you take this with advice without Nuance you may not understand um the and appreciate where he came from you know some of his attitudes were really bad early in his career and he is sort of healing from this process other folks may not struggle with that and so if you just take prescriptively what he's telling you to do it might be an overcompensation for your personality type things like this I my my other hot take is that this is the the CrossFit of programming Styles me this earlier in the week and it cracked me up yeah so I'm and I'm I was like I did CrossFit for years so I I mean this in a loving way but it's it's sort of like people who are into CrossFit or veganism or anything it's like do you know programmers who are into clean code don't worry they'll tell you right so it's that they'll you know it's it's one of those things where as soon as you start hearing somebody obsessed about clean code it's probably because they just read some Uncle Bob stuff um so I had a like half smirk on my face when I was like coming across some of these things but I still thought there's a nugget of wisdom and Truth to every piece of advice even if I maybe rolled my eyes a little bit at some of it the other one was the book's obsessed with professionalism which again it's in the title or the subtitle at least um and I couldn't stop thinking about Wayne Jarvis which is this like uh character from Arrested Development Jarvis so like anytime he start talking about professionalism like Wayne Jarvis would narrate that part of the book for me um which is just so way Jarvis was this like yeah this attorney on the show and he's just like Oh I'm a professionally like he would always say this of like why he would or would not do something um and so it just made me think of that because really I don't know you should check out some clips on that maybe we can put it in the show notes it's really and if you haven't watched Arrested Development there's about an 80% chance this podcast turns into an Arrested Development rewatch podcast when we run out of software engineering books so you know you get ahead of that there's dozens of us so he made um and then he also one of the most interesting hot takes that I found in the book was um I'm obsessed with uh Mii chm high in the idea of flow like that's where this whole focus on Flow and creativity he also calls getting in the zone and he makes a case against spending too much time in flow and I just i' never heard of this hot tap before and it kind of like knocked me a a bit and I had to like really think about where he was coming from here um I went from a visceral reaction against this idea to being like okay I I see where he's coming from so anyway those are my general thoughts I'm sure we'll bring them up when we get into specifics but yeah I it made me think a lot I'll take I'll say that your final point about how it kind of took you a and you being like I've never heard this take before is how I felt about a lot of the book and not necessarily in a bad way but yeah it's kind of filled with like I said hot takes I totally agree that it's a very engaging book which is great because obviously we're reading a lot of books in this podcast and I like to strike a balance between whenever we reading kind of deeper technical readings and then whenever we reading something that's a little more like autobiographical or more like a novel so this one definitely Falls in like the autobiographical section and it was it was delightful I mean it was an easy read again do I agree with everything that was written in it probably not but super fun read it serves as a semi biography of Bob Martin's career which is really cool and I also think it's really cool to get an older Engineers perspective there aren't many older engineers in this field part of that can be agism but another part of it is just that it's a growing field and so there's always going to be more younger Engineers than older Engineers so this really did feel like having a crotchy old cooworker who you can sit down at lunch with and get his take on this or that or the mistakes he's made in his career why he's adopted the philosophies he's adopted and to hear it from someone who is as high performing and successful as Bob Martin it's a treat again is it the gospel truth no probably not but it is someone's perspective and I did appreciate that like I said tons of personal stories it makes for a very engaging read despite being pretty intense it's also pretty grounded like the whole thing isn't just platitude after platitude it's usually a platitude followed with some very specific advice on how you could Implement that platitude in your career so I thought that was really helpful and I also found it in a way aspirational he he has a very high standard for himself and for others and I don't know if I'm going to live up to that standard but just seeing someone doing it I don't know and like inspiring is too heavy a word but it's kind of like how people thought what was it like a sub 2hour Marathon was impossible until someone did it and then all of a sudden people started doing it that's kind of how it feels reading this book you might think that behaving this way is impossible or out of like or or too much but seeing someone write a whole book about it reading it and just reading that it is a possibility it kind of broke down that mental barrier in my mind of what my career could be do I want it to be exactly like this book probably not but it it opens up uh possibilities so I I I thought that was really fun about the book um the main theme of the book is professionalism right I I'll I'll throw in another sitcom reference in 30 Rock there's an episode where one of the characters Jenna is trying to be like the spokesman for wool like the the like sheep make but like her life is wool is a conservative industry and she's kind of lives a crazy life and they say she's not wool enough and but then when she will like do things that are she's trying to impress them those things that are like you know conservative they'll be like that's very wool Jenna that's how I felt about this book he talks about like that's very professional this is very not professional the whole book is defined by what is or is not professional and kind of to set up his thoughts on it he had two really engaging stories at the beginning one personal and then one well known from the news so the personal one he talks about working on this team with uh he's the tech manager he's kind of partners with a business manager and they have to get this product delivered it's it's a very time sensitive due date and so they work they work they work they bust down doors they do everything they can to get it done and finally they get it it's ready to go across the finish line but they need legal to like sign off on one more thing he goes to his business partner and says okay great let's go up to Legal let's do our song and dance let's get this done one more time but it's like a Friday afternoon and his his business partner says like no we're not going to go do that even though they're supposed to go live he like what are you talking about he's like legal he's like they're not going to have time to do it today and Bob is like well they can do it over the weekend he's like no he's like if they could have done it they would have done it already the these people are professionals Bob and Bob kind of paused and thought well I thought we were professionals like the dev team but then it sets up the book and he says he reflected on it maybe they weren't professionals and he also starts the book with talking about the Challenger disaster and the Challenger disaster kind of famously was caused by some malfunctioning O-rings which the engineers knew about and they went to management and they kind of raised a big stink internally and said we really shouldn't launch in the states too cold the O-rings are going to malfa or malfunction and Bob Martin kind of says well those Engineers did the right things they went to management it's Management's fault and maybe that's what they tell themselves they said I wonder if any of them regret not calling Dan Rather and he and that sets up kind of the other side of what it means to be professional this idea that ultimately it's not management that's responsible for your career or the product you produce it is you and you're responsible for it and the consequences really fascinating and intense way to set up the book Nathan what are your thoughts on how he set up the book and just how he talks about professionalism in general yeah so I have some I have some conflicting feelings here I think that from like a taking personal responsibility and accountability Mastery commitment like these themes are really solid uh it actually reminds me of um what they what is it pall's law which is be liberal with what you accept and conservative with what you send in the sense that like hold yourself to a very high standard and at the same time understand that you can be responsive to a world that maybe doesn't hold themselves to that same standard but that you can be this example in Beacon I think that's a really valuable thing what I don't get and I think maybe this is a generational divide um especially the Challenger thing I've actually studied the Challenger bit a good a good bit and my uh my father actually is a retired military and uh spends a lot of time he worked in the safety wing of of the Air Force uh and so this is a very famous story and what's funny is the way that he framed the Challenger episode in this book is that like this ragtag team knew that there was some problem and that no one would listen to them and it stopped and that's not really what happened it was actually uh a really interesting story about cascading failure in the sense that every 's zone of responsibility was actually within an error band that was considered acceptable but nobody had measured the system of an emergent disaster that would have come from all a bands cascading in their failure zones meaning that um a fundamental flaw can actually emerge from complex systems when every component is thought of as being healthy and okay and I think this is an area that you know maybe this is just a sign to the times um you know I a big fan of for instance blameless postmortem right the idea of a blameless postmortem is isn't that somebody somebody did push the button or write the code that actually broke the website but why did the organization allow this to happen and and what's interesting is I consider a Professional Organization one that doesn't throw someone under the bus or put too much pressure on the very bottom rungs and there wasn't an emphasis of that in this book um and I don't think that's what the purpose of this book was the the purpose of the book was hey you might be in an unprofessional environment you might do have all this pressure you might have people asking you to give a lie about timelines and you should hold yourself to this high standard and I again I agree with that but putting all of that on you and saying that hey if the organization fails it's because you're the problem that's the part where I was like I don't know yeah I think the book very much deals with like a high internal locus of control if you're not familiar with that means it's a concept in Psychology which basically says how much you feeling control over yourself right and when bad things happen are you blaming that on others or when you want to let's say you want to get a new job are you the type of person who says okay well I'm gonna study I can improve my resume I can send out you know uh I can send out applications there's a lot of things within my power to get this job are you the kind of person who says Hey getting a job is up to everyone else you know I there's not a ton I can do about it so that's having a high internal locus of control that's what this book is about like it's very much not a book about organizations and systems right I actually have no idea what Uncle Bob's thought processes on like yeah like you're saying something like the Challenger disaster in total organizational failure he is a he's a consultant and so I imagine he has feelings about how organizations work but this book is very much what can you do as a software engineer as a professional to be the best Craftsman you can be and so I think if you read this book and I'm not accusing you of doing this Nathan I I know we've been texting about it all week but I think if you were to read this book and be like this jerk doesn't know what he's talking about he's you know doesn't he know about this doesn't he know about that like you're not gonna get a ton out of this book but if you read this book and say okay what could I change from this book there are there there's a lot of great stuff in there and that's kind of yeah what he says being a professional is all about I really do I and I think that's really to it's just I see it as a Continuum and for instance I wish there was a section here that was elaborated more on when to walk away right there are some environments in which you can't Thrive right imagine being in a negotiation where your manager won't be reasonable and we're going to talk about timelines and estimations I've been in environments where you literally tell them this is how physics functions and they're like yeah can you change physics yeah well so how does he Define professionalism he says this book is about softer professionalism it contains a lot of pragmatic advice and intemp to answer question such as what is a softer professional how does a softer professional behave how does a professional deal with conflict tight schedules unreasonable managers when and how should a professional say no how does professional deal with pre pressure and he goes on to say professionalism is something that our profession is in dire need of but to me a big takea away from the book I love Harry Truman the president had on his desk supposedly a sign that says the buck stops here basically there's no one for the the president to blame he's the president and I've tried to take that is kind of a personal philosophy in my life that at some point The Buck has to stop with someone and it might as well stop with me I think that kind of drives with the book that we like there's a lot of specific advice about professionalism as the book goes on but I think the core of the idea of professionalism is we are responsible for what we produce we are responsible for our career we are responsible for managing relationships with our co-work workers that doesn't fall to anyone else and if we are responsible for it it then we should do it in a professional standing responsible way yeah I think you nailed it there and uh that was my assessment as well I I will tell you that a lot of the stories of where he screws up and then you know has the character Arc were um maybe I didn't hit hit the loads of the lows that he kind of describes but I've definitely I've definitely grown a lot in my professionalism and look back and go yeah I over promised here or you know I skirted around process and you know he makes really compelling cases for never doing that right that if you if you say that something's going to happen it needs to happen and if you've identified that there's risk to the project you should bring this up as soon as possible and renegotiate and you know be as honest early in the process as possible and that's just part of professionalism um I also and we'll get into into this later I really love his focus on sort of these non-traditional aspects of you know not necessarily getting a computer science degree or the fact that like a mentorship or apprenticeship should actually be part of our profession I love these ideas and I think that they're well founded with this big greater argument that he makes on professionalism in the book I loved it too a little podcast lore for anyone who's interested Nathan and I also came to this field untraditionally neither of us have a computer a Bachelor's of computer science Nathan is since earned his Masters in computer science and I'm working my way through mine yes so I felt some kinship with Uncle Bob in that we are going to talk a lot about his specifics Nathan alluded to negotiation how you can say no there's a lot of great specific advice in this book we're going to talk about all that and more after a quick break and we are back thank you so much for tuning in Okay so we've talked a lot about professionalism and if you've tuned in you might be a little worried and think this Uncle Bob he's a workaholic he's talking about how I I got to sacrifice my personal life my family work 80 hours a week to be a professional and that's not what he means again the whole point of this book is taking responsibility but a big part of taking responsibility is setting reasonable expectations and so he has a whole chapter it's actually comes very early in the book on saying no because being a professional doesn't mean you say yes to everything this is how he phrases it professionals speak truth to power professionals have the courage to say no to their managers how do you say no to your boss after all it's your boss aren't you supposed to do what your boss says no not if you are a professional slaves are not allowed to say no laborers may be hesitant to say no but professionals are expected to say no indeed good managers crave someone who has the guts to say no it's the only way you can really get anything done I thought this was a great way to kind of push back on what I think Uncle Bob knew we might all be thinking after reading the first bit of the book or what do you think Nathan yeah uh I'm I'm a people pleaser and I'm like a recovering yes aholic so um this is something I've had it's been long and painful in my career as to you know my instinct is to be optimistic on my timelines my instinct is to be to be accommodative um especially if you have like a charismatic leader in your organization it's really easy to be like yeah you walk out of the meeting you're like yeah I think I I think I could pull this off and then you're like wait a second don't be a hero right like that's one of the big points here is that you're going to fail it's going to undermine your credibility there's a lot of reasons to say no uh and to be very um sober in your decision-making process here because your goal is to be the person who has a reputation of follow through delivering what they say they're going to do and part of that is to say no to all the other things that you should say no to to be a success in the things you've said yes to yeah it's a theme throughout the book that adversarial relationships are not necessarily a bad thing I think that about that a lot as a parent I've got four kids all boys very young boys it is their job to run around and try to break things it is their job to try to eat 10 popsicles for lunch right like that's part of their normal healthy developmental pattern to find out where those boundaries are but it's my job as a parent to push back neither of us is doing anything wrong here but it it's that adversarial relationship I have with my children that makes for a healthy functioning Dynamic and he says something similar about managers and workers he says when your manager tells you that the login page has to be ready tomorrow he is pursuing and defending one of his objectives he's doing his jobs if you know full well that getting the login page done by tomorrow is impossible then you're not doing your job if you say okay I'll try the only way to do your job at that point is to say no that's impossible well don't you have to do what your manager says no your manager is counting on you to defend your objectives as aggressively as he defends his that's how the two of you are going to get the best possible outcome and I love this framing that your objectives do not necessarily line up perfectly with your manager's objectives and that your manager's objectives shouldn't subsume immediately any objectives you have for yourself as professionals our job is to create good quality software as quickly as we can and in this scenario they's talking about having a login page done by tomorrow that might be impossible so giving your manager that false hope and saying okay I'll try it's actually not helpful it's not the kindest thing you can do the kindest thing you can do is to defend your goals as aggressively as your manager defends his and and so you might look at that and say okay well then my job is just to say no to my manager all the time also know because as you are working to defend your goals you also want to be creatively coming up with solutions to the actual problem at hand so this is an example of how that back and forth might go with this login page so Paula is is who the the software engineer is in this case she says Mike I can give you a mockup of the login page that we'll let you log in I've got that working now it won't actually check your username and password and it won't email a forgotten password to you won't the company newss Banner time squaring around the top of it and the help button and hover text won't work it won't store cookie to remember you for next time and it won't put any permission restrictions on you but you'll be able to log in will that do and in this context the login page need to be ready for a client demo so this is Paula recognizing the business objective that the client wants to see the login page and wants to have an idea of what it looks like but that everything surrounding the login page can't be done and this is perceptive on Paula's part because she's recognizing the real need here the manager is just coming and saying I need the login page done we as software Engineers understand all that comes with the login page like she says the banner time squaring emailing forgotten password storing it as a cookie of course that can all be done by tomorrow but could the bare minimum functionality be done by tomorrow to make it look operational for a client Nathan have you ever been in a situation like this where uh deadlines have been approaching and you might have had to creatively come up with a solution to help bail your manager out I've done I've worked in a lot of early stage startups and I think this is one of the biggest things that we grapple with is um fuzzy definitions right fuzzy requirements fuzzy definitions if you let those sit um people will misinterpret like what is the definition of done and he talks about this a lot here part part of getting to yes or saying no is that do we all really agree on what the definition of done what is the login page ready for the demo mean you know um and a software engineer I think a lot of times we have a we have a tendency to catastrophize meaning that we're like login page being done well there's like 50 things I have to think about and the manager in this case probably just said I need to show them that we're making progress and I really just need to like have a login thing where the email confirmation comes up that's all I really care about right or at least a a you know mock of a page that says the email was sent right like that's all I really care about and um a lot of conflict to me comes from the fact that I misinterpret what the other person means the other horrible side is I think all they really care about is the login with the mock uh confirmation and they're like no we contractually promised them that we would deliver a fully functional service by this date and I misunderstood right that's a much more situation but yeah what about what about yourself I'd love to hear about your professional experience in this kind of area yeah it's not exactly in this kind of area but he goes on to say either at this part of the book or later in the book talking about how you it's okay to say no it's okay to miss deadlines and to push things out but it's not okay for that to be a surprise if there are errors coming up I mean software engineering we're going to talk about estimation later with software engineering it it can be hard just by nature to know exactly when something is going to be done says that's okay but you need to be communicating that early and often and I've had that in my career several times I I remember in particular in particular working at a cloud provider and having to do this big evacuation routine for we had accidentally developed a circular dependency uh one of our sister teams had developed a circular dependency on themselves in conjunction with using our product right and so I had to orchestrate this big evacuation to of their products to get rid of this circular dependency at this cloud provider uptime and availability was like the number one goal we had to really do everything kind of under close guidance close supervision I had to draft a lot of particular documents called mcm's modeled change management that showed exactly what steps and CLI commands we're going to execute what the criteria for successful execution was what the roll back plan was right takes a lot of time and then you have to get these documents approved by like the sister team and a peer and your manager and then like a senior technical leader right it was a lot um right so because there were I was relying on so many other people the deadline was kind of a moving Target but that project really taught me that about active communication that you need to be telling your manager okay I thought I was going to be able to evacuate this region today I can't because I'm waiting on the signatures from these people but while they've been doing that I have been or while I've been waiting on that I prepared the next three model change management documents I'm going to try to get them all signed off in one go yeah that project was really interesting because from a technical perspective it was really the the surrounding context for it was very complicated or at least uh in the weeds but the actual execution of it wasn't crazy it was really an exercise in like executive functioning and coordinating all these teams I'm I'm in a similar situation with a uh we're moving um like Edge compute resources and I propos thing in the technical implementation really isn't that difficult but it's like yeah hurting cats like getting everyone to actually sign off and understand and agree what the implications are what changes have to be made um this also reminds me of in the fundamental software architecture this is one of the policies uh which is that um that it's that covering your assets piece where you procrastinate on maybe some implementation details because you're not quite ready and I think this is actually an interesting side of the agile methodology as well right which is that you don't have a 12-month waterfall of everything that's going to be done um sometimes you need to be moving back and forth uh as far as like what you're implementing what's ready to ship and this is a good reminder that you have to continue ously negotiate what these definitions of done are right you might have said yes the new information comes up and then you realize I need to set expectations with my manager like I realize that there's a lot more unknown unknowns in this than I assumed and so therefore my pessimistic estimate of this projects actually accurate right and so yeah it's it's really it's a really interesting thing and again I think Uncle Bob gives us some really nice foundational principles to kind of fall back on when you feel like you maybe are getting confused or that you're finding frustration in negotiating what work is actually on your plate or what's realistic um which I which I thought was really cool I agree and that concept we call it a company I was at dun dun dun like what you know we because we think okay the code is shipped we're done are you really right and at this cloud provider we like done done done I remember I had to ship a public facing feature and my goodness was that an insane amount of workload like it it's I remember just writing it and thinking my goodness this would be a two- week job at a a startup and it was like a six-month process to get it out the door to get something that like because I had to we were responsible for the back end but we didn't control the UI and so I had to work with like the the front end team on this right there were a million Security reviews there was legal there was working with the profession document writers there was even at this cloud provider since I was adding a new public facing feature which modified the API contracts it didn't mod it added some new optional Fields but still that is a modification of the API contracts and since that has to propagate across like HTTP request you know like the rest models that has propagated across our our Java python go node SD K everything so they had a whole internal process set up to do that population but that was a big deal you know like there was I learned a lot and you learn about whoo like managing software at skill is crazy complicated but like working through all of the approvals and understanding that system like that was crazy and it was a frustrating process because every time you thought you were done you realize there was another thing that needed to be done um learned a lot about what does done dun done mean and it can be really helpful to have a document or something just a full list of requirements for once we have done all these things then we will be truly done and if you have that that North Star of what you're aiming towards it's easier to say no to your manager it's easier to push back on deadlines because you can take the whole of it in if he says this needs to be done in a week and you can look and say okay well I might be able to have the code shipped in a week but could I unit test it could I build integration tests for it could I again depending on the size of the company could I have the UI portion done working with the UI team done by that point and and that can help you kind of talk to your manager and say I can't have it all done but I can have these parts done and then I can drive towards these parts um and and I know that's scary hearing that because like yeah saying no to your manager is a tough thing this is obviously something that's easier once you're more senior in your career but I do love Uncle Bob's take on it which is this is what professionals do professionals don't work themselves to the Bone because yeah like you said slaves can't say no we can say no professionals don't give Rosy optimistic pictures of what might be because they're scared no we take responsibility for our craft we take responsibility for the deadlines we take responsibility for the pro this is a this is actually a really good segue into coding practices which is something that we do there's a big section of the book related to a lot of things around coding practices absolutely and I I think what what ties into this too if you think about this uh and this is a big motivator for me I want my boss to look good and if I'm not being professional it makes them look unprofessional they go cuz their boss is going to come to them and be like why are you always missing your deadlines you you gave me this report you said all these things are going to ship and things aren't shipping and your boss can't trust you you end up having these situations where you might start getting micromanaged or the teams get reshuffled uh and those are all avoidable if you had the uncomfortable conversation up front instead of saying you know what I'll tell you what you want to hear and then we're just not we'll never hit our deadlines right that's that's really the the Crux of what this professionalism piece is is um yeah so and like you said he talks about some coding practices that can help us feel more confident in the craft we're producing and and feel more confident about moving faster Meeting those deadlines we're going to be back with all of that and more right after this break and we are back thank you so much for tuning in well let's talk about coding practices and let's start talking about something Nathan brought up the beginning which is the idea of flow the you know you might have referred to it as flow you might have referred to it as being locked in you might have referred to it as being in the zone we've all been there as programmers Uncle Bob makes a case for avoiding this Zone which I thought was fascinating here's how he describes it along with his description of the flow Zone much has been written about the hyperproductive state known as flow some programmers call it the Zone whatever it is called you're probably familiar with it is the highly focused tunnel vision State of Consciousness that programmers can get into while they write code in this state they feel productive in this state they feel infallible and so they desire to attain that state and often measure their self worth by how much time they can spend there here's a little hint from someone who's been there and back avoid the Zone the State of Consciousness is not really hyperproductive and it is certainly not infallible it's really just a mild meditative state in which certain rational fun faculties are diminished in favor of a sense of speed let me be clear about this you will write more code in the zone if you're practicing test driven development you will go around the red green refactor Loop more quickly and you will feel a mild Euphoria or sense of Conquest the problem is that you lose some of the big picture while you're in the zone so you will likely make decisions that you will later have to go back in Reverse code Written In the Zone may come out faster you'll be going back to visit it more now a is when I feel myself slipping into the Zone I walk away for a few minutes I clear my head by answering a few emails or looking at some tweets if it's close enough to noon I'll break for a lunch if I'm working on a team I'll find a pair part this is very much a contrarian take what did you think about this I'll be honest I hate this um I think that flow State um sure the one risk that you have is what they call clever code right this is where and you've seen these somebody's doing some like Elite code level tary operator mishmash that puts like what should be 15 lines of code and do like one line of code like and you can do those things in Flow State don't do that like obviously like that is a a good assessment but um some of the best work I've ever done has come out of these deep Flow State sessions and I would imagine I mean again you just look at the uh the history of like prolific ideas that have been prototyped in weekends get you know lonus tals was solving this problem for himself uh look at Ken Thompson and the foundations of Unix was like the beginnings of that was built in 3 weeks when his uh his child and his wife were out of town visiting family um you can't tell me that those weren't built in flu State I I just I would find that near impossible um I think it's who you are and what your personality is and the type of work you're doing I also think that you should edit later it there's nothing wrong with going back and being like what did I do in Flow State here like what what was I doing if we look at um the Oster how book uh philosophy of software design he argues that you should design it twice well it's amazing if one of those designs happened in Flow State and maybe you do a a design in Flow State in one that's not I mean um that to me it's it's a tool I think that it like shooting it down categorically is something that should be avoided is really odd to me uh maybe he got burned with some Flow State hacky code and he you know reached that conclusion I I've enjoyed Flow State and I know that when I find flow I'm happier as a software engine uh obviously you can't spend all day in it but it when you meet it it's like when a writer talks about being visited by The Muse right you have this like deep inspiration and if you're driven with a very clear design thinking I think Flo is I mean I the more time I spend in flu the happier I am I'll put it that way let me I I'll give a defense of Uncle Bob's opinion here or if not defense I'm going to to give some what I think might be some context so Uncle Bob mentions in the book right that he's only ever been drunk twice I do not know if Uncle Bob at this point is is stains from alcohol but at the very least he he doesn't seem to you know indulge to the point of getting drunk right I I I feel kinship with Uncle Bob I I don't drink myself Uncle Bob I could tell I think this book like the idea of sobriety almost like permeates the whole the whole of it right he's he's very much about you are in control you are responsible you are a professional and so I think like again I'm totally just drawing connections and and probably and I'm certain that I'm improperly psychoanalyzing Uncle Bob but I see a through line there between sobriety and being against the flow which is not to and again I I've I've been in the The Flow State before and and I I think Uncle Bob takes it too far I do see the parallels here and that when you're in the Flow State you are you get like he says tunnel vision you're too hyperfocused on one task and you you kind of lose the the inhibitions that naturally should be grounding you when you're writing software I would agree with you Nathan like I think this idea of avoid the flow state is Impractical one I think it's impractical just because we're human beings and like it can be hard to to sit yourself down and make yourself write code sometimes right I know I don't show up for work every day RAR and a go and so sometimes it can be really hard to actually get myself to produce and so if you find yourself in a state where you are effortlessly producing I think that's great and and you should do it but I I would agree with what you said Nathan which is that I think sometimes we as engineers assume that flow code is the best possible code ever written I'm in the zone I I crank it out and and this is the Pinnacle of code but when we lose those inhibitions we might have we might make decisions that we wouldn't have if we were a little more I don't know aware of our contextual surroundings but the solution is just what you said Nathan follow John aerous device or device advice design it twice write flow code and then don't assume this is the best code I've ever written it's a work of art approach it again another time when you are a little more out of the flow Zone and I think that I think is the I would say that's the better approach not always avoid flow but maybe just be aware when you're in in the flow zone of let me let me revisit this later it's totally possible the code you wrote is great and doesn't need any redesign but it's just a good practice in general to design it twice and so don't exempt flow from that you should always doubt your your output meaning that like I don't feel that my flow code is this like magical thing um you should go back and say hey um and with a with a sober approach and I I think this but this is the same way that like so Stephen King wrote in this book on writing um he actually he writes I think 2,000 words a day or some crazy amount he will write beginning to end his book or his manuscript and then he puts it away for six weeks and then he comes back and reads it fresh and I think that's the beautiful relationship between Flow State and that sober approach is that there's this editor's mind and he actually talks about this and this is a cool thing of he makes this argument that is against the one I'm making and he says he's a huge advocate for PA programming also comes up in coding practices and Pa programming is something I've done very occasionally and I wish I spent more time doing it but um he's like PA programming is the antithesis to Flow State it's two people riffing ideas off of one another um and producing output that's superior to the abilities of either one of them the first time it also forces Focus you're not going to get as distracted because you're relying on this other person I love that idea and I do I think that there's something deeply collaborative and interesting uh and this counterargument here that hey look at this highly productive State you can be in that's the antithesis to flow that actually pairs up two people but gives more output than either one of them would have done on their own is a very good argument here and I so again I don't want to diminish the fact that he's got brings a lot of wisdom here and maybe in 15 years I'll come back and be like you know what I was a bunch of I was full of baloney you know like I I shouldn't have been you know so gung-ho about Flow State I don't see that happening because I I'm a huge like free form creativity type of person that's just my personality but I appreciate the perspective uh and I think that it's important for me for me to double down on why I think flow is is valuable I need to hear these counterarguments against them I think otherwise you know it's just a default argument on my side absolutely what do they say like the mark of a intelligent mind is the ability to entertain an idea without accepting it um I think this podcast would be very concerning if we were just reading everything and saying this is a great idea wait no now this is a good one too and we were just immediately accepting everything we read in these books we often disagree with the authors um but it's that perspective is valuable hey some one of our listeners who's good at making memes I want you to make a meme of uh that scene in The Social Network where like Eduardo Andrew Garfield's character like comes storming into Facebook headquarters and like he Mark Zuckerberg is like T typing on his laptop and uh and Sean Parker is like he's locked in and Eduardo's like oh he's locked in huh he takes the laptop and smashes it I want you to make that but label Eduardo's character as Uncle Bob and Mark Zuckerberg as the flow Zone well let's talk about do you want to talk about um well into I think what the big one that you're interested in like I saw your your notes Here which is test driven development but as a segue into this a lot of this he there's a lot of emphasis on pacing yourself and I think that tdd is part of the so pacing ourselves is this idea of like well how do I actually know how much work something is going to be and he gives us a bunch of tools uh and very clear uh layout of heyy you have to have these foundations in place before you can start doing this so for instance he talks about how he used to spend a ton of time debugging uh and that he spends you know oneth or one 100th of the amount of time debugging as he used to because he relies on tools like tdd or test driven development but the other ones I want to bring up briefly is honorable mentions before we get into tdd is um time management and honesty and he talks about like these patterns that we can slip into and ways to amend them on being late at um hope is not a strategy right this like I hope it's going to be done by this date well that's a terrible way that's a terrible way to operate um rushing things so the idea that like okay well if I just like cut out these three or four things in my process I can get it done and then I'll look like a hero and then then everything's gonna be awesome and and he gives really great examples of like this never works out like you want it to and I think from professional experience it's absolutely true you know you you go back and if you don't have to pay for it immediately with something embarrassing you will pay for it in six months or a year when you go gosh this thing keeps like breaking because I just I never did the integration test like I was supposed to and now we found the edge case the customer did like that's terrible over time so he talks very clearly about hey sometimes you commit to something and the only way possible is to do overtime and um you need to negotiate you need negotiate with your family you need to be if it's more than two weeks you're going to burn out and you know these things end um and then also like a false sense like a a false sense of hope right uh where you just kind of lie to yourself right these are all like uh the false delivery I'm sorry false delivery meaning um you redefine definition of done to get it done I his overtime was fascinating because he gave some requirements for like when you should agree to overtime and it was something like I think one of the on was like one if your family's okay with it two if it's two weeks or shorter and three does your manager have a plan for if the overtime doesn't work and he said if you can't get these three things done and I think it was those three things we'd have to go check the book to be absolutely sure but I remember that last one in particular like then don't agree to the overtime and kind of playing with this whole idea again of like sobriety we talk about pacing yourself he says like if you're panicking if you're rushing if you're scared you're not producing the best code you can this franticness and again he's very professional he's way jar he is a professional he says this this franticness is not how a professional behaves yeah I I I thought it was fascinating and he gives a very impassionate offense of test driven development if you're not familiar with what test driven development is it is the idea that you don't write any code before you write a unit test that tests the functionality of that code so for example let's say you need to write a feature on the I don't know you need to write a feature on the customer account class that is going to take all the take all of the the the orders over the past 10 weeks and then return the sum total of them something like that right he says before you start writing that code you should write a unit test for it that evaluates that function and evaluates that it's correctly and he says when you start writing that unit test you'll probably be writing it for like non-existent methods like you might write the you know customer. get sum of past 10 weeks of order function and your ID is going to get mad at you because it's going to say hey that's not a function on this class but that's the whole point the test fails when you write it might not even compile then you write the functionality I I he's really defensive and passionate of it he says yes there have been lots of controversial blogs and articles written about test driven development over the years and there still are in the earlyer days there were serious attempts at critique and understanding nowadays however they are just rants the bottom line is that test driven development works and everybody needs to get over it I felt called out here because I've been skeptical of test driven development for years Nathan what are your thoughts and philosophies on test driven development and maybe how did they change after reading uh this book yeah I think like a lot of things in this book I take a nuanced approach um I will say the best code I've ever written most reliable code I ever written has um really thorough test coverage very early in the process um to me if you have very clear requirements you really already understand how your class structures work what the function signatures are writing out and and those came from a specification document and all great ideas great ideas to write out the spec before you actually write a single line in code you have a very clear path to doing tdd right you know exactly what the API structure is going to be what the function signatures are and you you AB Ely should write failing tests that come out of that first and then Implement uh uh to it times uh and maybe this is some Flow State stuff sometimes you're kind of kicking the tires to figure out how you will structure stuff and I do think that if you write the test first this is kind of the antithesis to um what came up in the philosophy of software design which is that if you write a bunch of tests that cover these like five line functions it makes it really cumbersome to refactor your code in a way that you're like you know what these should actually live together or I'm actually going to like in invisibly move things around and so I my nuanced approach is I try to have formal tdd structure to anything that's exported anything that's externally facing uh and give myself some leniency to internal functions for at least the early part of a development process but then I try to anywhere that hot code path happens right anywhere that um important logic is in place it should you should St to have uh full coverage and again this gets back into Martin Fowler's ideas in refactoring is that you can't refactor with confidence unless you know that you're not putting side effects into the system you can see where Uncle Bob and Martin fower share a lot of um stuff here and of course the way that their programming style works is that they're constantly updating functions and contracts and stuff but if you do that and you have a bunch of very like granular unit tests you're also changing unit tests and that's a really tricky place I and and I I try to have unit tests that I I should be able to refactor some code and not have to change the unit test and if I have to change the unit test I need to be careful because I might trick myself into thinking that all the tests are passing but I actually change the behavior of the function and so yeah that's my like very long answer to um tdd is a cool idea I think if you have real clear purpose um you can't go wrong with it sometimes the formalism you can get into this uh I guess what Oster house called uh Oster how calls um the uh tactical tornado which is that you write a lot of code that you feel like you're feeling really busy but maybe taking a step back and doing a little design work um should complement your tdd but yeah yeah I wish I had more thoughts on it like to be in my Development Career I have always looked at it and thought this is ridiculous what you what are you talking about I write the test first that's insane I write the code first I'm a coder I I would push back a bit on this idea that if you're writing tests that are so fine grained that you when you refactor your code you have to refactor the test I think Martin Fowler and Bob Martin would push back and say yeah that's the point they say it's okay if you need to delete some tests it's okay if you need to refactor your tests right that's a that's the part of refactoring and it's the price you pay for having high confidence that your code is working and that you can switch it around like that I think a mental hump I need to get over and I imagine I'm not alone in this is I always feel like when I have to like dig into the unit test like it's really cumbersome like the code can be manipulated easily and I can understand it and read through it then I get to the test I'm like oh gosh it's like the neglected stepchild of any project and anytime I'm in the unit test I'm like how can I get out of here as quickly as possible how can I change as little as possible here because this is the test Suite this is what governs everything I think Bob Martin and and Martin Fowler and Kent Beck would encourage us to have less of a separation between the two the unit tests are just as much a part of the project as the code um and I'd like to be better about that about feeling like the unit tests can be swapped around more if they're not serving my purpose because ultimately the purpose of the unit tests in test development like Bob Martin talks about is to give us a high confidence that our code is working if is not giving us that why bother and and I will say a Nuance here is I I am absolutely a huge fan of unit testing um unit tests are incredibly important and you know in the go Community a good example is um you know the testing Suite is built into the language it there's a huge um emphasis on highly High test coverage and one of the things I really like and this is in a lot of languages is um TBL driven testing right table driven testing to me is a good example you could write a test that says um you know multiply pi two and you could have a single test case that multiplies a number times two and um it comes back and is correct and um that would actually have 100% test coverage right it's probably like a oneliner but you know one of the things that's important about TBL driven tests is that you know uh or maybe we say you know divide by in or something like this and we run a few tests through it and it's fine but we don't think about things like divide by zero right um You need a TBL driven test to think through a lot of test cases and cases to me are much more important than like what number of lines of code are actually covered you like there's lots of ways that you can like game the system um and I do think that like being as comfortable with your unit test you are with your code base is really healthy relationship and that tdd encourages this it says hey just like with like static typed programming languages I have to think about the structure UPF front right I have to have my structs I have to have my class structure I have to have these things and some programmers find it kind of annoying to think about all these type signatures um but I would say you benefit tremendously from that upfront thought it's the same thing is true with unit tests right if you one of the things that you get for free with tdd is testable code and I think that's one of those things that you know you'll see especially like junior devs or even with you're just not careful it's like I'm G to pass in this database client and instead of uh and and so you do all this stuff and you're always using the database client and then you realize like oh I actually need a mock of the database client or I need uh you know some sort of lightweight version of it so that I can like test these things and so writing your code so it's mockable right writing your code that you can swap out the uh distributed logger for something that is a good uh you know local Dev logger and using patterns like conversion of control or dependency injection you know these are the kind of things that if you're doing tdd these problems are solved up front have to go back and go oh my gosh like I this is untestable code and so therefore I have to do a huge refactor uh and so again that's a huge win on the tdd side is you know think about ATT testability up front um think about the social contracts or the ex export contracts that you have in place uh and I I love that again if I spend a little time writing all my test stuff up front um I feel very confident in my code and I think that's you know nice well Uncle Bob says that the jury is in on test driven development and that anyone who opposes it is a so we might be morons according to Uncle Bob we love you Uncle Bob come on the podcast prove us wrong I mean again I it's funny it's like I I I think it's this is one of those things where you're like um you know you should floss after brushing your teeth like I know that and you know people who are diligent about not getting cavities always floss but I don't always floss and uh you know every dentist out there would probably be like horrified but like I you know it you know it's something that I I make sure that my daughter does uh uh all the time and it's a good habit and you should do it and I felt the same way about tdd oh yeah when my sons write code I make sure that they do tdd I don't do tdd but when my six-year-old is writing his code well I I I have a feeling that tdd is going to be a recurring topic on this podcast and our thoughts and opinions on it will evolve we're not going to resolve everything about tdd within this one episode but uh listeners give us your thoughts on tdd let us know there something you've done and it's worked out well for you is this something you think is overkill like honestly the podcast could just turn into a test driven development discussion podcast and we could probably get a lot of good content out of it but that's not the goal the goal is to read the best technical books in the world well we will take a quick break and be back with more right after this break and we are back wrapping up our thoughts on Uncle Bob's clean coder this book really has so many great pieces to it we always say we could we could do multiple about pretty much every book we ever read we we always just scratch the surface on on what is available in these books we want to make sure before we leave that we talk about estimation Uncle Bob has some interesting philosophies on how you estimate tasks and how you can estimate responsibly as a professional Nathan you you liked this section why don't you give us your thoughts on it yeah I like this section because it was kind of like the medicine I needed to take right um he speaks about commitment versus estimate and how there's a typically a mismatch between management and software engineers in that um he basically makes the argument that if an engineer estimates the amount of time that something's going to take leadership will typically take that as a commitment you say it should take five days and they go cool in five days you're gonna have this thing done and I can go and like you know they're going to create these big plans for the future and that is a devastatingly bad thing if you aren't careful he calls it the danger of implied commitment and um so he really differentiates the idea of what a commitment is and what an estimate is and um he used a method that I had never heard of before it's like an old US Navy operations manual called per the program evaluation review technique s 1957 and he talks about how um there's actually like a systematic statistical way of estimating um with this sort of like you give an O optimistic estimate a nominal one a pessimistic one and then a calculation where you can figure out what the standard deviation is which is basically this this calculation to your program managers I'm like yeah I'm sure they'll run that Uncle Bob and what's funny is that he gives this very like scientific thing and I was like you know I would love to play around with this because it's a really interesting way to think about like your the larger your standard deviation is the more uncertainty you have and so therefore there's these things but then he goes okay but mere mortals like regular humans there's like lots of other ways to do this and one of the best tools that you have at your disposal is the group of people that you're building stuff with right you say I think this will take three days and then somebody in the group goes no no you you always say that it's going to take you six days right and then you negotiate the fact that all the things that could go wrong or they come back and go you know you should get this done in one day like Billy did this over here just like modify what they worked on and you should be you should be able to ship this right and and there's this negotiation there's a lot of techniques and I think if anybody who's on agile Stu there's lots of tools there's like uh estimation poker and a bunch of other things he could he kind of goes over all of those and if you've heard of them you know you you'll probably just be nodding your head uh but the way that he frames it again was this idea that like a commitment is something that the business can rely on and so we need to be very sober in what we're committing to and very much differentiating that an estimation is a distribution if everything goes well it'll only take this much time if everything goes wrong it's over here and then there's this bell curve in the middle of what it probably will take um and that you shouldn't make commitments on probablies right uh and that you need to have these this sort of negotiated contingency plan the backup just like with the overtime conversation it's like okay there's there's three pieces like talking to your family is it less than two weeks and what's the contingency planned with management if this doesn't work out right um and so anyway that had a big impact on me as towards the end of the book he has some really great anecdotal stories but um I think we can segue into the end of the podcast with that that kind of top of mind but I'd love to hear if you have any thoughts on this as well absolutely I I I love his quote he says an estimate is a guess no commitment is implied no promis is made missing an estimate is not in any way dishonorable I think there's a lot in this book I I found overlaps between this and the final section of fundamentals of software architecture which talks about how to communicate well because a lot of times we as Engineers give estimates to management they're taking that as a commitment and there's that fundamental mismatch he talks about that in this book too this is one of the things that I would really just encourage you to read the whole book if you're if you're listening and saying but wait a minute wait a minute the manager's in charge and I can't tell them this is just an estimate it's not a commitment because the book delves into a lot more specific advice and even has like kind of conversation scripts for how you can have those conversations um and but yeah I I think it's a good closing thought on the podcast as we move to our closing thoughts which is just that professionals have high standards for themselves and professionals have clout within the organization in the same way that you might imagine if a doctor you know who's preparing to operate on a patient were to say I'm going I don't know we need to move the surgery back 20 minutes because I am in traffic or because you know because need to listen to this particular song because that's what gets me in the zone for the surgery so we got to move it back 20 minutes I don't know I I don't know how hospitals work but if I were if it were me I'd be like well this is a surgeon he's about to operate he needs to listen to a song for 20 minutes he does what he needs to do because he's a he's a professional right we We should strive to to have the same sort of ethos with our profession where if we say this is an estimate it's not a commitment we would we would hope we' have the institutional clout where management would say well this is a professional this is someone who knows what they're doing if they're giving me an estimate and emphasizing it's not a commitment I'm G to buy into that but how do you become a professional I'd recommend you read this book and you follow all or most of the advice in here because you can't just show up and have all the fun parts of being a professional and say no to your manager and push back on deadlines and you know redefine requirements and things like that without doing all the other things that make you a professional right are you meeting deadlines when they're important are you producing production ready code that doesn't fail are you showing up on time you know are you easy to talk to all sorts of things like that um if ever there were a book Nathan that would prompt us to do something different in our career I think it's this one so we always like to close out the podcast with what do you what are you going to do differently in your career as a result of reading this book what's your takeaway Nathan yeah the the estimate section struck me um I'm now in a tech lead role where I actually have a few Engineers that you know rely on me to help coordinate planning and so this has actually gotten more interdimensional in that I'm not just estimating my own work I actually have to like make sure that the rest of our team is estimating work properly um and so I want to take the I want to take some of the tools that are in the estimation section and see what we can do to become more professional in how we make estimates versus commitments and and put that delineation there and so that's what I'm going to be mindfully implementing over the next few weeks for me it's test driven development Ive like I said I've never given it a good faith effort I have some some data pipelines which right now are written in schala running on Flink I need to rewrite them in cotlin and run them on data flow it's a clean rewrite it is a perfect candidate for doing some test driven development I'm going to do it and I will report back on the podcast how it goes that sounds like a great that sounds like a great way to experiment with tdd yeah absolutely and that's what I love about reading all these books right because we don't necessarily like we said we don't take everything from them you know we we probably forget more than we learn from these books to be totally honest just because we have a a really fast reading Pace but we do get to experiment with these ideas and we do get to just that constant exposure to new ideas and the constant long form exposure to them where we're taking time and and wrestling with them again i' I've seen a million tweets about test driven development but they're tweets and so I I just write them off and say yeah you know I'm not going to do that but to see someone make an impassion defense like it or for it in this book it makes me say you know what Uncle Bob you've had a lot of other great advice in this book you feel this strongly about tdd I'll give it a shot so I don't know if I'm going to come away a big tdd convert but I'm excited to try it I think it'll be good um well the worst case scenario you read a lot more tests so yes absolutely right okay and we also like to close out the podcast with who we would recommend the book to Nathan who would you recommend read clean coder yeah I don't have a universal recommend ation for clean coder but it's if I saw someone struggling with one of the core one or more of the core topics here especially if they felt like they weren't meeting their potential in professionalism or they needed better time management or they needed a good defense for test coverage for struggling in those areas I would absolutely recommend this book I think this to me is s sort of like a good therapeutic book for someone who needs a little wake up call for certain perspectives that they have yeah I felt the same way if you never read it um I used to read a lot I don't read as much these days but I'm sure it's still great there's a great blog called ask a manager where it's like an advice column people write into this woman who's a a professional manager just about kind of like workplace Dynamics and office politics and things like that but she is very much a professional and she always has great advice there was this one I read years ago which really struck me which is about how this woman worked in a really toxic environment where people are you know just always mean to each other and childish and Petty like just she talked about this one co-worker who would like literally just stand in the doorway so she couldn't get through like to bother her insane stuff in a professional environment she said that he was doing that once and like putting his arms out and this lady a professional educated lady bit him like she wrote in saying I bit my coworker like she bit him on the arm so he would get out of the doorway and she's like I feel mortified by this but the manager Allison kind of r back and said like you are in an environment that is completely warped your idea of what office Norms are and you need to you need to get out and you need to change something kind of saying like I don't blame you for biting this guy but like it's insane that you even got to this point I kind of feel like if you are a programmer who's at that point in your career or like you are in such an unprofessional environment that you are thinking whoa something's got to change I'm not being treated I'm not being taken seriously read this book because like I said at the beginning it's aspirational in a way and just realizing there's a way out I think a lot of us wind up in companies and you assume that this is the only way a company could operate this is a great and in similar way you might wind up as who you are in your career and assume that's the only way you can be and if you're looking to make a change read this and I also wrote that I would recommend it to any Junior Engineers who know how to read something with a grain of salt because again this is aspirational it's a vision for what you could become if you're a junior engineer I would caution you against reading this and saying this is the career ideal this is exactly how I will behave myself there is so much great stuff in this book but it is just one vision of what a professional could be but I do love the whole concept of this book that we should be professionals that I think will absolutely stand the test of time okay well great thanks for tuning in everyone like always you can find us on Twitter at book overflow pod find us on YouTube at book overflow pot if you want to engage with us that's the best way either in YouTube comments or tweeting at us we monitor that stuff pretty Faithfully Nathan as always hosts his monthly podcast imperative he where he interviews interesting creatives please check that out and also check out our interview with Mark Richards which just went live what is this this goes live on Monday so last Wednesday is when that should have gone live really fascinating interview and we were so happy to talk with him and yeah like subscribe leave a comment as five stars follow us on your podcast player anything helps we we do appreciate it and like always we are just so excited by the response we've seen and we are very optimistic about this podcast we think big things are in store thanks for tuning in folks and you have a great day f

Channel: Book Overflow

Views: 410

Keywords:

Id: RkxVB1eNdCc

Length: 75min 27sec (4527 seconds)

Published: Mon Jul 08 2024