In today's episode, I'll be doing the first in a series of episodes about the Great Developer Mindset. In this part, we will talk about demystifying code. Make sure you subscribe so you don't miss out on future episodes!
In today's episode, I'll be doing the first in a series of episodes about the Great Developer Mindset. In this part, we will talk about demystifying code.
Make sure you subscribe so you don't miss out on future episodes! Also, please take a moment to review the show! Click here to review Developer Tea in iTunes.
Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell, and in today's episode, I'm going to be doing the first installment in a series that I'm going to call Adopting the Great Developer's Mindset. Hopefully you all enjoy this series, and that will be what tells me whether or not I should continue this series. But the concept of the series of these episodes, and it's not going to be back to back, there's going to be, you know, over time, we will release more of these, kind of like we've released the Client Relationship series. But the idea behind the Adopting the Great Developer's Mindset series is to talk about the way that great developers think, not talk about specific types of code necessarily, and not talk about, you know, what framework should I use now? What framework should I learn today? And not talking about... But instead, talking about the way that a developer deconstructs a problem, for example, or the way that a developer goes about learning a new language. And so today is the first episode in the Adopting the Great Developer's Mindset series, and it's dedicated to demystifying code. Demystifying code. I hear this phrase often. How do you understand all of that? It's like gibberish on your screen. It's like a different language to me. When I look at your screen, my eyes glaze over. I can't imagine doing that kind of work. It's just a bunch of letters. The problem with this perception is that people are viewing code as some kind of non-human thing, where the human has learned maybe to directly communicate with the computer. As we've said in the past, most code is actually not for computers. Computers happen to understand it, but rather for humans to communicate with each other, we have to write code that other humans understand and that the computer can translate to zeros and ones. Now, when you read a book, if you simply view that book as letters on a page, you miss the point. The proper way to enjoy a book is to recognize that those letters represent a story. And you're going to enjoy the book most if you immerse yourself in the story. When you read a book over a period of time, particularly fiction books, that story sticks with you, even when you are not reading the book. Now, how is that the case? Well, the words on the page represent something more. All of you may be listening and thinking, well, this is kind of obvious, right? Words on a page represent communication and assistance. story. But code is very similar to this. And this is something we don't talk about very often because a lot of people see code and once again, their eyes glaze over. But code is like a book in a lot of ways. Code should be considered a representation of ideas, not an exposing of the computer's kind of cryptic internal working parts. So how can you start demystifying code, especially if you're a young developer, even if you're not a developer, if you want to understand how code works and you've never written a line of code in your life. Just like in grade school, when you learned how to comprehend a novel, in today's episode, we're going to talk about the fundamentals of comprehending code. I'm going to give you three basic ideas for comprehending code, basic ways, things that you need to identify specifically to comprehend code. Number one is identify the writing style. Identify the writing style. Code, just like books, has an author. All code has been authored by someone or perhaps multiple people. Usually multiple people have written whatever piece of code you're looking at. If you start reading a book of poems expecting a novel, you might be surprised with the lack of narrative structure or maybe the same. Erratic arrangement of words or the lack of punctuation. However, if you understood the writing style from the beginning, you can approach the book of poems much more holistically. You can understand it a whole lot better when you approach it, understanding that it's a book of poems. The style of code is influenced by a lot of things and you need to understand what style of code you are reading. The style, of course, is influenced, by the language it is written in. This is actually true for books as well. Obviously, the style of a book is influenced by the linguistic structure. But with code, if you have a different language, a different syntax, that code is going to be shaped differently. It's going to look different. It's going to feel different. It's going to have different features based on whatever features that particular language supports. You may see a lot of brackets or you may see no brackets at all. You may see a lot of numbers or a lot of quotes or you could see a lack of those things. So it's important to understand that the language itself is going to influence the style. But then the author and the job of the code, both of those things will heavily influence the style as well. So you can have different paradigms for constructing code that either the author or the language or both can influence heavily. For example, functional. Or declarative or imperative or object oriented. There are a lot of these different paradigms that you can go and Google in your free time to understand them a little bit better. They're beyond the scope of today's episode. But you need to understand the style coming into it. You may also have a particular author who's more clever or maybe a particular author who is more verbose, somebody who likes a lot of comments versus somebody who doesn't like a lot of comments. Now, we aren't saying the way, that the code should be. We aren't saying the way that the code should be because in my personal opinion, for example, I don't really like to see clever code. Sometimes that's a little bit more difficult to approach as a developer. But you will very likely come upon some code that isn't perfect. In fact, you absolutely will come upon some code that is different from the style that you would write that same piece of code in. But you need to understand style to be able to understand code. So I'm going to go ahead and show you how to do that. A piece of code. So number one, identify the writing style. Number two, identify the setting. Quite literally, where is this code being run? Is it being run on a server? Is it being run on the client, maybe in a browser? Is it being run on a native device? Or maybe it's being run on something like a Raspberry Pi? Or perhaps it's being run distributed across a lot of virtual servers or something like that. So that's a good question. So you need to understand where the code is being run. You also need to understand where it is being run conceptually, right? So is this code collaborating with other systems? Do other things depend on particular parts of this code? If we take our book metaphor further, perhaps the book is one in a series of other books. Or maybe it's fan fiction that requires a predetermined knowledge of the larger world that that particular fan fiction story takes place in. So that's a good question. Is the code a part of a legacy project that is maybe being slowly updated? Or maybe the code has a whole suite of tests you can run? Or even worse, maybe that code is full of errors, and you have the opportunity of discovering those errors. Understand the setting of the code that you are trying to get into, trying to comprehend. Identify that setting. That's number two. Number three, identify the code. Identify the plot of the code. And we're taking that book metaphor even further. Identify the plot of the code. Unlike a book, or unlike most books at least, most code doesn't read top to bottom. You're not going to really be able to understand it if you read it top to bottom. Instead, it's going to read a little bit more like a choose-your-own-adventure novel. If you try to comprehend the code in the wrong order, you're going to get lost and frustrated quite easily. But there's a lot of ways to do that. There's a lot of ways to do that. There's a lot of ways to do that. But there's not just one order. That code is dynamic. Unless you are reading a script, which may actually read top to bottom, most of the time, code has different entrance and exit points. So you need to understand what those are. Where is it being called into? What function starts the code? Does it read from top to bottom and execute from top to bottom? Or does it maybe create an event listening system that watches a user's actions? This is true, for example, for Gulp Watch, if you're familiar with Gulp Watch, as well as JavaScript in the browser. This is the way that it runs. So ask yourself, what is the big idea, the full story of this particular piece of code? How does it fit in with the things around it? Now that goes back to the setting a little bit, but what is the plot? What is the starting point and the outcome? Why does this code exist? Do I have enough information to understand the big idea? It may be that the piece of code that you're looking at doesn't have the full plot. Maybe you're coming in in the middle of the story. And once you understand the purpose for the code, you will likely be able to identify the big plot points in the code you are working on. For example, if you're working on an application that has a database and users can log into it, maybe there's roles, you can reasonably assume that you're going to find some files related to the database structure, some files related to user access, maybe some views for the user login. These are the ways that you're going to identify what are the main actors, where are the plot points. And so you need to do these three things when you're trying to understand new pieces of code. Number one, identify the writing style. Number two, identify the setting. And finally, number three, identify the plot of the code. Thank you so much for listening to Developer Tea today. I hope you enjoyed this first installment of the Adopting the Great Developer's Mindset series. And if you did, please let me know because I want to know if you guys would like for me to continue this series with more content talking about how a great developer thinks, how a great developer approaches a problem. Thank you so much for listening. Thank you so much for listening. Don't forget to subscribe and leave a comment. Leave a review in iTunes. And until next time, enjoy your tea.