Vox

Leitura de 16 min

The Great Developer Mindset - Demystifying Code

Summary

Jonathan Cottrell introduces the first episode of a new series called ‘Adopting the Great Developer’s Mindset.’ The series aims to explore how great developers think, focusing on their approach to problems and learning rather than specific technologies or frameworks. This inaugural episode is dedicated to ‘demystifying code’ for both new developers and non-developers who want to understand how code works.

Cottrell begins by addressing a common perception: many people view code as incomprehensible gibberish, a ‘different language’ that causes their eyes to glaze over. He argues this stems from viewing code as a non-human means of communicating directly with a computer. In reality, most code is written for humans to communicate with each other; computers merely translate it. He draws a parallel to reading a book: if you only see letters on a page, you miss the story. Code, similarly, is a representation of ideas, not an exposure of cryptic computer internals.

To help listeners comprehend code, Cottrell presents three fundamental ideas to identify. First, identify the writing style. Code has an author (or authors) and a style influenced by the programming language, the author’s preferences (clever vs. verbose, comment-heavy vs. sparse), and programming paradigms (functional, declarative, imperative, object-oriented). Understanding the style is crucial, just as knowing you’re reading a book of poems versus a novel sets proper expectations.

Second, identify the setting. This means understanding where the code runs physically (server, client/browser, native device, Raspberry Pi) and conceptually. Is it part of a larger system or legacy project? Does it collaborate with other systems or have dependencies? Using the book metaphor, is the code a standalone story, part of a series, or fan fiction requiring prior knowledge? Understanding the environment and context is key to comprehension.

Third, identify the plot of the code. Unlike most books, code rarely reads top-to-bottom. It’s more like a choose-your-own-adventure novel with dynamic entry and exit points. One must ask: What is the big idea or full story? What is the starting point and outcome? Why does this code exist? By understanding the purpose, you can identify the main ‘plot points’—like finding files related to database structure or user login in a web application. Cottrell concludes by encouraging listeners to provide feedback on whether to continue the series.

Recommendations

Podcasts

  • Other shows on Spec.fm — Cottrell recommends checking out other shows on the Spec network, suggesting that if listeners enjoy Developer Tea, they will likely enjoy the other content hosted there.

Topic Timeline

  • 00:00:00 — Introduction to the Great Developer Mindset series — Jonathan Cottrell welcomes listeners and introduces the new series ‘Adopting the Great Developer’s Mindset.’ He explains the series will focus on how great developers think—deconstructing problems, learning new languages—rather than specific frameworks or technologies. This first episode is about demystifying code.
  • 00:01:29 — The problem with how people perceive code — Cottrell addresses the common perception of code as incomprehensible ‘gibberish’ or a ‘different language.’ He argues this view is flawed because it treats code as a non-human way to talk to computers. In reality, code is primarily for human communication; computers just happen to understand it. He introduces the core analogy: code is like a book, where letters represent a story, not just symbols.
  • 00:03:44 — Three fundamentals for comprehending code — Cottrell outlines the three basic ideas needed to comprehend code, analogous to learning to comprehend a novel in grade school. He will explain how to identify: 1) the writing style, 2) the setting, and 3) the plot of the code. These steps help demystify code for beginners and experienced developers alike.
  • 00:03:56 — Step 1: Identify the writing style — The first step is to identify the code’s writing style. All code has an author (or multiple authors), and style is influenced by the programming language, the author’s tendencies (clever vs. verbose, comment usage), and programming paradigms (functional, declarative, etc.). Understanding the style is crucial, just as knowing you’re reading poetry versus a novel sets proper expectations for structure and content.
  • 00:07:00 — Step 2: Identify the setting — The second step is to identify the setting—where the code runs physically (server, client, native device) and conceptually. Is it part of a larger system, a legacy project, or does it have dependencies? Using the book metaphor, is it a standalone story, part of a series, or fan fiction requiring prior knowledge? Understanding the environment and context is essential for comprehension.
  • 00:08:21 — Step 3: Identify the plot of the code — The third step is to identify the plot of the code. Unlike books, code rarely reads top-to-bottom; it’s dynamic, like a choose-your-own-adventure novel. One must find the entry/exit points, understand the big idea, starting point, outcome, and purpose. By understanding why the code exists, you can identify the main ‘plot points,’ such as database files or login views in a web app.
  • 00:10:55 — Conclusion and call for feedback — Cottrell recaps the three steps (identify writing style, setting, and plot) and thanks listeners for this first installment of the ‘Adopting the Great Developer’s Mindset’ series. He asks for feedback to determine if he should continue the series. He also promotes other shows on the Spec network and reminds listeners to subscribe and leave a review.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2016-05-27T09:00:00Z
  • Duration: 00:12:05

References

Podcast Info

Transcript

[00:00:00] 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 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

[00:00:29] 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 developers think, not talk about specific types of code necessarily, and not talk about, you know, what, what framework should I use now? What framework should I learn today, and not talking about those kinds of things, but instead talking about

[00:00:59] the

[00:00:59] 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

[00:01:29] 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 the

[00:01:59] it, but rather for humans to communicate with each other, we have to write code that other

[00:02:06] humans understand and that the computer can translate to zeros and ones. Now, when you read

[00:02:12] a book, if you simply view that book as letters on a page, you miss the point. The proper way to

[00:02:20] enjoy a book is to recognize that those letters represent a story. And you’re going to enjoy the

[00:02:30] book most if you immerse yourself in the story. When you read a book over a period of time,

[00:02:38] particularly fiction books, that story sticks with you, even when you are not reading the book.

[00:02:43] Now, how is that the case? Well, the words on the page represent something more. And all of you may

[00:02:50] be listening.

[00:02:51] And thinking, well, this is kind of obvious, right? Words on a page represent communication

[00:02:56] and a story. But code is very similar to this. And this is something we don’t talk about very often

[00:03:03] because a lot of people see code and once again, their eyes glaze over. But code is like a book

[00:03:10] in a lot of ways. Code should be considered a representation of ideas, not an exposing of the

[00:03:17] computer’s kind of cryptic internal working.

[00:03:20] So how can you start demystifying code, especially if you’re a young developer,

[00:03:27] even if you’re not a developer, if you want to understand how code works and you’ve never

[00:03:33] written a line of code in your life, just like in grade school, when you learned how to comprehend

[00:03:38] a novel. In today’s episode, we’re going to talk about the fundamentals of comprehending code.

[00:03:44] I’m going to give you three basic ideas for comprehending code, basic ways,

[00:03:50] things that you need to identify specifically to comprehend code.

[00:03:56] Number one is identify the writing style. Identify the writing style. Code, just like books,

[00:04:03] has an author. All code has been authored by someone or perhaps multiple people. Usually

[00:04:12] multiple people have written whatever piece of code you’re looking at. If you start reading a

[00:04:17] book of poems, expecting a novel.

[00:04:20] might be surprised with the lack of narrative structure, or maybe the seemingly erratic

[00:04:25] arrangement of words, or the lack of punctuation. However, if you understood the writing style from

[00:04:32] the beginning, you can approach the book of poems much more holistically. You can understand it a

[00:04:39] whole lot better when you approach it understanding that it’s a book of poems. The style of code is

[00:04:45] influenced by a lot of things, and you need to understand what style of code you are reading.

[00:04:53] The style, of course, is influenced by the language it is written in. This is actually

[00:04:58] true for books as well. Obviously, the style of a book is influenced by the linguistic structure,

[00:05:05] but with code, if you have a different language, a different syntax, that code is going to

[00:05:10] be shaped differently. It’s going to look different. It’s going to feel different.

[00:05:15] It’s going to be shaped differently. It’s going to look different. It’s going to feel different.

[00:05:15] It’s going to have different features based on whatever features that particular language

[00:05:20] supports. You may see a lot of brackets, or you may see no brackets at all. You may see a lot of

[00:05:26] numbers, or a lot of quotes, or you could see a lack of those things. It’s important to understand

[00:05:32] that the language itself is going to influence the style, but then the author and the job of the

[00:05:38] code, both of those things will heavily influence the style as well. You can have a different

[00:05:45] paradigms for constructing code that either the author or the language or both can influence

[00:05:52] heavily. For example, functional, or declarative, or imperative, or object-oriented. There are a lot

[00:05:58] of these different paradigms that you can go and Google in your free time to understand them a

[00:06:03] little bit better. They’re beyond the scope of today’s episode, but you need to understand

[00:06:08] the style coming into it. You may also have a particular author who’s more clever, or maybe

[00:06:15] a particular author who is more verbose, somebody who likes a lot of comments versus somebody who

[00:06:21] doesn’t like a lot of comments. Now, we aren’t saying the way that the code should be. We aren’t

[00:06:25] saying the way that the code should be because, in my personal opinion, for example, I don’t really

[00:06:30] like to see clever code. Sometimes that’s a little bit more difficult to approach as a developer,

[00:06:36] but you will very likely come upon some code that isn’t perfect. In fact, you absolutely

[00:06:43] will come upon some code that isn’t perfect. You will come upon some code that isn’t perfect.

[00:06:45] You will come upon some code that isn’t perfect. You will come upon some code that is different from

[00:06:47] the style that you would write that same piece of code in, but you need to understand style to

[00:06:52] be able to understand a piece of code. So, number one, identify the writing style. Number two,

[00:07:00] identify the setting. Quite literally, where is this code being run? Is it being run on a server?

[00:07:07] Is it being run on the client, maybe in a browser? Is it being run on a native device,

[00:07:13] or maybe it’s being run on a server? Is it being run on a server? Is it being run on a server?

[00:07:15] Is it being run on something like a Raspberry Pi, or perhaps it’s being run distributed across

[00:07:20] a lot of virtual servers or something like that? So, you need to understand where the code is being

[00:07:26] run. You also need to understand where it is being run conceptually, right? So, is this code

[00:07:32] collaborating with other systems? Do other things depend on particular parts of this code?

[00:07:38] If we take our book metaphor further, perhaps the book is one in a series of other books,

[00:07:44] or maybe it’s fan fiction that requires a predetermined knowledge of the larger world

[00:07:50] that that particular fan fiction story takes place inside of. Is the code a part of a legacy

[00:07:57] project that is maybe being slowly updated? Or maybe the code has a whole suite of tests you

[00:08:03] can run. Or even worse, maybe that code is full of errors, and you have the opportunity of

[00:08:10] discovering those errors. Understand the setting,

[00:08:14] of the code that you are trying to get into, trying to comprehend. Identify that setting.

[00:08:21] That’s number two. Number three, identify the plot of the code. And we’re taking that book metaphor

[00:08:28] even further. Identify the plot of the code. Unlike a book, or unlike most books at least,

[00:08:37] most code doesn’t read top to bottom. You’re not going to really be able to understand it if you

[00:08:41] read it top to bottom. Instead, it’s going to read a little bit more, and it’s going to read a little bit more,

[00:08:44] like a choose-your-own-adventure novel. If you try to comprehend the code in the wrong order,

[00:08:50] you’re going to get lost and frustrated quite easily. But there’s not just one order. That

[00:08:55] code is dynamic. Unless you are reading a script, which may actually read top to bottom,

[00:09:01] most of the time, code has different entrance and exit points. So you need to understand what

[00:09:07] those are. Where is it being called into? What function starts the code? Does it read from the

[00:09:14] top to bottom and execute from top to bottom? Or does it maybe create an event listening system

[00:09:21] that watches a user’s actions? This is true, for example, for Gulp Watch, if you’re familiar with

[00:09:28] Gulp Watch, as well as JavaScript in the browser. This is the way that it runs. So ask yourself,

[00:09:35] what is the big idea, the full story of this particular piece of code? How does it fit in

[00:09:43] with the things?

[00:09:44] Now, that goes back to the setting a little bit, but what is the plot? What is the starting point

[00:09:50] and the outcome? Why does this code exist? Do I have enough information to understand the big

[00:09:57] idea? It may be that the piece of code that you’re looking at doesn’t have the full plot. Maybe you’re

[00:10:02] coming in in the middle of the story. Once you understand the purpose for the code, you will

[00:10:09] likely be able to identify the big plot points in the code.

[00:10:13] You are working on, for example, if you’re working on an application that has a database

[00:10:18] and users can log into it, maybe there’s roles. You can reasonably assume that you’re going to

[00:10:24] find some files related to the database structure, some files related to user access, maybe some

[00:10:31] views for the user login. These are the ways that you’re going to identify, you know, what is the,

[00:10:37] what are the main actors? Where are the plot points? And so you need to do these three

[00:10:43] things when you’re trying to understand new pieces of code. Number one, identify the writing

[00:10:48] style. Number two, identify the setting. And finally, number three, identify the plot of the

[00:10:55] code. Thank you so much for listening to Developer Tea today. I hope you enjoyed this first installment

[00:11:03] of the Adopting the Great Developer’s Mindset series. And if you did, please let me know,

[00:11:09] because I want to know if you guys would like for me to continue this series,

[00:11:13] with more content talking about how a great developer thinks, how a great developer

[00:11:19] approaches a problem. Thank you so much for listening to Developer Tea. We did not have

[00:11:25] a sponsor in today’s episode, but still go and check out the show notes at spec.fm.

[00:11:32] And while you’re there, go and listen to the other shows on spec. There are some incredible

[00:11:38] hosts and incredible content in the other shows that are on spec. So go and

[00:11:43] check them out.

[00:11:43] Check those out. I know if you enjoy Developer Tea, you will enjoy some of the other content

[00:11:48] on spec. So thank you so much for listening. Don’t forget to subscribe and leave a review

[00:11:53] in iTunes. And until next time, enjoy your tea.

Visão de gráfico