Ruby Rogues

Our original panel podcast, Ruby Rogues is a weekly discussion around Ruby, Rails, software development, and the community around Ruby.

Follow

Managing Emotions When Programming with Ryan Ong - RUBY 597

Guests :

Ryan Ong

Hosts :

Published : May 31, 2023

Duration : 50 Minutes

Show Notes

Ryan Ong is a software engineer at Buoy Software. He joins the show alongside Dave and Valentino to talk about emotional programming. He shares how he got into Ruby on Rails and dives into creating and monitoring code bases. They talk about handling their emotions when they are coding and how to minimize the stressors around.

Socials

Picks

Dave - GO WITH RUBY
Valentino - Livebook's big launch week

Transcript

DAVE_KIMURA:

Hey everyone, welcome to another episode of Ruby Rogues. I'm Dave Kimura and today on our panel we have Valentino Stoll

VALENTINO_STOLL:

And now.

DAVE_KIMURA:

and we have a special guest Ryan Ong.

RYAN_ONG:

Hello.

DAVE_KIMURA:

So Ryan, would you mind giving us the top level introduction of who you are and kind of what you've been doing and why you're famous and all that good stuff?

RYAN_ONG:

famous, yeah. Let's see. I am a staff software engineer at Buoy Software. We do donation management systems. There's only one other company that makes them, so we're in a good place to do better than them. I've been a programmer since I was 12, putzing around with PHP and then slowly going into Ruby. I've worked at Pivotal, Focus Eyes, really specialized in product and engineering management, whatever that is, or development. Making dreams come true. best way to put it. Yeah, and that's my history of programming, basically. Beating teens and building them from scratch for the most part.

DAVE_KIMURA:

Awesome. And so how long have you been doing Ruby?

RYAN_ONG:

I've been doing Ruby for since I was 22. So 14 years now, basically. Yeah.

DAVE_KIMURA:

That's a good amount of time. So did you start with Ruby or did you dive into Rails first? Because I think Rails came out, yeah, a little bit before that.

RYAN_ONG:

Yeah, Rails was at 2.1 or 2.2 back then. And I joined a company as a technical advisor, technical assistant, supposed to do emails and stuff like that. Then he found out I could program and so he paid me to learn Ruby on Rails. I worked on this little app. Really lucked out.

DAVE_KIMURA:

Yep, that's awesome. So which one do you prefer more Ruby or PHP?

RYAN_ONG:

PHP

DAVE_KIMURA:

Ha ha.

RYAN_ONG:

back then was a real mess. Your error messages were unlegible. They didn't have good debugging solutions. Your IDE options were limited. You had like Zend IDE. And then the community, as you know, the most important part of any language is pretty splintered. There really isn't one. You have a good support community, but there's no good library community for the most part. I think that's

DAVE_KIMURA:

Mm-hmm.

RYAN_ONG:

changed with Symfony and a couple others. Rails like software have come out, larval and stuff like that, but when I was around, there wasn't much.

DAVE_KIMURA:

Yeah, awesome. Well, today we had you on and I think our main topic is emotional programming or something of that nature. Would you mind giving us the high level overview of what that is, why it matters and why we should adopt something like that?

RYAN_ONG:

Yeah, definitely. I feel like as programmers, we're really good at the logic of things. We're really good, really heady people, and there's a real joy in exploring heady problems. But at the same time, when we only think about how to solve the problem, sometimes we don't do a great job of communicating it. We live in our own head and don't have this other idea. And when we're programming, we'll also... It's a team experience, you know? Usually you're working on a team with other people. And you feel things when you're writing code. And these can really influence how you choose to write code or just how to respond to code. I think we can start off with the idea of writing code. When you're writing code, you can feel when it's bad. You feel bad. You feel angry. Like they say you write with anger or code with anger. I think that's a good example of you're upset at the way things have been designed and you really want to change it. And the anger is the impetus to actually put something forward. And being aware of that is important. I think you can also get out of hand sometimes when you get so focused on trying to make this thing better, you don't get the work done. And sometimes you really just have to bite the bullet and just be OK with this bad code because you have other deadlines in mind. And being aware of how these things, being aware of where you're at while you're responding to this code is important. I think on top of that, You can tell how other, or at least I can tell how other people were feeling when they were writing the code, when you're reading someone else's code. If you've ever joined a project that's kind of been stressed, they've been a startup and they've been doing rounds and changing and pivoting every three to four months with short deadlines, you can see how uncared for the code is. And it doesn't feel good. to work in that environment. It's just a little stressful and everything is disorganized and stuff like that. And that makes it hard. And it's nice when you can tell when a code base is loved and cared for. Because it's easy to move around, everything is logically ordered, everything makes sense. There's a general level of consistency in communication and just like small little things and niceties throughout the code that you can tell. And I think it's nice to be aware of how we're responding and how we can not just, not how we're just, we're reacting, but how we choose to respond to it. And I think that can really affect the way we choose to build a code base and also how we work with each other.

VALENTINO_STOLL:

Yeah, you know, I've just ran into this same thing recently where I was looking at a code base that I was looking to adopt like a new library and looking at the code, I was just like, you know, it was satisfying to read through, made so much sense, you know, everything was where I had expected to be and it made me wanna use that library more, right? And there are some libraries will open and be like, you know, it's popular, but... it looks like a mess. And it makes me not wanna use that library and I'll prefer something a little more simplistic or maybe it's more structured a little better. And it really is a feeling. And I get that too, just like diving into new code bases like you're saying. And that feeling is really important, at least to me. And I know this whole thing really reminds me of like, how burnout happens, right? Like, and people get overwhelmed and it can oftentimes just be what you're stuck in, right? And I know oftentimes like even just refactoring something that I have to work in that is a mess just because of technical debt or whatever it might be, just even doing a small refactor to make my life better. Right? Because it would make me feel better knowing, oh, at least this piece, you know, I know it works a little bit better and other people come in will feel a little better as well. And you're so right. It's like it's a metric I feel like isn't monitored.

RYAN_ONG:

Yeah.

VALENTINO_STOLL:

Do you have any suggestions for like, how to go about monitoring that kind of? you know, aspect of a code base.

RYAN_ONG:

I think one thing that can help is, I think first understanding where, being aware of where you are now or where your culture is at this point, or what like your norms for pain or unpleasantness is. I read a white paper a while back, psychology white paper talking about how humans feel four core emotions and everything else is kind of built around those four core emotions. just layers and complexity and context. And the four commemorations are like, can be viewed at two accesses, but for the most part, you can feel both at the same time. It's pleasant, unpleasant, activated, and calm. And I think breaking down how you're approaching anything in life, but in this context code, because this is what we're just talking about, I think it's useful to understand like, at any given moment, you can say like, am I activated, calm, unpleasant, pleasant? And that's a good way to be. to move through it in general, first awareness. I find that a lot of startups tend to come up, or especially younger engineers, especially those who've went through bootcamp, have a high tolerance for unpleasantness. It's just like, it's part of like the culture of startups in bootcamp is to burn yourself out. It's like burning the midnight oil is a badge of honor and it's something we should tolerate and not only tolerate, but aim for. And I think that tends to... In fact, the code that we're writing, and it's probably one of the biggest failings of ICU junior engineers or engineers who come out of startups, is this desire to prioritize the feature getting done over the quality that's written in. And it's a short-sighted viewpoint. It's not even a viewpoint, but a belief in the way things should get done. And understanding where your beliefs lie is what your tolerance is is kind of... how you begin to bring awareness to what you actually need to change in order to bring it into right feeling. I don't know how to explain it, but like what is an appropriate feeling for your company state or the desires or the goals that you have. Like I understand in a startup that is in stress or needs to pivot, maybe you should be burning men oil if your livelihood is depending on it. Or if you're making a big bet and you think it's worthwhile to take this risk, but. If you're working at a JP Morgan or if you're working at a Citibank, maybe you should take a break a little and not stress so much about how much you're working about this project. You're not going to get a raise because you got it on deadline on time. Most of the time you'll get a raise because you set expectations clearly beforehand. And so a lot of the times one thing that can help is set reasonable expectations for what you're doing. don't say that you're gonna be a hero and get this stuff done. You're not gonna get accolades for that, unfortunately. Usually management or from what I, my experience is, you'll get accolades when you can be delivered consistently and do what you say. And most product people are managers and will appreciate that more than anything else. Does that answer your question?

VALENTINO_STOLL:

Yeah, I think so. I mean, it's, I think it's a hard issue to quantify. And

RYAN_ONG:

It is.

VALENTINO_STOLL:

mostly because I feel like, you know, in the programming world, it's, you know, you push your emotions out of the way and focus on, you know, the logical steps that you're tasked with, right.

RYAN_ONG:

Yeah.

VALENTINO_STOLL:

But I feel like it's still, you know, everybody does have like feelings with their work, right. And so like,

RYAN_ONG:

You can't avoid it.

VALENTINO_STOLL:

You can't avoid it. And so I'm, I'm curious to like, how does, you know, have you noticed anything like, like signals that you can pick up from other other people's work as they're going through that kind of say, Oh, like they're feeling a specific way when they are submitting something, right? Like, can you, what are some ways that you gauge that and, and try and like, you know, resolve maybe some, some things out of it?

RYAN_ONG:

Yeah, I was trained. Most of my training comes from Pivotal apps we pair, where we paired 100% of the time. So after a period of a year and a half, you got pretty good at reading other people's emotions or working with them. Pivotal hired, one of the number one traits Pivotal hired for was empathy, which I really appreciate. And it's an interesting thing to hire for on an engineer, but it makes sense in terms of consultant or someone who's pairing all the time. It really helps you train or... be aware of the current situation and how to make it better when you're pairing. I think when you're pairing with someone else or working with someone else, it's pretty easy to... Be aware of where you're at. Whoever you're pairing with is end up going to be a mirror with where you are, whether you like it or not. You're going to be working on the same problem. If you get frustrated, they're going to get frustrated, or at least you're going to notice how they're not frustrated and you're frustrated. It's like, why aren't you frustrated? Which is a good way to go about it. Pairing has many benefits and definitely I'm an evangelist of it, but it's one of those, it's more of the sneaky ones that you get from it. Um, yeah, I think in general, just, you can learn how to read other people's feelings or emotions from pairing. Just try to be a bit more aware of it. You can kind of see when they're coding, whether they're rushing, whether they're slowing down, whether they're choosing to take a big picture. You'll notice when people get into rabbit holes about things. As someone gets into rabbit hole, you'll notice that they'll hyper focus on one problem and trying to fix this one small thing, which may not matter at all. but it's just like, this is a problem I'm trying to solve, which is like really useful, but also maybe not necessary. So yeah, I think an awareness of, when working with someone, it's pretty easy to have an awareness of where you're at, because they are a mirror in some way or form. And it's hard to ignore them if you're talking with them. You're just, as humans, we're designed to be aware of these emotions and just leaning into those. that sense of caring about this other person, having this empathy, I think is important. And I think also just having empathy when you're writing your code. Like, why are you writing this code? Who you're writing it for? Are you writing it to solve the job? Or are you writing it for the next developer who's gonna come along? And it's like, oh, I wanna be nice to the next developer who's come along, who's most likely gonna be you. I wanna be nice to myself in the future. And that means taking my time and being a boy scout about this and... leaving a bit better than you found it.

VALENTINO_STOLL:

Yeah, I think about that a lot with open source. And that's kind of its own beast, because as a maintainer, it's one form of empathy to be considerate of people trying to contribute to your project, but at the same time conveying certain expectations for the code base milestones and things like that for the project are already set up, maybe a big refactor to a specific thing doesn't make sense in this context. How do you balance that in an open source world? It's very hard, especially because you're not pairing for the most time. And maybe that's the solution, is to offer pairing on things to get better understanding. But I'm curious if you have any ideas for that, like how to... uh, frame open source projects better to be kind of more receptive to that, uh, emotional intelligence.

RYAN_ONG:

VALENTINO_STOLL:

Cause

RYAN_ONG:

man.

VALENTINO_STOLL:

that's one thing I definitely struggle with is how do you like, you know, set proper expectations, but also like, uh, how did not just like come across as, you know, shooting somebody down where I am considerate of their, uh, contribution, you know, and you could say it as much as you want, but if somebody submits something and, you know, is declined. It generally is not a great emotion. I know personally, right. But how does that, you know, how do you resolve that kind of thing?

RYAN_ONG:

I think that's probably one of the large questions of engineering of our current generation or just ever. I think it's a large problem of politics in general, like how do we even solve this in like, at the end of the day, these are just shapes of power, open source and stuff like that. we see those exist also in nonprofits being like, oh, anyone can come and help. And even not in a nonprofit, but like thinking of an open space, like a community garden. How do we manage this community garden? How do we care for this and stuff like that together? I think community gardens actually do a great job of bringing people in, being like, oh, if you want to contribute, you have to go to this intro day and you have to get this buy-in. You have to consider someone a member. in order for them to be worthwhile of contributing and helping out and understanding and caring for everyone else who's using this project. I think that works for smaller projects. I'm not sure if that works for larger projects like Rails and stuff like that. But I think in the beginning, it's often that you don't have any members besides the maintainer working on this project. And getting other maintainers would be basically other members having other people co-create and co-care about this thing. I don't know what to do when it gets larger. That's out of, I don't know how to handle large groups like that. Then you get into like. It's fascinating seeing how Ruby has done it, how Rust has done it, because these are newer languages, how Python does it. Ruby and Python almost work because they have a benevolent dictator of sorts, the BDFL, benevolent dictator for life, which I appreciate. But both of them still have ways of communal power, like... The benevolent dictator there is there to solve any kind of open issues or make decisions that aren't there, that need to be made, that are a little bit hard, that where like, you end up bike shedding if you go too long. And the bike shed ends with the benevolent dictator. But then you see things like rust happen where there's no benevolent dictator. And there is a big power struggle within the rust community right now, which is interesting. Rust trademark, which is like non-programmatic,

DAVE_KIMURA:

Hehehe

RYAN_ONG:

but still a discussion that's happening and why that happened poorly, but also about API level stuff that's always a discussion, like how the async discussion about how async would work within Rust took literally two years for anything to decide into its current format. And there's still people arguing about how it should work and like how do you continue doing that? I don't know. I think Rust has done a great job. Ruby has done a good job too. I like the motto, Ruby is nice because Matz is nice. Having kindness

DAVE_KIMURA:

Mm-hmm.

RYAN_ONG:

built into any kind of belief framework or political framework, I think is important without it kind of lost into conflict.

DAVE_KIMURA:

And so I think the key point here, and it's not the solution to everything because you'll always have bad actors in any kind of community,

RYAN_ONG:

Always, yeah.

DAVE_KIMURA:

but it is relationships. And so in your example, the community garden, if I just see the vegetables, so I see like a big corn stalk or something, and if I'm hungry, it's very easy for me to just walk over there and grab someone's corn and, you know, take it and eat it. But. If I know the person, if I have a relationship with the person who took the time to prepare the ground, sow the seeds, care for the plants, I would have a much harder time to take what belongs to them because I have that relationship. And I think the same way applies to open source software because if we all hide behind our avatars and this kind of like anonymous garden that is the internet, then we are less humane towards one another. And so that's something where RailsConf recently passed and I had the opportunity to go there for the first time and I got to verbally speak with other people and meet people who I've always just known as an avatar and a username or handle. And so opening up that... bridge to then form a human connection with them, I think has greatly changed not only how I view that person, you know, for the better, but also how we can then further the online relationship. And so I've always kind of, you know, passed on the Rails conferences and stuff in the past because I'm like, oh, well, you know, there doesn't look any I'm not interested in going this time. I don't want to travel and all that stuff, but having going this past time It's really opened up my eyes to this human aspect of relationships and how important it is When we're dealing with open source communities and stuff so

RYAN_ONG:

Yeah, it's really amazing the power of in-person organizing and gathering. I remember in the beginning of becoming a Ruby developer, going to Gotham Ruby conference was one of the biggest deals for me in terms of just being able to interact with other Ruby people in New York. Ruby, the Ruby scene in New York was hilariously small, like 14 years ago. Like everyone, every Ruby office knew everyone at every other Ruby office. And like. For some reason, everything spun out of the Gilt group. Gilt group had like one of the biggest Ruby shops and everyone kind of came out of there and built the rest of the Ruby community. Like Brian Helmkamp, creator of Racktest and stuff like that was at Gilt. Josh Knowles, who's the director for Pivotal, was out of there and a bunch of other people kind of all used to work at Gilt came out of there, which was fascinating. And having that in-person conference. connect these people felt a larger sense of community. It's like, oh, I actually like these people. Like this is nice to be here and I don't know if this applies to other conferences, but I've noticed that the Ruby conferences people actually want to meet each other like they're really open to just hanging out and shooting this shit like I remember I think at the first Gotham Ruby conference I went to I ended up sitting next to Sandy Metz and being like hey nice to meet you I'm Ryan and like had no idea who she was and she was just super nice And she gave a really nice talk. And then after it's like, why don't you work at like a big company or something like that she was working at like University of Ohio or something like that. She was like, I get to do what I want. I don't need to join a big corporation. Like, okay, I'm just, I was like 22 at a startup. And it was just so funny, but they're so nice. And she was so nice to me, like just still kind, even though I was saying very young and ignorant things, which I appreciate. I felt like everyone was about that. at the Ruby conferences.

DAVE_KIMURA:

Yeah, I'm well past my young age and I still say stupid ignorant things a lot. So It doesn't get any better and it actually gets worse as you introduce kids because then the you know in my case like the dad jokes enter in and then we just almost like Digress 20 years and go back to the stupid ignorant phase again

RYAN_ONG:

Yeah,

DAVE_KIMURA:

So that's where

RYAN_ONG:

absolutely.

DAVE_KIMURA:

I'm at right now is the inappropriate trolling and messing with the kids, gaslighting them and stuff.

RYAN_ONG:

Hahaha!

DAVE_KIMURA:

It's a lot of fun.

RYAN_ONG:

Talking about the organizations and the communities, one thing I'm always fascinated about also is like, how do we change the culture? Because like, as we're talking about, as I was talking about before, like... We as individuals have a lot of agency over our own actions. And that's nice, but let's say you're working in an open source code base or a part of a community, like what do you do when it, when you're feeling bad about it? Like, do you just do nothing and just take it? Do you just leave and find someplace better? Or do you like, or do you find that you have power, enough power influence to actually change the organization or the community that you're in? Um, as I was saying earlier, I really do believe it's easier to change a community than it is changing individuals. Like maybe you only have problem with one person, that person is just being real mean to you. Like you could talk to that person, but usually at this point they're not really interested in. At this point, they're probably not interested in changing their behavior with you. And so like, what do you do? I find that like going to calling to the community being like, is this an appropriate way to communicate with each other in general? Like, I don't know how to call it. I think we always have more power than we think we do. Does that make sense?

DAVE_KIMURA:

Mm-hmm.

RYAN_ONG:

Yeah, like there's always, we can always do things that we weren't aware of or we didn't know that we could influence by just, and we have to become aware of them or figure out what they are. There's always opportunity. And I think being a part of community, I don't think many people are aware of how much they influence they have in part of the community if you're willing to step up and call it out. Like, hey, I wanna create a norm. I think most people are willing to... to be interested in talking about if it's a norm or not. I find.

DAVE_KIMURA:

That's essentially what culture is it's what a group of people find to be the normal thing and I think that if there is some kind of behavior in a community So I'm gonna go back and quote this horrible movie that's completely awesome Idiocracy you can either lead

RYAN_ONG:

Great movie.

DAVE_KIMURA:

fall over get out the way and I really think that's what it is a lot of people have chosen to get out of the way or just leave the community as soon as something bad or controversial happens. And yeah, that'll solve your immediate problem, but it's not going to change this from happening again. So by getting involved in your community to help change what is perceived as normal is how you change culture. You know, it's not going to happen overnight because it's going to take a while for people to realize, OK, this is normal. But it's possible, even as you said, like even that small junior developer at a large corporation has a lot more power than they realize just through getting involved and helping change what is perceived as normal.

RYAN_ONG:

Absolutely, yeah. I think that a lot of people who have a job or feel beholden to follow the cultural norms because they don't want to risk their job and their livelihood for it. I've always, I definitely feel of a certain amount of privilege being a staff knowing that I have more power than most or the ability to leave and find another job pretty easy. But even as a junior, I would still do my best to make small acceptable changes. Like, you already know what the norm is, and asking for small things doesn't hurt. Like bringing up in a public forum, being like, hey, what is the best way to do something? Like literally just asking questions is so powerful. Being like, is this how we've always done it? It's like, yeah, it's like, why? Why do we do it this way? And. And. Usually just asking the why we do it this way will cause a dramatic shift of people being like, that's a really good question. They don't know why. Can we change it? Like, who do we need to convince to change it? Like, know who has the power. And if it's all of you, great. You don't have to convince everyone, all of you are already in. But if it's someone else, then like bring them into the conversation and go from there. It is, you don't have like... doesn't take much to poke a buffalo kind of thing or poke a lion as I say. It's like just asking questions about what do you think is acceptable. If something's weird, being like, this feels weird. Can someone help me with this? And then maybe they'll explain to you. Maybe there is a good reason, which is even better. That's when you learn. But if there isn't, then there's room for change, which is always nice. Or you learn more about why it needs to change. You're like, okay, so we need to change this thing first. And like, what is it the? Yak shaving, it's like how you have to go all the way down. But I feel like you have to yak shave culture too. Like why do we have this norm of being stressed out? Why can't we take more time? What is the issue that's going on here? Yak shaving things politically is just as important as yak shaving things technically.

DAVE_KIMURA:

So I remember like 10 years ago, Ernie Miller created humanedevelopment.org.

RYAN_ONG:

What

DAVE_KIMURA:

And

RYAN_ONG:

is this?

DAVE_KIMURA:

I think it covers a lot of this where, you know, the basic captions is, we are humans working with humans to develop software for the benefit of humans. So I'll link to it, it's pretty cool.

RYAN_ONG:

Oh, this is amazing. This reminds me of like a old school Agile manifesto level stuff. Hey, that's super cool. I always want, like, I love these beliefs. I wish there was a bit more of a guide in how to enact change. Like, it's like, okay, this is what we believe, but how do we go through that? And I think this is one of those first steps. So it's like, can we agree on this manifesto? Can we agree on this one community principle of humane development or whatever you wish to call it? Then if you don't agree with it, then why aren't we making that change? It's a nice way to go about it.

DAVE_KIMURA:

So let's try to put this into some examples. Have you ever been in a situation where there was a process at your work, previous employer if you wanted or wherever, where you didn't like the process and then you tried to make an effort to change it? And how did you go about that? And were you successful? Because we're not always going to succeed at changing something to be the what. the culture that we want it to be.

RYAN_ONG:

Yeah, I have a tendency to going into companies, pitching myself as the cleaner. I'm going in and kind of cleaning up old code, cleaning up code debt, changing processes and stuff like that. And... I was at this company where everything was in controllers or models, you know, standard rapid fire coding, just putting everything where it can go without much thought, had no services, and so I wanted to create a service-oriented, I wanted to just create service models for everything. And so I saw that solve the specific problem that I was going to have, and I just wrote it. And then I pitched it to everyone afterwards, being like, hey, this isn't hurting anyone. This is not far from the, this is better than the way we're doing it right now. How do people feel about it? And because it was a small change, I made it very small. It was like one file in a small little area. It's like, how do you feel about this idea? And eventually people were like, I don't know about it, but I paired with them and tried to solve for another problem and solve that problem well. solved another problem well, and eventually people were really bought in, and all the business logic got turned into services. Like, the company was plated, so we were making food delivery boxes. So it's like, oh, add recipe to box, remove recipe from box. And really clear services about how a child would think about our business and do each business option, and it was really effective. And I feel like that's usually the best way to do it. I've done it also with another gem I wrote called copy bar experiences, where it turns your front end copy bar code from spaghetti strings and an unmaintainable mess into an object-oriented API for your front end for testing. And what I'll usually do is I'm going to use it in this one test. This is better than what we've had before. And it's very small. and I'll show it to people and be like, oh, that's not bad. And then usually from there, I'll be a nice change in terms of tooling. This is, that was one way I changed tooling or patterns. When it comes to culture, it's a bit different. I'm not sure if I'm gonna be able to do this. Usually what I'll try to do first is try to get a retrospective up and running first, making sure that we have a place where we can, we're intentional at our process. A lot of shops you won't have retrospectives or a way to place feedback or a way to discuss process or cultural norms. So the most important part is starting a meeting about, that's a regular, that's regular, a ritual that allows you to give feedback or change your process or your culture. If you don't have that, that's the first thing you need to change and just get by it. Being like, hey, if you want to change your culture, right, we want to have this discussion. Let's make a meeting about it and talk about it regularly. If you don't have that, you have a much larger problem. I don't know what to do if no one wants to change their culture or people are stuck in their ways or don't see the point. Trying to change people's beliefs about culture is a whole another thing. I am interested in, but I'm not sure it's relevant here. But. Getting the rest show up and running is most important. Getting somewhere where we can give feedback and discuss what you want to change about your process or your culture. Then from there, just discussing how you're feeling. Like using, and if you're not good at discussing how you're feeling, read up on nonviolent communication, NVC. It's really basic. You start off with an I statement, an emotion feeling. Like I feel... angry or sad or frustrated when I have to do this thing or when you do this thing. And it's a really nice feedback structure for code and for other people in processes. You don't have to state the thing and how it should change. The most important thing is just to state what's wrong. And then from there, being able to collaboratively create systems or patterns or new ways of interacting with each other, that allows us to... Live in harmony. Ah, that's gone too far. But making it a little easier and towards the culture that you desire.

DAVE_KIMURA:

Yeah, I've always had a- I don't know what you want to call it, just a cringe whenever I hear code smell. Because to me, I think that is a direct... It's another way of saying like hey the code you wrote is crap. That's why it smells like it's crap and My goal is not to insult someone or to make them feel sad or upset So I like using the phrase that this could has an opportunity for improvement Because you're essentially saying the same thing but it can be perceived in a different way. And I think our approach, and this is something that it's taken me over 40 years to finally realize, is that the words that we say do matter and our approach to things matter as well. And

RYAN_ONG:

Absolutely.

DAVE_KIMURA:

it wasn't until I had kids that I realized like, I can't just go out and say what I'm feeling to that child. Because

RYAN_ONG:

Hahaha

DAVE_KIMURA:

It may not be received well, and if my end goal is to make a change or to have

RYAN_ONG:

Thanks

DAVE_KIMURA:

that

RYAN_ONG:

for watching!

DAVE_KIMURA:

person change their behavior, then my approach to it is going to be different. And what I found with having four kids is that each of these little monsters are all differently approachable. The same approach does not work for the next child as the other child that I have to meet them where they're at. And then work with them if I try to use the standardized approach for all four It's not going to work either three of them will be crying or one of them will be fighting and yelling so It's unfortunate that we have to do that, but that's the reality that we live in

RYAN_ONG:

If you have the energy to do that with your coworkers, I applaud you. I do not. I am not interested in parenting my coworkers, but it is something that is necessary sometimes if you are a manager or a leader, it is absolutely true.

VALENTINO_STOLL:

You make a good point about critique, right? Like critiquing is probably one of the most difficult things of our jobs, right? Because we have a very review structured, you know, to our work where everything is peer reviewed. If you want to go through this quality process, right? That we've set up through kind of these agile processes. But to go through that quality process, you get your code peer-reviewed and it basically goes through critique, right? Like, should this be structured this way? Should, you know, and fortunately, there are getting more systems in place to take a lot of the critiquisms out, right? Where, you know, we have code formatters and things like this that take away a lot of the interpersonal critiques that you can come about just by like reviewing something, right? But I feel like that's definitely one of the harder problems is how do you how do you not how do you set the right tone right when you're critiquing? And it's easy. I have personally made mistakes in the past reviewing like somebody's code with just like a bunch of like incessant comments, you know, just calling out everything that I saw as I went where it's like, that's not really the right way to do it. Right. Because it sets a tone where, oh, like, you know. any comment that you get is going to be negative. And so I even today will, you know, leave positive comments while I'm reviewing just to balance any other critiques that I may have that maybe are valid and need to be called out. But you know, if too many are there, you know, it's almost not worth commenting, right? Like it's, well, let's have a discussion because if there are too many critiques, then it really just means that expectations were... Not clear right and somebody had either gone a direction that they didn't know They should have gone through or the you know problem itself was not set up in a way that they could go So like I feel like a lot of times Anytime you find yourself like just hammering away at comments on our on a critique of something It's often just like alright. We need to have a discussion on What we really are trying to accomplish because even if you have that discussion yourself So oftentimes you'll realize maybe this is the way that it should work or you can realize a lot of things about the critique by just turning it internally as well. Going back to the empathy, right? Empathy higher definitely is a great pathway to that. Being able to think about how your critiques would affect somebody else as well. I don't know, that's not a takeaway that I had.

RYAN_ONG:

I've definitely, I joined a new company and this was bladed, the staff engineer job, and I got there and within the first week, I'm going through this code. I was on a team called the bomb squad because of how many errors were going on within the company. It was so bad. By the time I left it, by the time the company shut down, there were no more errors. It was great. Happy ending. But in the beginning, we were at one meeting and I was like, this code is bad. Like this is really, I cannot, we need to make time to rewrite this. Like this is giving me unpleasant feelings. And afterwards I leave the meeting and the director of engineering comes over to me and is like, hey Ryan, it hurt that you said that cause I wrote that code. I was like, oh, damn it. It's like, I'm not sure how else to convey though, how I'm feeling about it. It is bad code. Objectively, this is poorly written code. But also, yes, I understand that you wrote that. Dave, I think you had a good point. There's a lot of room for improvement here. It's a great way to state

DAVE_KIMURA:

Hahaha.

RYAN_ONG:

something and trying to come at it from a place of kindness. I think there's also place, though, to be resilient in that feedback. Knowing how to hear. You're going to get feedback from so many people and definitely in unpolished ways. And learning to hear

DAVE_KIMURA:

Mm-hmm.

RYAN_ONG:

that feedback without getting defensive or reactionary is such an important skill. As much as it is to give good feedback or learning how to receive feedback is so important. I'm not saying that we should be stoic, but trying to hear the truth in what they're trying to say and acknowledge that they're human and also acknowledge that they might be really mean. It doesn't have to take away from what they're saying either. It's like you said that mainly and also you're right Both can be true Yeah, it's so hard navigating that fine line of giving, receiving, being kind, being kind, and hearing effectively, and also just trying to say it. Because sometimes it's better to say it than not say it at all. Find the imperfect way to say it. Because I hope that within a good culture that one can receive it well, or figure out a way to... understand if you're saying it from a kind place they can understand that you're not meaning harm and then they can give you feedback like my director did that it was hurtful and it's like okay i have to be kinder about this

DAVE_KIMURA:

Yeah. See, man, I know we can go on and talk about emotions and. Our approach to calling out bad code all day. I mean, I've had to deal with it a lot, like, and a lot of it was my own junk that I created 10 years prior. So, I mean, I know we've all been there, but one project I was working on that I did not create, I got brought into. They were doing IATN, so internationalization translations. And instead of using YAML files, it was in a Excel file. Now even a CSV, it was in a legit Excel file. And so with it being binary, you cannot have two people making changes on it in. without like getting a merge conflict that just is not solvable. So. I just know posed like one day I said hey we've been having some merge conflicts and it's been causing a lot of headaches because it's in the translations Excel file. I think if we were to take this approach it would then solve these issues I've been experiencing and then got the buy in. made the change, we've been a lot happier since. So I think that unfortunately, even in a small team, there can be a sense of politics that we had to navigate around and really just have a tactful approach. So kind of back to that Ernie Miller website, humanedevelopment.org. No, we are humans developing software for humans for now until AI comes in and replaces us. Well, I think we are starting to hit that mark. Are there any closing thoughts you want to leave us with, Ryan, or Valentino?

RYAN_ONG:

Be kind.

VALENTINO_STOLL:

I mean, yeah, I was just, I was about to say the exact same thing. That's so funny. Yeah, I completely agree. I think,

RYAN_ONG:

Pivotal

VALENTINO_STOLL:

I think, yeah, go for it.

RYAN_ONG:

Pivotal had a saying that I still resonate with and kind of take with me in each job. And the three rules were do the right thing, do what works and be kind. And I think in general, those are great ways to work with each other and just be with each other.

DAVE_KIMURA:

Awesome. Well Ryan, if people want to follow what you're doing online, is there, do you have a social media presence that they can follow you?

RYAN_ONG:

Everything on my social media has nothing to do with programming, so I'm not going to share it. It tends to go more with dance stuff than programming. I have a whole mindful dance life outside of programming, so I'm not interested in sharing it though. So thank you, though.

DAVE_KIMURA:

Okay, awesome. Well, let's move on to some picks. And that's just where we kind of pick whatever is interesting and going on in our life that may be tech or non-tech related. So Valentino, do you want to kick us off?

VALENTINO_STOLL:

Yeah, sure. I just listened to kind of incredible podcast changelog where they had Jose Vilemon, for those that don't know, was a former Rails contributor turned creating Elixir with Erlang. And he basically, it was a breakdown of everything that they released recently with their livebook Livebook is kind of like Jupyter Notebooks on Elixir. And it's just incredible, all the different things that you can do within the Elixir ecosystem. I know we're on RubyRogues right now.

RYAN_ONG:

I like

VALENTINO_STOLL:

But

RYAN_ONG:

sures.

VALENTINO_STOLL:

Elixir, they just basically wrapped the entire machine learning ecosystem into the language in a fork of Elixir, in its own ecosystem called Nix. And it's remarkable and you basically have access to hugging face models in a very easily deployable and replicatable You know distributed processing so it's like it's the most wild thing I've ever seen. But anyway in this in this changelog episode, he goes through and breaks down all the different things that they're working on and I'm not gonna lie. I'm definitely checking it out. I'm gonna play around with some bumblebee

DAVE_KIMURA:

That's awesome. I'll have to check that out. Any other picks or is that it?

RYAN_ONG:

Check out my gem, Copy Bar Experience. I just released it about a month ago. And it can really change the way you do frontend testing. It kind of uses a form of page objects and it really tries to, and it solves the entire problem of the longevity of frontend testing, which is... pretty wild. Usually after working on a project for like three years or so, changing anything in the frontend means you have to change 50 or 60 frontend tests. This allows you to change one or two files. So that's really it.

DAVE_KIMURA:

That's awesome. And so I'm gonna pick a website that I created and released last night in response to another website that someone created and released the day prior. So someone created gowithphp.com and it was the PHP propaganda why you should use PHP. So I created gowithruby.com. And that is my take on the... Ruby propaganda as to why everyone should use Ruby. So I will pick that and share that with you all. All right. Well, Ryan, I really appreciate you coming on and talking to us about the emotional side of programming.

RYAN_ONG:

It's my pleasure, love to talk about it.

DAVE_KIMURA:

Alright, well that's all for this one. Thank you all for listening.

Ruby Rogues

Subscribe

Follow

Managing Emotions When Programming with Ryan Ong - RUBY 597

Show Notes

Sponsors

Links

Socials

Picks

Transcript