[00:00:00] Speaker A: Hello and welcome to the Robert Duck Dev Show. I'm Chris.
[00:00:03] Speaker B: And I'm kristen.
[00:00:05] Speaker C: And I'm chiago.
[00:00:06] Speaker A: And today we are excited to have our new friend Chiago with us to talk about the complexities outside of code. Developers deal with a lot of stuff and we're usually thinking about code, but there's things that go on outside of the code that we have to deal with. So we're going to talk about some of those today, but before we get into that, we can review. Kristen, how was your week?
[00:00:27] Speaker B: So pretty exciting on a personal front. And then I'll also talk about some professional did some I did a tree climbing ziplining excursion. I talked about it on the show last year, last October, and I did it again this year. But this one, I did the whole gauntlet of doing the yellow level, the green level, the blue, the black diamond, the double black diamond. So they did their most difficult course all the way through and multiple times I said, ain't going to do this, I was ready to quit. The guy says, no, this gets easier. If you could climb up this last steel rod with wooden pegs in it, you could finish.
So I ended up doing it. But yeah, that was a struggle, but a lot of fun. But I definitely felt it days afterwards in terms of professional front.
So I am still working on my postgres course and I'm at the point where I actually want some feedback. So if you are potentially interested in a course that teaches basically performance optimization of postgres basically I do postgres consulting and it's kind of taking what I do in terms of client engagements to make their server run more efficiently. Do query optimization, things of that nature, maybe schema change suggestions if you're looking for something like that in a course. To learn more about how to optimize postgres, I'd actually like to talk to you. And in the link for the description of this video, I'll put a link that you can send me your email and we can coordinate and set up a zoom discussion because I'd like to have a discussion with kind of what you would be looking for if you're interested in a postgres course. But other than that, what about Chris?
[00:02:31] Speaker A: I was actually really excited when Chiago reached out to me about doing this topic because this was actually his idea to talk about this, because it was really kind of kismet, because last week it was announced that the division that I work for in our company just bought our biggest competitor in the market. And so we're integrating all those folks and all their product and all their customers.
And this is a large team of people, they're as big an engineering staff as we had, so we're doubling our engineering staff overnight. And so there's a lot of complexities outside of code that I'm having to deal with and will have to deal with. So I'm really excited to have this discussion because it's really going to be impactful, I think, for what I'm actually doing in my job right now.
So I'm excited to hear what you got to say about this. Chiago but how about you? How was your week?
[00:03:33] Speaker C: So my week was pretty great. I am releasing some open source work that I have been working on for a long time, and I am just finished off with a lot of tasks that I had been pushing towards the very end parts, and I'm just done with all of them. So I'm really excited. Last thing I was working on was showing terminal colors on the showing hex colors on the terminal. I had to draw a whole spectrum with 240 colors and find a way to show them as the foreground and the background.
Really interesting. It was something that I always knew where it was and how to do, but I had never taken the time to figure out those little ASCII codes they have to do. Yeah. So it was a lot of fun.
Cool.
[00:04:32] Speaker A: Well, it's nice to kind of depart from our normal work days and do something a little different to work our brains.
So I'm excited. Chiago thanks for joining us today to talk about this, and thanks for bringing this topic up. Yeah.
So we're talking about the complexity beyond the code, right? So as developers, we're constantly dealing with complex code, trying to find ways to make it less complex, streamline it and stuff.
And we're good at that, right? Most developers are really good at finding complexities in code and dealing with those things, but then we have complexities in life and the stuff around the code, and a lot of developers aren't very good at dealing with those things, me included.
But we have to and we should think about those things.
So let's get into it. Chiago what is your thinking on why is this important to think about the complexities outside of code? As a developer.
[00:05:48] Speaker C: We love Ruby, right? And we work with Ruby because Ruby on Rails is built on and after after a few years with Ruby on Rails, we start playing with other frameworks and using other gems that necessarily work in the Rails environment and things like that. And we begin to notice that the language itself, it's much more complex than we think, but at the same time, it's that way so that it can be simpler. So being attenuated with the complexities of the language that you're working with is something just that's going to give anyone an amazing extra depth in the effectiveness in how they can work alone, which is something that I really don't see a lot in the Ruby communities. People are usually getting distracted by learning react instead of getting good where they are already good at. And I think that's a real shame. So that's one thing, right?
Do you see?
[00:06:58] Speaker A: Absolutely. I mean, there's, there's the ecosystem around not just Ruby, but just development in general is so vast that there's a lot of things to get distracted with.
And I know my brain tends to work that way. I'll be like, Squirrel, go work on this thing and squirrel, go work on this thing.
And I tend to get bored with stuff that lasts too long and so my brain does a lot of jumping, which is not the most efficient thing to do.
And then I struggle with dealing with those complexities in between the code, right?
And you had talked about when we were having the discussion right before the show, you had brought something out up that I had never really thought about, and I'm interested to kind of hear about this. But you said, take the complexities outside of the code, your life complexities, and turn them into code. Look at them as nested for loops and evaluate them that way, because that's how we're used to evaluating things as developers.
Kind of introduce that concept and walk me through that a little bit. And then we'll do a little exercise here with the editor and take a look at it.
[00:08:23] Speaker C: I remember back when I was, back when I had my first job, I actually started a company.
And so we had a consultant that knew all the database stuff, for instance. And I learned from him that in order to be able to be effective on database, you have to know completely different techniques and styles of writing the SQL code so that it would work fast. Because if I were to try to use my standards, techniques that I was used to, that wouldn't work, that would be efficient. And that shocked me a little, because then I learned that, oh, not only I have to worry about the language that I know, which was at the time, Pascal with the net framework, but I also had to know all this SQL stuff and I had to know some specifics on how to be effective, at least sometimes for more complicated stuff. And those seemed like too many worlds apart that I had to juggle with. And I just thought, oh my God, this is going to be so hard, right? And we got by, we goodbye.
And then there came more languages, and then there came more techniques, and then there came more styles and paradigms and principles and just a lot of people in your head skewing you towards going through different perspectives, which is great if you're building a life as an engineer, because you're going to get all of those. But the problem with that is that you tend to favor the one that you learned about last.
So if you've just been learning about functional, I'm taking a Lisp course right now. It's amazing.
Lisp is an amazing language. I had no idea it was so beautiful.
I was used to concepts, but I had not really used the language. And it's interesting because it invites you to thinking in different ways and then you want to expose part of those thought processes as your code.
And that the person who's reviewing your code on the company he's taking a class in.
And for you, we sold five years ago. We should all be learning functional. And we completely ignore that. They've been here since the 70s. It's not new. It's just new for me, so I'm excited about it's. New for them, so they're excited about it and we're fighting why.
And that gets in the way of happiness when you're a developer. It just gets in the way of having a happy team that everybody agrees to work together.
[00:11:03] Speaker A: Right?
[00:11:04] Speaker C: And it's hard to do those things even in the team, even within the code and just in conversation. That's where Agile comes in and helps us by allowing us to adjust as we fit based on some regular basic principles on how we're going to deliver. And so there's also a layer in the industry where a lot of people tend to overly structure agile developments and that tends to create more problems than it solves for developers. And the developers feel it and they're trained to optimize for things and then they're having to deal with an environment that is not optimized, or at least it's not optimized to their perspective, which both can happen.
And that's something that slowly erodes the ability of the team to work together because then you start developing patterns where you're just more defensive about the way they write your so that's a big one.
[00:12:18] Speaker A: Yeah, you bring up a good point about patterns too. And I think there's a thing that I've noticed, chris and I often talk about how long we've been doing this and that we keep seeing the pendulum swing back and forth on all kinds of different things like dumb terminals and smart terminals and methodologies and Op and all this kind of stuff. And I guess from your bio, you've been doing this a couple of decades now. So I think would you agree that it's kind of hard to see those kind of patterns early on in your career? Because I think you're so focused on exploring and learning that you're not really paying attention to those kind of patterns overall. And it takes some time to get the ability to kind of step back and see those patterns develop over a long period of time.
So were you kind of aware of those things early on in your career or is it something that you had to kind of wait to be able to see those patterns?
[00:13:21] Speaker C: This is a sensitive topic because the true, cruel, brutal honesty is that everybody has to go for those things and everybody has the same ideas. Oh, it's me, I'm the problem. I'm the one who doesn't know how to deal with this. 300 different words that people are juggling and they seem to have no hardship with. And then you begin to notice that it's very much like going to a different country and having to listen to people talking about the actors in that country, which you know nothing about them, you know nothing about their lives, you know nothing about the lives of the actors in your country. Why would you care about right. And the politics and everything. And you're just, oh, it's not about me, it's just the way things are. So it takes a little while, but yeah, quickly, yeah.
[00:14:16] Speaker A: Let'S take a look at and you can kind of walk us through because I do good with diagrams and writing things on the whiteboard and stuff. Let's take a look at this at kind of walking through your idea for, for loops as working on complexity of life things. So we've got a little nested for loop here.
[00:14:36] Speaker C: So the nicest thing that you can do about a loop if you're teaching programming to beginners, is you can think about how you're going to draw all the cards from one to six or something like that. So you can do one, four, and that's its own thing. And then you can also do an array and you learn how to connect those two ideas of the ray and the four.
Something that you can also do is that you can work with recursiveness and you can use the stack of the language as that array, which is something that you kind of have to learn that it's there.
People teach you how to do and they don't really teach you about the details, but later on we find out that it's there. And what ends up happening is that the code is not just those little loops. The code is a little bit more. And if the code was small, if it was one for loop one line of code, one for loop, one line of code, you could manage four to five nested loops easily in your mind.
But the problem is that it's not just that. So when you're studying algorithms formally, you're thinking that, oh, one of those four loops is going to go way out of hand at some point later on, and that's going to cause the problem. Okay, so I should add a little extra piece of code right in the beginning that checks.
If that number is not too high, it's not above a certain number because you've decided so that it warns the developers, hey, there's something happening. Maybe you want to check on something there. So let's say you write that code that way. Then the person who's doing your code review, he's going to look at that. He's going to say, oh, this is useless. No, it's there for a reason. It's there for a reason because you agreed with this person, that person, that other person that is going to come this way. And this is how you can deliver the code the fastest. So they're pinpointing on little trivial details that doesn't really change anything. And the reason why they're doing that is because the GitHub interface love GitHub. The GitHub interface invites you to comment on every single thing that you see.
So why wouldn't you?
And that creates stress. Why?
Why are we doing this to ourselves as an industry? And honestly, I have no answer for that. Yeah, that's one way to look at it.
The other way is that there's more. There's not just the for loops, there's just a lot of lines of code that are going to be in between and that's going to make the code complicated and you won't even be able to understand it later. So there are many different ways to break apart that code.
And then we have life where you go through some of those complicated things and then there are many ways to break those.
And we need all sorts of strategies to be able to figure those out. And the people around us need to be aware of those strategies. They need to agree that those strategies are the best, otherwise it's not going to work.
[00:17:45] Speaker A: Yeah, well, buy in is important, especially when you're going through change. That's one of the things about change management, is you can tell people how they're going to do things, but it's much easier if you can get them to almost have it as their idea and buy into it, then they'll do it themselves.
So yeah, agreement and consensus is definitely a big part of that.
[00:18:12] Speaker C: Which is so hard to do when you're working with multiple remote teams, working on the same code base and multiple code bases that all interact with each other with microservices because somebody had that idea.
Damn it, I hate the way they do microservices. I hate it's. Such an interesting concept. Such an interesting concept.
[00:18:34] Speaker A: Oh, it works great on a whiteboard.
[00:18:37] Speaker C: Yeah.
[00:18:38] Speaker A: But.
[00:18:43] Speaker C: I always look at this kind of problems as this oh, if this wasn't a whiteboard, if this wasn't a piece of paper, you could understand it. But in practice it's not.
[00:18:50] Speaker A: Right.
[00:18:50] Speaker C: So why are you planning for things that way?
And I can't find an answer to that question other than it's not just someone's fault. There's nobody evolving skimishing against the company or anything. No, it's just that thing JWT sounded amazing. I mean, look at all the things that you can do that you never have and never will. Right. And I've seen a lot of companies around that time just changing their authentication token to JWT and you're asking them why, and then you're asking people basic things about what JWT can do, like the whole encryption thing. You can crypto hash in it and stuff, and people have no idea that the thing is there. They just think it's more secure.
[00:19:36] Speaker A: Right.
[00:19:37] Speaker C: It's not.
[00:19:40] Speaker A: Yeah, and I think it's just people have good ideas and if you sit and think about things, it's great to work stuff out on a whiteboard. Sometimes it's going to work in reality, and sometimes it just isn't. Like, I'm sorry to say, that's kind of how I feel about cucumber, but that's a different show.
[00:19:59] Speaker C: We have to talk about cucumber.
Yeah. Jim BDD. Check it out.
[00:20:06] Speaker A: Yeah, well, I agree with BDD, but later.
[00:20:09] Speaker C: Yeah, talk about cucumbers from other time.
[00:20:12] Speaker A: Yeah, right.
All right.
So if you were going to deal with a complexity outside of code, I'd be really interested to kind of go through an example.
Give me an example of how you would deconstruct real life complexity into a code based thinking.
[00:20:38] Speaker C: Let's talk about something that happens way too often in the company that I'm working for.
If you need anything related to access to a different code base or anything like that, you can call the day off because you have to send it to a different team, and they have to give you access for that. And you're just not going to be able to get anything done today, so you can call the day off. So if I come to work and once a week I need something else, that's one day that I'm not going to be working. I'm going to be just get the meeting, ask for that thing, and then nobody expects me to do anything.
[00:21:18] Speaker A: Right.
[00:21:18] Speaker C: If you had a sleep statement with 24 hours around, that four on those four statements, you would be insane. But that's exactly what we're doing.
[00:21:32] Speaker A: That.
[00:21:36] Speaker C: Just inside that four somewhere. So when it gets to those scenarios where you need to wait for a whole day, where one person needs to wait for a whole day, that person will not get anything done. And that is, sadly, what happens where I work. It's not that they want to do it, it's just that it ended up becoming that way.
That's upsetting.
[00:22:03] Speaker A: Right.
[00:22:05] Speaker C: Does anything like that happen with you?
[00:22:07] Speaker A: Oh, it happens with us quite a actually, because we're a global company.
There's a division in Poland that we work with, so if we have to ask them a question about what they're doing, we can't get an answer back till tomorrow.
[00:22:23] Speaker C: Right.
[00:22:24] Speaker A: So there's huge delays in communication, and that's problematic because we get this. Exactly.
[00:22:32] Speaker C: Yeah. Imagine trying to do a podcast that way.
[00:22:36] Speaker A: Yeah, I know.
[00:22:40] Speaker C: Creston, you're often quiet. You're awfully quiet. What are you thinking?
[00:22:46] Speaker B: No, I'm just listening.
[00:22:48] Speaker C: Absorbing.
[00:22:51] Speaker B: With regard to this, I'm a little bit different in that I don't have as many people I work with, so my delays aren't necessarily internal to the organization, but it's interactions with clients. So I have to send a communication and need to wait for something to come back. But this brings an interesting point of Asynchrony and how Asynchronous programming lets a lot of stuff happen. So as opposed to just sleeping one thread, basically you send something off and then you do a bunch of other stuff on the side until things come back.
And that's what I have to do with my client communication because I have no control over when they'll get back to me with stuff. So I basically just send it out and just wait for things to come back to me.
[00:23:45] Speaker C: Does it sometimes feel frustrating they have to remember that stuff for so long so they can continue the conversation? For instance.
[00:23:59] Speaker B: Sometimes it's a little frustrating if I have things that are hanging out in a waiting state and I'm waiting for something for them to complete.
It would be great to be is.
[00:24:10] Speaker C: Going to look bad on you if you delay.
[00:24:12] Speaker B: But it's not on me. They're the ones that haven't gotten back.
[00:24:18] Speaker C: Yeah. I get a little frustrated sometimes because I want my delivery to look good, but sometimes because of outside sources, that can happen and it happens. Yeah.
[00:24:34] Speaker A: Well, I also get frustrated with it with because there's a lot of stuff when you've got a lot of different projects going on and you're working on a project and you have to ask somebody about this and get some feedback on this thing you're working on. If you have to wait and jump to some other project. In the meantime, all that brain power for context switching is wasted. And then at some point you have to go back to that other project and get your brain back into it. So you're wasting more energy and time because you couldn't get an answer to keep pushing that project forward.
So that's where I get frustrated with things. Yeah.
[00:25:15] Speaker C: I have to work on two things.
When they're related, it's great. When they're not related, it's awful.
[00:25:23] Speaker B: Yeah, that's the thing is I get up to a certain point and maybe I send something to a client waiting to hear from something, or it doesn't have to be a client. I've started a job, and I know it's going to take 1216 hours, some amount of time to get done, and then I can go back once it's done its thing and I can finish up. But the thing about it is, as you were saying this, Chris and Tiago said his thing. I think basically my brain maybe has a four core processor, so I can only do four threads at once.
So if I get to the point where I have things going in parallel, even though I'm not thinking about it, I know I can't put anything more on my brain because I then won't be ready to deal with the other things that are happening. Like I can't paralyze myself to an eight core or a twelve core processor because it just won't work.
[00:26:22] Speaker C: It's like garbage collection. Right. Yeah.
[00:26:25] Speaker B: I basically have to step away and just say, all right, I can't put another thing on my processor bus. I got to just wait till this thing comes back. Then I'll just continue because it is an incentive. I want to keep working, but I know once I have so many things in parallel, I'm like, okay, I can't start another thing. I just got to do something else. Take some time, take a walk, whatever, wait for this thing to finish and then I can continue working.
[00:26:59] Speaker A: How do you mitigate stuff like that, those kinds of situations? How do you approach the thinking to start moving past that? Or I mean, you're never going to get rid of things like that, right. Life is full of weird crap that happens and things that are frustrating. I mean, that's just life.
But there are things that you can do a lot of times to kind of mitigate or minimize the effects of that.
So how do you do that?
[00:27:32] Speaker C: When I'm the manager, which not always, I like there to be two meetings per day.
The stand up early in the morning and then a quick get together, something like 15 minutes, kind of just leave the room open. Around that time, you come in, you say hi to people and check if anybody's going to need you for anything, if this or that, so that you can have that extra time where you're going to be working on more focus things. And that's not something that you can always do because sometimes the team structure is not going to accommodate that. But that is what I try to do.
[00:28:15] Speaker A: Right.
[00:28:20] Speaker B: I was going to say in terms of sorry. Go ahead. Sorry, my bad.
[00:28:24] Speaker A: So it sounds to me like your big thing is just improving communication so that people can make sure everybody's understanding the same thing and just communicating better.
[00:28:38] Speaker C: Yeah, just creating more opportunities for communication.
It tends to help.
The problem is when you don't create those opportunities, so that because that person was working a little bit more on that thing, or because they took a little bit of a bigger break on that time, then they missed that person, and then they're going to have that feeling of, oh, I need training for more hours. I need more context on this. I'm lost.
What you want to avoid is you want to avoid every single person in the team for feeling that, of getting that feeling that they're lost. If they're having that feeling, then that thing is going to eat off the quality of the product that they're delivering. Why would you do that? Logically. Right? Yeah, exactly. And then we see that a oh yeah, a lot.
[00:29:31] Speaker A: So what were you going to say, Kristen?
[00:29:34] Speaker B: No, I was going to say in terms of mitigation strategy, I mean, this may be going back a little bit, but in mitigation strategies of when you have multiple things in parallel, what can you do to minimize it? Disrupting your workflow is I don't do this, but I just thought it might be a good idea is actually writing down and documenting kind of where you're at for an item. Like if you are in the quote unquote flow state and you've just completed something, you send off that task, maybe document where you are and what the next few steps are. Once it comes back to you, 24, 48 hours later, whatever it is, so that you know when it comes back, then you'd be ready to jump on board and just do what the list tells you to do, as opposed to having to remember, what the heck was I supposed to do with this?
[00:30:26] Speaker C: So if you were going through a labyrinth and you had checked some of the rooms, you would write down a backtrace of where you were last time so that you know which places you've already been through and you can get up to speed faster.
[00:30:42] Speaker A: Yeah, as you're saying that, I'm thinking about the fact that I think support teams are really good at this because they use a ticketing system and they document all the steps that they're doing. Well, good support teams anyway.
They'll document all the steps that they're doing because they know that I'm going to have to send back a question to the customer and put this aside and go work on 15 other tickets. So I got to know what I'm coming back to when this customer finally decides to respond. Seven days, seven months, seven years later, whatever it is, because a lot of times, especially in bigger businesses, support has to deal with, oh, this is an emergency right now. Okay, well, let me ask you this question and then it's not an emergency again for 15 days, and then all of a sudden it's an emergency again.
So they're really good at that. And then, Chago, you said the word backtrace, and that made me really think about maybe that's what developers need. They need kind of a life back. Trace some way to keep track of that.
[00:31:53] Speaker C: We need to make a startup for that with AI.
[00:31:55] Speaker A: Yeah, there you go.
Because we're used to reading those and that's how we figure out what happened in our code.
[00:32:04] Speaker C: Yeah, normal people call it checklists. That's what they call it.
[00:32:09] Speaker A: Yeah, but normal people, we call normal.
[00:32:11] Speaker C: People, we call it Durh. With devs, that's what we do.
It's hard.
You could reflect that as saving the state of where you were in the process on a piece of paper. Sometimes I like paper.
If I write something down somewhere online, I'll tend to forget where it was. So unless I have a very clear structure of things that I'm keeping up with, so then I have to deal with the complexity of keeping that up.
And the company doesn't always accommodate that. And I can't really get bogged down with enjoying one thing, because first, maybe that thing is going to go away. Second, maybe that thing is going to get rebranded and they're going to change everything. I'm talking about you, Skype.
[00:32:56] Speaker A: Right.
[00:32:59] Speaker C: And so the sad thing is that we have to just go back to our. Biology classes and realize that we are the most adaptable, horrible creature on this planet and we have to strive to make the best out of it.
[00:33:14] Speaker A: Right?
Yeah.
You kind of touched on something a little earlier, too, that I've been a big proponent of and I think is very lacking in a lot of dev environments, especially larger ones, and that is communication. I think devs typically are very bad as a whole at communicating. We talk to computers. We're not as good at talking to people a lot of times, and I think that that's a skill that we should probably be pushing more for devs, encouraging them to no, you don't think so?
[00:33:50] Speaker C: I don't think so, really? But I don't think so anymore.
So my family moved to States a few years ago, and we look at life as a decision making tree, as an everlasting decision making tree. And I was like, okay, so I can fight the system to get back to States, or I can wait and go with the family green card.
What do I do in between? So I went on to get a doctor's degree because that's probably the last time they're going to have the time to do it, so I'm going to do it. So I went back to just studying more and just taking extra classes. There's a bunch of stuff from Harvard and MIT and Stanford online that everybody can benefit from. There's a lot of great stuff on programming languages. I wish there was a whole course on Ruby, but those are great. And what we end up seeing is that all the sciences pretty much studied the same things. It's just that they have extremely different names for those. And computer science in particular. I don't mean computer science, but I mean modern, realistic and effective development, much like focusing on Ruby, on Rails, instead of trying to go for all the shiny JS and backend things that are out there.
Focusing on things tends to be a great thing if you're trying to get away from having too many things to deal with.
What was I saying? I lost myself.
[00:35:29] Speaker A: Why we should communicate more for developers.
[00:35:35] Speaker C: Anyway, so why we shouldn't communicate.
It turns out that the way we've actually evolved.
I've struggled this a good part of my life because it looked like when you're growing up, you're kind of learning how to be a person.
You kind of tend to see that a lot of people are spending a lot of time, mostly women.
The plays tend to be around social communication. So you tend to see that a lot of people spend a lot of time investigating how other people behave in certain situations. So that's why you have the TVs and the magazines about the life of the royals and the famous. And that person did that. She said what? Oh, my God. That's inadmissible.
And then you create the extra layer of complexity in society, which is that you have to be aware of what all those different actors that I never hear about, some people follow those spectacularly and they have to be aware of everything that's going on in their lives and then you don't live your life for God's sake. Right, but most importantly, we get into that idea that other people follow that stuff too.
I spend a lot of my time studying, I spend a lot of my time watching talks, watching conferences, that kind of stuff. So in my head I don't understand how people can spend so much of their time to social stuff. But the reality is that our brains evolved to both manage complicated hunting scenarios where we have to make quick thinking and calculate little things here and there all the time. So a lot of geometry and it also evolved for us to be able to retract and to be calmer and to live in society.
Actually, if you take a parallel view, they're having studies about this, all the primate species out there, and you see specifically how the size of their brains and how that thing or that thing size their arms, whatever other things. You can see that there's a direct correlation between certain parts of the brain and the number of individuals that they can have in the same tribe.
The problem is you're using the same parts of the brain to compute complex, to compute any sort of complexity really.
But the stuff that you need to focus on so if you're focusing on the code, you are not going to be as socially responsible responsive as if you were not focusing on the code.
And then you're going to have one of those context shift moments where you need some 15 minutes to get from one thing to another thing and then you need 15 minutes to get back. So if you account for that and you want to have free conversations with your developer during the day, you have to account for the fact that you were removing three times 45 minutes from his day just for 15 minutes conversation. So what you're thinking is an hour is actually three to 4 hours and then you wonder why the code becomes messier the more you talk to developer. Well, it's because you're making them do context well.
[00:39:00] Speaker A: And I was earlier just bitching about context switching and how it's frustrating. So. Yeah, I get that. I think what I'm talking about is not as much conversation as communication and that can be asynchronous.
[00:39:17] Speaker C: What I kind of think works is that you just put the place where people can talk, right? So there are times that people are going to be together and there are the times that people are going to be asynchronous and those are the rules. So people can follow them and agree and if they don't like them, they can adapt. But when there are no rules well.
[00:39:37] Speaker A: Yeah, and I think that's a good point, too, is that I've come into a lot of situations, especially at larger organizations, where they don't have good processes and policies in place to deal with this stuff. And so it's a Wild West show, and every developer is kind of doing their own thing the way that they want to do it, and they've got their own little Google Docs folder with the way they like to document stuff.
And so I think one of the big things to help mitigate this is kind of standardization, where if I go and look at your code, that's one of the big reasons, I think, that things like and I know there's a lot of people that don't like this, but Linters are helpful in that on large teams. Because if I go and look at your code, I know what I'm looking at, and I understand it, because even formatting is important. I can skim it faster because I know how things are laid out.
But people get all been out of shape about, oh, we hate using linters, we hate rubocop because it forces us to do well. Okay, but have a meeting. Decide what you all want to do, and everybody do the same thing, and then it's a lot easier to you don't have to spend as much time conversing to communicate the stuff you need to communicate.
[00:41:04] Speaker C: But at the same time, you kind of have to go back and reiterate. That thing once a month ish so that people are always on the same page, because there's going to be new people coming in and they're going to be people coming out. And much like the example that I gave you, you're going to a different country and realizing that people are in the middle of a big political conversation or a conversation about what those actors are doing and their lives and this and that, and you're just like, I don't follow that. I don't know what you're talking about. It's not that I don't understand the words you're saying. It's that I don't know who these people are. I agree she is a bee, but I don't know who she is exactly.
[00:41:44] Speaker A: I mean, I guess if you're a journalist for that thing, it's something you pay attention to, but devs not so much.
[00:41:51] Speaker C: And then when you look at things ecologically, I love the word ecosystem, you realize that people are going to mimic behaviors and people are going to do things that are more cost effective than things you are going to do. So for instance, you can see that there's a lot of scammers who are sending you messages that you want to reply to.
Why those messages are tailored to get you to engage. They're tailored to get you enraged. And then what happens? We have social networks that are focused on that, just trying to get you angry, just trying to come back.
If you get distracted with social network, for instance, while you're working with code, you're not going to be able to come back with the same speed that you came back. And just having your phone around while you're working is a huge waste of time. So I was of a more strict ruling that people should leave their phone turned off while they're working in things complicated like development. And I still like that rule. I still use that rule with myself. And I just think that we are there for a few hours. You have to be respectful of people's times because that's when the opportunities for more things arise, even if those things are just keep doing good at the company, and if those things are just getting yourself ahead and preparing yourself for promotion the company, you have to be there to be able to do that.
Yeah, and that's I see a lot missing people.
[00:43:31] Speaker A: Right. And I think that's one of the big complexities outside of the code, too, is that we use slack at our company and that god, I'm starting to hate slack because it's just constant ping, ping, ping, ping, ping.
What I've started doing is just putting it to sleep for four or 5 hours so I can get a consistent brain on something that I'm working on and not be tempted to look at that thing every 15 minutes. I just had to shut it off because while it's great at communicating, it's also really bad at interrupting.
And I think that's what you're talking about with the social media, too. You can fall in that same trap with Twitter and Facebook and all those social media things. You just get stuck on all this pinging back and forth.
[00:44:28] Speaker B: Now you've got double the instance.
[00:44:32] Speaker C: Go ahead.
[00:44:34] Speaker B: I was saying now he has double the developers in his company.
[00:44:37] Speaker A: Yeah.
[00:44:39] Speaker C: So you take a look at, for instance, here's a very classic case.
Let's say you have a girlfriend and she sees that you logged on to that app that you used to communicate with.
Why did you log in the app in that particular time? It was because it was through that thing that you had to go send a message to somebody, your mother, whoever, and you shut off the app in their understanding, you were talking to people during the app because no, you were not. You were opening it, sending a message and getting back and do the things that you, the responsible person, has to do. But they're thinking something else much in the same way that's the way that your bosses look at you when they see that you are away from slack between this time and that time. Well, I was drawing the sketches for the extremely complicated thing that you want me to do. So I was not touching the mouse.
Right?
[00:45:41] Speaker A: Yeah. What do you want from me? I mean, do you want me to think and work or do you want me to play with have the camera.
[00:45:45] Speaker C: On so you can see me, I don't mind. And I'm not complaining, I'm not saying that. Oh, no. But it's just that sometimes you are really doing the thing you're supposed to do. You're just doing the right thing and people get a wrong impression because of what they saw, right?
[00:46:02] Speaker A: Or what they think they saw.
[00:46:04] Speaker C: Yeah. And again, we are extremely wired for engaging with other people and engaging with things. So if those things are bullying our attention, those are processors that we're losing that we could be using to focus on the thing we're focusing on.
So that's that you were going to say something creston?
[00:46:26] Speaker B: No, I was just following up with what Chris said.
[00:46:29] Speaker C: OK.
So it's interesting because people seem to understand this at some level. People seem to understand, oh, when you're growing up, someday your father gets home and he's tired, your mom tells, oh, he's tired, don't go to him right now. People understand those. It's just that when you are busy trying to work, if you say, oh, I'm tired right now, people get a different understanding of that. So you have, oh, no, I'm actually working, but this and that, and then it becomes a whole big conversation.
Why make that a big conversation? So what we end up developing is little strategies to saying little comforting things that justify what we're doing at the time so that we can more easily navigate. And sometimes that bothers people because they're thinking that, oh no, this person has to be on the computer.
[00:47:28] Speaker A: Right? Well, this kind of always being connected thing and not having just some time to sit and be with the problem is problematic. I mean, the distraction factor is way different than it was when I started developing 20 million years ago.
We didn't have that.
[00:47:52] Speaker C: Say you're waiting for somebody to ring the bell because there's a package coming and you're waiting to ring the bell. You're coding, but you're waiting to ring the bell. You need to keep one of your processors available, just channeling the general noise because you have to be aware for the cues that there's going to be something because you may be distracted. And it's pretty much the same thing for everything else.
It's not a problem that has a solution too, because it's so intrinsic in the way that we are. But I think that what helps is that we have agreed upon times that we get to talk that we have agreed upon times that nobody's going to talk to us because we're busy.
Right. I can't plan ahead and go spend time with people if they make me aware earlier in the day so that I don't plan against that.
[00:48:40] Speaker A: Right, well, and I think one of the things that I'm really getting out of this conversation, I'm saying this because I'm thinking about what I do on a daily basis, is that the distraction levels end up causing a lot of the complexity that we have to deal with and we need to reduce our distraction levels. And you brought up the example of the doorbell. I'm waiting for the doorbell and yeah, I have to keep kind of a one ear open for things that are outside of me. But I think we've gotten to a point today that wasn't like this 25 years ago with slack and stuff and remote work where I have to keep four ears open for four different communication channels and I don't have anything left to put into concentrating on the problem I'm concentrating on. So I think shutting down some of those communication channels, not completely, but have times where I'm spending this hour working on project and I think that will fight a lot of the complexity, at least the stuff that I'm dealing with.
Because I probably spend half of my time context switching every day.
[00:50:05] Speaker C: Which is what exactly? What? I just gave you three to four conversations and you're half the time busy doing non work stuff. And the thing is, deep in yourself, you feel guilty about that.
You feel guilty when that happens. If you really care about your work, you feel guilty. If you don't care about your work, you feel nothing, you feel fine.
[00:50:25] Speaker A: Well and if you don't, then you're probably the one causing a lot of those distractions in the first place.
[00:50:32] Speaker C: The shitty thing is that the way you feel about that, it's really reflective of the things that you listen to, the people you listen to and the ideas that you allow to get in your head. So if you're watching, I'm talking about new developers now, which I wasn't to this point. If you're learning about development as this thing that you're going to learn in five days and you're going to get this big salary and you're going to have this big life and you're going to be traveling all the time and you're going to have time for your family.
No go drive your right.
You're better off you're going to be able to travel all you want.
But there's a lot of people who are coming in with that mentality and I don't think that's a good thing. I'm not saying that I don't want new developers to come. I think it's amazing that we have new people coming. What I think is that people are coming in with a mentality that is not aligned with creating and being a part of a cohesive team and helping the team and helping each other and helping one another so that everybody looks good and the product is delivered and the clients are happy and the clients stop complaining to support. So the clients stay with the software at a level that you can't even see just because they're happier with the way that the software is catered to their needs.
[00:51:58] Speaker A: Right?
[00:52:00] Speaker C: So a lot of things happening there and we just don't really get to experience that whole layer. So because we don't experience the benefits of having the good software working. And a lot of people have never seen good software before.
So we just act on those memories that we have in our head and those memories of the voices that are talking right now sometimes are trying to sell you an idea that our lives are easy. They're not easy. They're not easy for us. We can make them easy because we're dads. But there's a lot of complication that we have to juggle with every single day and people don't really see it.
Yes, and that's true and that's everywhere.
But I think that what's happening is that this new generation of people who are being trained in that kind of align better with the way that things tend to create the rigidity in the first place.
And there creates these environments where you have 300 developers working on the product and nothing's really moving because people keep stepping on each other's toes and they keep fixing the bugs and they keep creating bugs for one another to fix under those circumstances. So people who really care about their code and their work that they're doing, they feel frustrated, they feel demotivated. And the people who don't care, they feel fine. Yeah. So what are the incentives that the system is creating?
[00:53:32] Speaker A: Right? Well, yeah, there's a whole thing we're going through internally about accountability and ownership.
It's some concepts that we're really trying to instill in people because there's been, I think, a generation of people who don't really understand that very well and what that means and what that does for them. And they don't understand that a rising tide floats all ships. So if you're helping the team, you're helping you. And that's probably not a really popular way of thinking, but I've never been a really popular guy.
[00:54:12] Speaker C: So it's if you listen to Dave Thomas and Marty Fowler and Ken Beck and Uncle Bob, they're all on the side that agility should be a thing, should be more of a sacred what would be the word? Covenant that people have and that they have these structures that are really thin and sensitive and they could easily break if people don't watch out for those things. And those are the things that allow the team to be productive. And sometimes because of management, that fades away. But if you look at it from management perspective, they're having something in front of them that looks like a problem. Just like we see code, we see a problem and they're moving things around to try to fix things. So is management really that wrong?
[00:55:11] Speaker A: Yeah. And I think that's kind of the eternal battle, isn't it?
[00:55:15] Speaker B: Yeah.
[00:55:15] Speaker C: And then that never ends. So we'll never run out of jobs and people are creating more complexity right now with the help of AI and that's just amazing for us.
[00:55:25] Speaker A: Right, exactly. So job security something to be said for that.
[00:55:30] Speaker C: Yeah. You just have to know how to code. Right?
[00:55:34] Speaker A: So, Chiago, we're running up on time, but thank you so much for joining us.
I really, really enjoyed that conversation.
Sometimes I like to talk about things that aren't just code and developer stuff, and I really enjoy kind of psychology and team synergies and team environment stuff. So that was a really fun conversation for me, and I really appreciate you bringing that up and joining us to share with us about that.
So thank you guys for watching.
If you have any ideas about what you think about how to deal with the complexities of your daily dev life outside of the actual code, let us know in the comments below. I'm really interested to find out what your thinking is, even if it's completely different from mine. I like to hear different thoughts.
And we will be back.
[00:56:29] Speaker C: Strategy is about coding review, code reviews, so anybody could comment on that.
[00:56:33] Speaker A: Yeah, code reviews. What do you guys do about that? Because that's a thing that I have to do, and I need to call people. Yeah, I need to figure out how to do them better.
[00:56:44] Speaker C: I sometimes call people and then they approve because then they can see, oh, that's why you had to do it. Okay, I'm not going to. Right.
[00:56:52] Speaker A: We'll be back next week with our friend. Coda is coming to join us. We're going to talk about burnout and how to deal with burnout. So that'll be a lot of fun.
[00:57:01] Speaker C: That comes with complexity.
[00:57:02] Speaker A: Yeah, exactly.
The after effects of this show we're going to talk about next week.
Yeah, really fun. If you did enjoy this, please like and subscribe. That really helps us grow the channel.
The best thing you can do for us, though, to help us out is to tell all your wonderful friends about us and share some links and show them this wonderful conversation with Chiago.
We will be available on
[email protected]. Or you can reach out to me on Twitter, X, whatever the hell it is now at Duckydev show.
And you can also join our discord and say hi to us there, which.
[00:57:52] Speaker C: Is called the Duck Pond. Yeah.
[00:57:53] Speaker A: Join us on the duck pond.
It's really fun.
So still growing, but having fun doing it. Chago, thank you again for spending time with us. We know time is a gift, and we very much appreciate the gift of.
[00:58:10] Speaker C: So I thank you. If anybody wants to keep talking about complexity and anything related to what we talked about, you can reach me out on Twitter or X. I still call Twitter.
Yeah, my link is here somewhere. Should be.
[00:58:27] Speaker A: Yeah, we'll put it in the show.
[00:58:28] Speaker C: Notes.
[00:58:31] Speaker A: And we will see everybody next week. All right? And until then, happy coding.
[00:58:39] Speaker B: Happy coding.
[00:58:40] Speaker C: Very happy coding.
