A viewer asked my thoughts on these phrases, but to be honest: I can't say for certain I've heard them.
Here's my interpretation of them for software developers.
📄 Auto-Generated Transcript ▾
Transcript is auto-generated and may contain errors.
hey folks we're going to the comments this is from beanbag 59 and the question is how do you think like a programmer I hear different takes on it like keep the end in mind while building your project I've heard go line by line so I'm curious to hear your take on it so thanks being back for sending this in um just a reminder if you have questions leave them Below in the comments or look for Dev leader on social media if you have something that's maybe a little bit longer you want to keep that Anonymous Dev leer is also my main YouTube channel so if these videos are too ranty for you that channel has a lot of edited down videos you might like that better and there's more like programming tutorials and stuff as well so you can go check that out but to
Bean bag's question so this is interesting I actually don't know the context here so I'm going to give you my take on what I think that this is meaning but this is certainly from my experience not it's not like a saying that I like regularly come across like oh like I took that to heart when I started programming 20 years ago or something so um I might have a different take on this than maybe what the maybe as I'm going through this I'll do a quick search because I'm I'm filming this at home I have a bunch of YouTube videos and stuff that I have to crank through for my main Channel and uh I figured I'm going to try to get some of these questions answered so I'm going to pull up a browser and just in case I might be able to jump
over but I want to kind of give you my take on it first so the the keep the end in mind and go line by line to me are talking about different things when I think about what I believe they mean and the keep the end in mind part I think is a very interesting one this is probably something that feels a little bit more relatable to me uh go line by line also does if I change the context so let me elaborate a little further when I think of keep the end in mind what I'm thinking about is like big picture Okay so uh when we're programming things this is why it feels like it's going to be at odds with go line by line by the way so hear me out um when we're building things and we are you know building parts
of systems and stuff like that it's it can be overwhelming especially for more Junior people where it's harder to keep the pieces of the system like in their head and how these things all work together um you might be like focused on a very narrow scope of code a certain module a class like depending on what you're building you pick the the words you want to use but like a smaller piece of the puzzle um and you might be focused on that you might be trying to uh perform just to give you an example maybe you're trying to optimize the user experience and you're focused on one particular area and you're optimizing this area over and over but when you're not thinking about like the bigger picture you're not realizing that maybe maybe it doesn't make sense to be hyper optimizing this one spot if
we zoom out we might be able to think about like what what is our actual goal right like our actual goal is to optimize this you know experience for the user maybe what you're looking at is a a hot spot but the other thing might be if you sort of uh do things in a different way you can avoid that code path altogether just as an example so um that's not necessarily keeping the end in mind but it's just an example of zooming out of an area of code so you can have like more of the the big picture in your head so I like to think of keep the end in mind when we're building stuff out right same same type of idea if we're thinking about where we want to get to I think that's the important part and we should be trying
to move in that direction um another sort of way that I like to think about this is like from from my experience like I I think it might be I don't know more common for people to think hey like we want to have a perfect architecture we want the code base to be clean everything's got to be perfectly tested like all these things we have in mind but they're not like it's not reality like ever so if we're thinking about where we want to go so again keep the end in mind where do we want to go I think as long as we're moving in that direction that's positive and sometimes that means that we're moving in that direction but we're not taking that perfect step forward it's like a half step right so you might um you might get closer to you know delivering
bring value to customers and in whatever you're building this is it's such a generic way to say it sorry but um you're shipping a feature and uh you didn't have time to go like rewrite the part of the code base but you shipped the feature and like that's ultimately moving you at least in the direction forward right of getting the product to a state you want it to be in but it's not the full step so it's still progression and I think as long as we're thinking about that then we can try to factor in like at some point if you're ACR Tech debt like that you will say like hey look like any step we take forward is like any sorry any step we try to take at this point is going to feel like it's not forward like you know the now the
tech dead is becoming overwhelming so taking a step in this direction is like it's just not forward anymore um but I think that when I think of keep the end in mind it's like about zooming out bigger picture stuff so that we're not so focused on like just the one small spot by the way I am going to Google this in just a moment um I just figured I wanted to get this video rolling because I don't edit these ones um you got to kind of deal with it um and then the other part on go line by line for me this is more about like debugging things that's how I'm thinking about it we're trying to understand how something's working so it to me it feels a little bit at odds with the other one cuz I was saying hey zoom out get the
big picture don't h hyper focus on one spot but when we talk about go line by line like especially from the context of debugging you might be looking at some code and you're like well this Mo like here's a class and there's a method in here and it says it does this and as I scan through the method I'm like yeah it rough like I get the idea of what it's doing so like hm I don't see the problem let's keep going but like at some point you have to start going like truly line by line and saying like you know this method says it's doing this right this is what the intention is the variables are named this way the method calls are named this way but like what is actually happening because computers don't just like computers don't just like make problems for
us it's not like they're just like magic and like oh look like a bug appeared here like it's because the computer's magic and haunted or something it's no like computers literally just do what they're told so when we're trying to investigate problems and debug things it's like we as humans have written code that will do something it's you know it's converted into instructions for a machine to run and our our own perspective or our intentions may not be exactly what is you know uh created in the end so when we're going through line by line you're able to in my opinion like that's what I would say to someone like to go you know truly understand where something's breaking down and and not working uh so like that's how I would look at those two things and they're both valuable but I use them in
different context so that's what I mean I'm going to I have my browser open you can probably still hear me if I keep this mic down on my desk I'll talk a little louder um but uh I'm going to search programmer go line by line and I'm seeing like on Reddit follow execution line by line go line by line Loop do Lexus have to go word by word or can they go line by line how to debug your code like a pro right go line by line um so yeah I I feel like the line go line by line part is like really to like understand and break down what's going on in code but let's let's see what the other one is just according to the internet with a a two second search so um keep the end in mind maybe maybe this isn't
uh okay this one I I might have to open this and not just rely on the Google search I don't know who this person is but let's see so part of their blog post they talk they're talking about extreme programming relies heavily on automated test to ensure code quality it also encourages team oriented approach and they say though each approach has different philosophies techniques and tools they all share some basic principles start with with what you know keep the end in mind and don't think don't make things more complicated than necessary uh it's the there's only one spot in this whole blog article um which like I said I don't know who the person is it's a pretty lengthy blog article it's called the productive developer um I I don't know this is by Brendon Matos um I don't know maybe I'll say the name
and people in the comments will be like oh you don't know who that is Maybe I'll search who that is um but in their article they only reference it the one time um no I'm not g there's like a an athlete name the same thing and I'm assuming it's not the same person so anyway I I suspect that I'm probably not too far off with what that means but I think that's my take on what those two are so we'll keep this one pretty short um I don't really have much more to add but I do appreciate that if other people are watching this and you're like nah man like here's what it means if you guys have different thoughts on the interpretation of keep the end in mind and the other one is go line by line leave them in the comments would love
to hear about it I'm happy to go make a follow-up video If there's like tons of different discussion on like what's going on with these two phrases um maybe I miss the mark completely but that's my interpretation of them so uh thanks for watching I do appreciate it and like I said at the beginning if you have questions leave them in the comments or look for Dev leader on social media and I'll see you next time take care
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.
- What does 'keep the end in mind' mean when thinking like a programmer?
- I think 'keep the end in mind' means focusing on the big picture and the overall goal of the project. It's about knowing where you want to get to and making sure your steps move you in that direction, even if they are not perfect or complete. This helps avoid getting stuck optimizing small parts that might not impact the final outcome significantly.
- How should I approach 'go line by line' when debugging code?
- I use 'go line by line' as a method to deeply understand how the code is actually working, especially when debugging. It means carefully examining each line of code to see what it does versus what it's supposed to do, because computers execute exactly what they're told, not what we intend. This helps identify where the problem or bug is occurring.
- Are 'keep the end in mind' and 'go line by line' contradictory approaches in programming?
- I see these two phrases as valuable but used in different contexts. 'Keep the end in mind' is about zooming out to see the big picture and overall goals, while 'go line by line' is about zooming in to understand specific code details, especially during debugging. They might seem at odds but actually complement each other depending on the task at hand.