Naturally Curious or Check The Boxes: What's Better for Developers?

Naturally Curious or Check The Boxes: What's Better for Developers?

• 168 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinoengineering managerleadershipmsftsoftware developercode commutecodecommutecommuteredditreddit storiesreddit storyask redditaskredditaskreddit storiesredditorlinkedin

It turns out that not everyone is like you. And they aren't all like me. And they aren't all like your neighbor. Everyone is different. While it's probably true that most software engineers seem to be more naturally curious... Are all of them? All of the time? Let's discuss.

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

Hey folks. Um, this is the second of two videos and in the first one I was doing a bit of a chat around like critical thinking, especially when it comes to like reading stuff on the internet. Um, in particular, I find that the more software developers that are turning to the internet to go like learn about how to, you know, get into the industry, how to improve as software developers, like you can't lose the critical thinking skill and just because someone says it, including including what I say, right? Like you must form an opinion about it. Take what I say or anyone else says as a grain of salt and form an opinion about it, right? So it's just perspective. You want to try and collect different perspective, inform yourself, right? Collect data points and come up with an opinion on things.

And so the previous video I was talking about a couple of different posts on social media um and kind of some people offering perspectives on things and trying to like share this idea that you know in some cases I'm like I don't think this person is the right qualified person to talk about this. Um, and then I also tried to call out that in for one post like I was in favor of it so it's easy for me to um, you know, disagree with the others that are disagreeing like kind of thing. So, uh, and then the other way around. So, like if I agree with a post or sorry, if I disagree with a post, it's easy for me to like I don't know kind of uh it's it's harder for me to go find like the value in the post if I disagree with it.

But we like always want to be trying to like extract information even if we don't agree with something like understand it and then use it to like form an opinion about it. And so in this video, I wanted to talk a little bit more um handson in the workplace and less about like social media posts, but I wanted to tee it up with like let's get some critical thinking going. So in this video, I wanted to talk about something that is um it's a little bit of perspective about how like the fact that in the workplace not everyone works the same way. And what I mean by that is like there are sometimes individuals I would say it's a little bit more common with junior people because I don't think that it scales really well into uh into higher levels but um there are individuals that um it's not it's not sort of their first instinct to like to to dive deep into certain things.

And what I mean by that is like the if we take the inverse it's pretty common um I would say for a lot of developers to want to like it's almost like to tinker to take things apart to like you know okay I see this on the surface but like what's happening behind the scenes how does this work I want to understand it right like there's it's pretty common to have this natural inclination to like want to just like understand how things work and I say that because I think that is the most common but that doesn't mean that's everyone and what can happen in situations like this is that if you see that more commonly people do this you may form the expectation or the belief that everyone does this and what ends up happening is that when you're working with others and they don't work like this you become frustrated because it either seems like they're not able to do their job properly You might feel like they're not intelligent.

It might feel like you will form opinions about this stuff. But the reality is Oh, is my hand bleeding? Something's bleeding. I got I just looked down on my hand. There's blood on my hand. I'm like, where is that coming from? Um, the reality is that in these situations, it's like it's not it's not because someone's not intelligent. It's just like someone is different than you. And so the the sort of dichotomy that I I want to talk about is like the difference between individuals that have a natural inclination to want to go understand things, take them apart, see how they work. Um versus the people who are just like, give me the list of things to do and I'm going to go through them. Um, the reason that I think that this is super important is that I think that as software engineers and engineers in general, we want to move in the direction of like understanding things because this is how we can analyze things.

We can um we can take data points and do an analysis, form an opinion on them, make suggestions on things. I feel that when you move in the direction of trying to understand and get that deeper understanding of whatever whatever the thing you're looking at is um that's where you can make better informed decisions and that is truly what I feel like drives a lot of engineering. So um to give you an example like if there was you know uh sets of data that were being collected in a system okay and there's uh you know months of data and the granularity sort of like at you know the minute level or something right so lots and lots of data to go over and a bunch of different signals and you can see this stuff on dashboards you can query against it um if you're in a situation where to do some work.

Someone someone was telling you like um I don't know like here here's some things I want you to go look at and like report back on them kind of thing so we can go make a decision in one camp. And I'm overgeneralizing here because I'm going to talk about like two two different camps and I feel like everything's a spectrum. So it's truly not like just two distinct groups. In one side of the spectrum, you might have someone that says, "Okay, I was told I have to go like look at some of the data here. So, I will go do that and I will report back and basically just do what I was told, which was go look at the data like what data do I need?" Well, they might have had a couple of pointers to say like, you know, this set of data

across this time range and they'll go grab some of that and then they'll bring it back and say, "Here's the data." Be because that's what they were told to do, right? So, in their mind, they're going, I'm getting my work done. Like, I'm doing the right thing. I got the data. Now, now that I've brought it back to who was asking for it, now we can go do the next step. And it's because they took it literally, right? Like, go get this data, bring it back. And so I'm framing it this way because you might have heard what I said and you're already like, "Well, that's all they did." Or you might have heard that and you're like, "Yeah, I don't understand what's wrong with that." And it's, well, nothing's wrong with it. It's just that some people will hear that and go, "Well, like what what did they go understand about that data?" Right?

And other people will hear that and go, "Yeah, they just did what you told them to do. like I don't understand why you're still talking about this. Now, if we take a different approach here, you might have someone who heard that. So, they were told, "Hey, go collect this data." And what they do is they go look across the data. They're looking at different variations of this. They're trying to say, "Okay, well, if I um if I look at this time horizon versus this other one, do I see a trend? Do I see a difference? If I split this signal up, do I actually see that, you know, signal A versus signal B?" like signal A is the overwhelming one here and it's kind of masking maybe this underlying problem with signal B. So signal A is introducing some noise hiding a problem in signal B and they start taking these things apart and they start looking at them and they start trying to form an understanding.

Now they bring that information back to the group or the person that was asking for it. Now you might have heard that and you you're nodding going yeah that's what I would expect to do. you're going and analyzing these things and getting a deeper understanding. Or you might have heard that and said, "Well, no one asked them to do that, right? Like that sounds like you're just creating extra work. So like which one of these is right and which one's wrong?" And the answer is both and neither, right? Like it's not that one is right and one is wrong. It's just that one of these there's more of a natural inclination to like what I would call an engineering mindset, which is generally trying to have a deeper understanding of how things work. And I say this again not to say one is right and one is wrong, even though I'm telling you like I would ra I would rather someone lean into one other side of this.

And it's just because I feel like over time that is a skill that you want to build up because it will benefit you. It's not that it was wrong to do the one versus the other because it's going to depend on if the person was clear about their expectations and what they wanted. So, I wanted to talk about this. Am I getting paged? No, we're good. We're good. We're still safe. Um, I wanted to talk about this because depending on your level and who you're working with and these types of interactions, you may have an interaction like this and you're frustrated because you're like, why is Billy not ever diving into this stuff? Like, Billy clearly doesn't understand what's going on. And in Billy's mind, he's like, I'm just doing what I'm told here. Like, what the hell, man? Like, why? like why do you why do you talk to me like I don't know what's going on or like why do you why are you getting frustrated with me?

I'm literally doing the things that you're asking for and it's just because there's a difference of opinions in in what the expectation is. This might seem like a silly thing to you and you're like I don't really get it. That's fine. It's probably my fault in how I'm delivering it. Um but I wanted to talk about it because it's a a point of contention. I have seen this happen many times and I've seen it happen across um like I said it's more common that you have more junior people that kind of do the the more service level thing but I have seen frustration from all different levels on the other side so like junior up to you know uh people that are levels above me being frustrated with people going like why aren't they diving into this stuff. Why don't they do that? Like that is my expectation.

But what's interesting is that when you talk to these people and you're like, "Have you did you clarify that expectation with them?" Well, no. That's just what I expect. And it's like, "Well, that's just not how their brain works." So, guess what? You're going to keep getting frustrated. You have to coach people through this stuff. Otherwise, you just continue to be frustrated and you'll probably reach a point where you're like, "Well, this person sucks." And it's like, "They don't suck. It's just that they think differently than you and they've never had that expectation raised to them. So that does require coaching if that is a behavior that you want to have. So, um, you know, I I like I said, I wanted to talk through this because I think there's going to be different people that watch this and depending on what side you're closer aligned to, those scenarios might either trigger you or not cuz you're like, "That makes sense." Or or it doesn't, right?

It's it's opposed to how you think. But now, what I would like for you to do, depending on which side you're on, is to think about your interactions with others, right? Are you the kind of person that does dive into everything, try to understand it because it's just like naturally how you approach things? And have you worked with people where you're like, "Dude, like why are you not doing that?" Like, "What do you mean you, you know, you pulled a couple charts and you pasted it in here and like now you think you're done? Like what do you mean you're done, pal?" They might be done based on their understanding, right? Like that's just how it is for them. So my homework for you is to go think about that. Go think about those interactions. Think about the last time you work with someone. Was were people clear with that expectation that there's supposed to be a deeper analysis or was it go grab the data, right?

Like how you try to clarify those things can can change a lot in what someone does. And if you're on the other side of this, all right, where you are the kind of person who just kind of checks the box, does what you're told, someone says move faster, you go, okay, I'm moving faster. Are you just doing it to check the box? And if so, like maybe an opportunity for you when you're having these types of conversations to is to try and pause, right? Awareness is the first thing. Having awareness isn't like fix things, but awareness lets you uh have more opportunities to interject and try to have change. So, if you have awareness that you operate like this, and I'm not saying it's wrong, but if you have awareness that you operate like this, you might want to try pausing and going, "Hey, like you're asking me for this.

Are are you actually asking for an analysis, right? Like, are you asking for data to be collected? If so, you know, do you have specifics around what you want to see? Are you looking to me to try and, you know, find out what those specifics are? Are you looking to me for an analysis? Try to pause to ask those questions because maybe what's happening is that person is expecting that. Maybe they're not. I don't know. But maybe they are and you're missing that. And it's not your fault necessarily. It's just communication differences between different people, right? So that's homework for you. Um, anyway, that's the video. I hope that was maybe an interesting kind of perspective, different ways to look at how different people work and this is just a friendly reminder that there's all sorts of differences in how people work. So if you're like experiencing frustration with different people, a lot of the time we get frustrated just because people work or behave differently than like what we expect, right?

But they could say the same thing about how you work and behave. So if you're experiencing different and maybe it's completely unrelated to what I just talked about here, but it's just a reminder that if we're different, it's there's nothing wrong with being different. It's just like we got to have conversations about these things and that's how we work effectively together. The more time that you spend with people on a team, the more that you learn about these differences and the more that you overcome them naturally just because you spend time together, right? But if you never try to understand these things or you never try to make progress on them, then if you have friction in the beginning, you'll probably continue to have friction because no one's ever trying to improve it. So just some different things to think about. Hope that helps. You have questions on software engineering, career development, that kind of stuff, leave them below in the comments.

You can go to codeccommute.com and submit questions anonymously and I'm happy to try my best to help. I'm just a guy sharing my experiences and perspectives and you need to inform yourself and have your own opinions and perspectives on things, not just take mine. So, hope that helps. See you in the next video.

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

How should software developers approach information they find on the internet?
I believe software developers must maintain critical thinking when reading information online. You should take what anyone says, including me, with a grain of salt and form your own opinion by collecting different perspectives and data points to inform yourself.
What are the differences between developers who dive deep into understanding tasks and those who just follow instructions?
Some developers naturally want to understand how things work by analyzing and breaking down information, while others prefer to just follow instructions and complete tasks as given. Neither approach is inherently wrong, but I encourage leaning towards deeper understanding because it helps make better-informed decisions and improves engineering skills over time.
How can teams manage frustration caused by different working styles among developers?
Frustration often arises when expectations aren't clearly communicated, especially if one person expects deep analysis and another just follows instructions. I recommend coaching and clarifying expectations explicitly, and for those who tend to just check boxes, pausing to ask whether a deeper analysis is needed can improve communication and reduce friction.