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 Tea. My name is Jonathan Cutrell and in today's episode I'll be doing the first installment in a series that I'm going to call adopting the Great Developers 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 Developers mindset series is to talk about the way that great Developer 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? Not talking about those kinds of things, 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 Developers mindset series and it's dedicated to demystifying code. Demystifying code. I hear this phrase often. How do you understand all of that 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 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 zeroes 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. 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 a story. But code is very similar to this. 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. It 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 seemingly 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. Basically 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. It's important to understand that the language itself is going to influence the style. Then the author and the job of the code, both of those things will heavily influence the style as well. 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 this style coming into it. You may also have a particular author who is 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. 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 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 you need to understand where the code is being run. You also need to understand where it is being run conceptually. 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 inside of. 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 plot of the code and we're taking that book metaphor even further. Identify the plot of the code. Even like 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 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 intrants 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 a 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? Maybe 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. 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 log in. These are the ways that you're going to identify, you know, 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 Developers 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 to Developer Tea. We did not have a sponsor in today's episode, but still go and check out the show notes at spec.fm. And while you're there, go and listen to the other shows on spec. There are some incredible hosts and incredible content in the other shows that are on spec. So go and check those out. I know if you enjoy Developer Tea, you will enjoy some of the other content on spec. So thank you so much for listening. Don't forget to subscribe and leave a review in iTunes. And until next time, enjoy your tea.