DEV Community: Kevin McGillivray

How to get up to speed in a new codebase, fast

Kevin McGillivray — Tue, 21 Feb 2023 00:36:30 +0000

You're alone in a wooded wilderness. Dappled sunlight is sneaking through the forest canopy. You hear the steady hum of a stream in the distance. A compass hangs from your neck, and you raise it to check for north. You swing your backpack off of your shoulders, and open it to look for your map and your mission. Inside, instead of a map you find a hastily scribbled software architecture diagram, a laptop, and a note that says: "Find the React component that renders the Pay Invoice button, and the HTTP route that processes payment requests." You open the laptop and find the text editor, angle the screen away from the glare of the sun, and sit down on an old tree stump... the code orienteering race has begun!

Orienteering is a sport that involves navigating through an unfamiliar terrain using a map and compass. Participants race against each other to find a series of checkpoints or control points in the quickest time possible. The terrain can vary from urban parks to remote wilderness areas, and participants must navigate around obstacles and through various types of terrain, such as forests, hills, and streams.

While programming isn't a competitive race, code orienteering is an important skill for any developer. I imagine the experience of navigating an unfamiliar terrain might have some similarities to the challenges we experience navigating an unfamiliar codebase. When we join a team or project, we're often not starting from an empty repository. We're walking into an entangled, multilayered ecosystem of existing code often without clear paths to navigate.

In code orienteering, the goal isn't to get from point A to point B as quickly as possible, it's to get a better understanding of the big picture of the system as a whole, how it's organized, why it grew that way, and how to navigate it so that we can contribute to it more thoughtfully and effectively. There are many strategies to practice code orienteering, and here are some of my favorite tips and approaches for a successful orienteering adventure.

(Photo of orienteering gear by Jametlene Reskp on Unsplash)

Look for common landmark types

While every codebase has unique organization patterns and development tools and might be simple or extremely complex, every codebase also has similar basic needs: data and document storage, a user interface, and a way for views and databases to communicate with each other. In most codebases, the code is often organized around these needs and these areas can be used as landmarks just like rivers and mountains in a landscape.

When surveying an unfamiliar codebase, keep a list of a few basic questions in mind and search for clues to answer them:

How does the frontend request or receive data from the backend? The patterns for fetching and sending data and handling miscommunication or errors between server and client are some of the most important code in any codebase. It's a great place to start to get a survey of the overall landscape.
How many and what kind of databases are available? How is the data structured? Is it loosely defined or strictly defined? Some codebases have highly structured and rigid data storage, like solid rock layers, while others are more fluid and shifting, like sandy soil. Often there are multiple complementary layers in data storage from low level persistent storage to high level temporary caches. While you may not need to understand all the details of the data storage layer, understanding its interface and capabilities provides a helpful map of a large part of the codebase.
How do users access and interact with the frontend interface? How is the interface rendered or patterned? Is there a visual or audio interface? Is there a programmatic interface? The frontend of a codebase is like the flora and fauna of the landscape. It's varies widely between different codebases, just like the plants and animals in a desert are distinct from the ones found in a rainforest. Some codebases have well defined trails and patterns available for navigating the frontend code, while some are deeply entangled ecosystems that are difficult to traverse. All interfaces are multifaceted with different kinds of user accessibility—visual, audible, tactile, and programmatic. Understanding all the nuances of interface-related code can take a while, but making a list of the general patterns and tools currently in use can be handy when diving in to more specific tasks.

Make a visual map

In orienteering, participants are given a topographical map which they must interpret to navigate the landscape. If you're lucky, before your own orienteering through a codebase, you'll also have access to documentation from other developers that provides some guidance. Of course, very often this documentation is incomplete, and is likely out of date compared to the reality in the codebase. Codebases in active development are constantly evolving, and even the most energetic efforts to maintain documentation aren't perfect.

Even if you do have great documentation and helpful colleagues available, I recommend you make your own visual map of the codebase as you survey it using any visual note taking tool of your choice. It helps to make maps at several scales, one for the system as a whole, and several for subsystems within the codebase at different levels of detail. In the high level map you might give names to areas of the system and show how they interact, and in low level maps you might show specific function and module names within a particular feature.

Mapmaking is practical because when you inevitably get turned around after opening a few dozen files you can quickly see the path back to where you started and get reoriented. It also serves as a record of your progress, where you left off, and what's left to explore so you can more easily start again if you need to stop. You can also show it to colleagues who have more experience in the codebase as a visual representation of your understanding so they can help make it more accurate or point out paths you may have missed. So, take the time to read the trail guides if you can, including documentation for third party libraries and packages, but keep your own notes as well.

Leave only footprints

While making your way through an unfamiliar codebase, a lot of the code you discover may not have an obvious purpose. Of course ideally code is written in a way that is easy to understand through clear module, function, and variable names or has clarifying comments, but in practice there are always areas that are difficult to decipher. I often find myself thinking, "Is this code even necessary?! It seems pointless, I'd love to simply delete it!"

As good as it feels to delete seemingly disposable code, orienteering is not the time to make extensive changes. Sometimes, rarely, the code you find is truly pointless. It was made redundant by a change elsewhere, or left behind unintentionally during a previous feature deprecation. But much more often than not, the code is a perfect example of the law of Chesterton's Fence: don't remove a fence unless you understand why it was put there in the first place. By removing the code, all may seem well at first... until it's released to production and mysterious support tickets start appearing describing a new issue in a feature that has been working fine for years.

Code refactoring and new feature development are separate processes from orienteering. During refactoring, steps are taken to better understand the purpose of specific lines of code and make it safe to change them without introducing unintentional side effects or damaging the function of the existing code. During orienteering, the goal is to understand high level structure and general purpose of large areas of the codebase so that you can navigate more easily and keep the whole in mind when doing more specific refactoring work or new development.

With this in mind, when in an orienteering mode, only make changes to add comments or TODO notes for yourself to return to when you have time to do a more thorough investigation. These notes are a clear trail you or your colleagues can follow later, and makes areas for improvement easier to spot so that more legible paths can be created. They're a sign that "someone has been working here" and that the codebase has caretakers looking for ways to maintain it, which encourages everyone to tread more carefully.

Use developer tools to scout

Reading code is like reading a map. Running code is like actually hiking through the forest. We can get a pretty good sense of the landscape from the map, but the only way to fully understand the code is to actually run it and see what happens. If we're only reading code, we can make a lot of assumptions that may not be true, or miss important details that are only apparent when seeing actual inputs and outputs. Orienteering in a codebase involves both reading code and actually running it and observing the results.

Consider your normal developer tools to also be your pack of code orienteering gear. Run existing tests to see the real code in action, and write your own to see how the code responds in different scenarios. Use a debugger to trace code execution and inspect variables. And manually run the code with experimental, temporary changes to observe the results and gain a deeper understanding of its relationships. All of these approaches give a much more detailed experience of the code in reality and reveal hidden paths that might be missed with only skimming. Of course don't forget to undo your changes at the end and "leave only footprints"!

Make a campsite

In codebases that have been around for a while, it's impossible to get a complete picture in a day or a week, and complex codebases can take years to fully explore. Sometimes it's best to focus your efforts on one part of the codebase from which you can get a good view of other parts. By fully exploring one feature and beginning to make significant contributions to it through refactoring and new development, you can learn a lot about other areas of the code since similar patterns are often repeated elsewhere.

Consider this area your home base campsite you can return to when you get stuck or fatigued exploring or want to experiment more in depth with new ideas you might want to implement. Since everything is interconnected, focusing on one feature as a vertical slice of the code can be more efficient than exploring horizontally across all features.

Code orienteering is an essential skill for developers to get up to speed with a codebase and make effective contributions to the quality of the whole system. As you get started with a new codebase, you may be eager to start building new features and making improvements right away, but spending some time orienteering by finding common landmarks, making maps, and exploring with developer tools can make your contributions more effective, efficient, and thoughtful.

Do you have any favorite strategies for getting familiar with a new codebase? Please share them in the comments below!

By the way… I’m writing a book! Introducing The Code Gardener’s Almanac…

Do you have an itch to build a programming side project but aren't sure where to start? Are you finally starting to get the hang of programming, only to be left wondering, "now what should I make?" Do you feel dispirited by endless two-week sprints, confounding codebases, and tumultuous job markets and wonder if there's a better way?

Whether you're a seasoned pro or just starting out, The Code Gardener's Almanac offers approachable lessons on programming as a creative practice. In this mysterious handbook you'll learn why creativity is a skill and how to practice it like any other skill. You'll also learn how to apply new creative skills to build the project of your dreams, navigate uncertain career changes, and collaborate with your team to make great software.

Almost every developer was drawn to programming for its ability to bring ideas to life and the satisfaction of practicing a craft. The Code Gardener's Almanac will help you tap into this thrill and satisfaction, giving you the tools to expand your creative skills and find fun, wonder, and curiosity in your programming work. So, why wait? Continue your journey towards a more creative and fulfilling career in software engineering today: preorder The Code Gardener's Almanac.

Orienteering in Unfamiliar Codebases

Kevin McGillivray — Sat, 18 Feb 2023 17:43:12 +0000

You're alone in a wooded wilderness. Dappled sunlight is sneaking through the forest canopy. You hear the steady hum of a stream in the distance. A compass hangs from your neck, and you raise it to check for north. You swing your backpack off of your shoulders, and open it to look for your map and your mission. Inside, instead of a map you find a hastily scribbled software architecture diagram, a laptop, and a note that says: "Find the React component that renders the Pay Invoice button, and the HTTP route that processes payment requests." You open the laptop and find the text editor, angle the screen away from the glare of the sun, and sit down on an old tree stump... the code orienteering race has begun!

(Photo of orienteering gear by Jametlene Reskp on Unsplash)

Look for common landmark types

When surveying an unfamiliar codebase, keep a list of a few basic questions in mind and search for clues to answer them:

How does the frontend request or receive data from the backend? The patterns for fetching and sending data and handling miscommunication or errors between server and client are some of the most important code in any codebase. It's a great place to start to get a survey of the overall landscape.
How many and what kind of databases are available? How is the data structured? Is it loosely defined or strictly defined? Some codebases have highly structured and rigid data storage, like solid rock layers, while others are more fluid and shifting, like sandy soil. Often there are multiple complementary layers in data storage from low level persistent storage to high level temporary caches. While you may not need to understand all the details of the data storage layer, understanding its interface and capabilities provides a helpful map of a large part of the codebase.
How do users access and interact with the frontend interface? How is the interface rendered or patterned? Is there a visual or audio interface? Is there a programmatic interface? The frontend of a codebase is like the flora and fauna of the landscape. It's varies widely between different codebases, just like the plants and animals in a desert are distinct from the ones found in a rainforest. Some codebases have well defined trails and patterns available for navigating the frontend code, while some are deeply entangled ecosystems that are difficult to traverse. All interfaces are multifaceted with different kinds of user accessibility—visual, audible, tactile, and programmatic. Understanding all the nuances of interface-related code can take a while, but making a list of the general patterns and tools currently in use can be handy when diving in to more specific tasks.

Make a visual map

Leave only footprints

Use developer tools to scout

Make a campsite

Do you have any favorite strategies for getting familiar with a new codebase? Please share them in the comments below!

By the way… I’m writing a book! Introducing The Code Gardener’s Almanac…

Writing Code in 3D

Kevin McGillivray — Sat, 15 Feb 2020 15:37:32 +0000

Code is made of line by line instructions neatly arranged in exact syntax. It's all logic and text, so the text-focused side of the brain defaults to trying to write one line, then the next, in order from top to bottom.

But, counter intuitively, writing code is not linear. A script is more like sheet music than a novel. Sheet music appears linear on the page, but when played the musician jumps from section to section based on the written instructions and creates a multi-dimensional expression of the music through layers of sound. The musical notation is a flat summary of the real 3D experience. The resulting music is played linearly, but it has depth in layers and doesn't follow the exact order of notes on the page because the notation often includes instructions to repeat, skip, or jump to different sections.

Similarly, a script appears linear on the screen, but when it's actually run it's more accurate to imagine what happens inside the computer as a 3D workspace with depth, repeated processes, and jumps to different points in the script.

This misconception is often a roadblock when learning how to write code. For someone learning how to read and write code, it's tempting to think you need to start at the top of the file and work your way to the bottom. This leads to frustration because it's not only an inaccurate model of what happens when the script runs, it limits your flexibility to sculpt the code iteratively and discover solutions through drafts and experiments.

I imagine many developers "think in 3D" when programming without realizing it, and likely rarely stop to practice it or explain how it works. It happens naturally and subconsciously with more fluency in programming. However, it can and should be practiced, especially if you're a new developer feeling stuck (which everyone feels most days when they're learning). Combining the logical, text-focused side of writing code with the visual, space/time process of imagining what happens when it runs is a vital part of programming, and practicing it will likely help you get unstuck.

To illustrate how "thinking in 3D" works, let's try it together. I'll walk through writing a short script and talk through how it might be imagined in a 3D space so you can try it on your own. If you've experienced this style of thinking when writing code, or try it after reading this, let me know your thoughts!

The script as a landscape

Imagine a cube. It might be abstract and transparent, or it might be an imaginary landscape like a tropical island, a mountain, or a city block.

This cube is the space your script uses within the computer when it runs. Every instruction you write in your script will change this 3D space. (Feel free to draw this cube on paper and edit it as you write the script if it's helpful.)

If you're writing a script, hopefully you have a rough idea of what you want it to do. But this is where a developer might get stuck if they're not thinking in 3D. Where do we actually start? Thinking linearly, the only option is to start at the beginning, but it might not be obvious what the beginning should be because we haven't figured out the "solution" yet. If we knew every solution before we started, programming would be very easy. With the 3D landscape in mind, it's possible to start anywhere, beginning, middle, or end, and it's okay if the first attempt isn't the final solution because it can be adjusted later. We can build up the scene piece by piece and rearrange the pieces as needed, like deciding how furniture should be arranged in a room.

Let's say for our script we know we need variables that store a user's name:

const firstName = 'Jim';
const lastName = 'Henson';

Now let's imagine what effect this has on our 3D workspace. Maybe in one corner of the cube a box appears with the label firstName and inside the string 'Jim' is stored. Next to it, another box appears with the label lastName and the word 'Henson' inside of it. This is an imaginary representation of the computer's memory as it stores values in variables.

Now let's imagine we know we need a function that can give us a formatted full name:

function formatFullName(firstName, lastName) {
  return `${firstName} ${lastName}`;
}

This function also appears inside our 3D space, but since it's a function and not just a variable, it has different visual characteristics. If we're imagining a city block, maybe it's represented by a truck, or a crane, or some other symbol that indicates it can be used for a task, and it's given the label formatFullName.

Let's write an instruction for the function to be called:

const fullName = formatFullName(firstName, lastName);

Now, imagine what happens when the script actually runs. The boxes pop up with the names inside. The construction worker operating a crane pops up and waits for instructions. Then the worker maneuvers the crane to the name boxes, takes out each name, copies and combines them, and puts the result into a new box labelled fullName.

This is a small example, but you can imagine how this process might grow as more variables, functions, and other instructions are added to a script. A class might be imagined as a building or a tree. A whole web application might be a series of interconnected cubes, each with their own landscape of memory and tools. And when the script runs, we can imagine all the workers moving around completing tasks, sending messages to each other, boxes being created and destroyed, and complex structures being generated as the script does its job.

This imaginary, non-linear thinking is not only fun, it's also a more accurate representation of what happens when a computer runs a script. And it enables a more iterative approach to writing code, which is essential for exploring options and working toward refined drafts.

Do you ever find yourself thinking in 3D when writing code? Does this description seem familiar, or has it helped you think differently about writing code? Let me know your thoughts on Twitter or by commenting below!

Late Night Code Club Newsletter

It's midnight. You're huddled in the restricted section of the library, eyes glued to powerful tomes—Creating Killer Websites! Resilient Web Design! The Pragmatic Programmer! You get a missive from your co-conspirators in the Late Night Code Club—another night of adventurous learning is about to begin.

If you enjoyed this post and want to read more like it, I'd like to invite you to join the Late Night Code Club by signing up for the newsletter—it's a programming newsletter all about learning and teaching programming, code as a creative practice, and programming as part of an interdisciplinary education. In each newsletter you'll receive updates about new posts as well as other resources and ideas all about learning programming! It'll be short, interesting, and encouraging for learners and teachers. See you there!

Join the Late Night Code Club

Photo by Marius Masalar on Unsplash.

What to do After the Developer Bootcamp

Kevin McGillivray — Thu, 04 Apr 2019 13:17:59 +0000

Studying in a programming bootcamp can be a whirlwind experience—it’s a fast-paced, challenging, and immersive environment that pushes you forward into the world of a career in technology. The period of time after you complete a course is an important time to use the momentum of your learning to build habits that will sustain your programming practice for the long term—habits that professional developers do all the time for as long as they’re improving their craft! Here are three steps to take right away to start off on the right foot.

Learn something completely different

Use the momentum from the bootcamp to keep exploring on your own. Start learning a language or framework you didn’t learn at all during the course. You’ll be amazed at how different the experience is compared to when you first started learning programming. You’ll still get stuck and have a lot of questions, but you’ll have a layer of fundamental skills that speed up the process and deepen your knowledge as you go. Many skills transfer between different frameworks and languages, so start exploring something new to see how far you’ve come and how much more independent you are as a learner. It works best if this is connected to a personal project you really want to make yourself because that gives you motivation and focus for what to learn next in the sea of possibilities.

Learning shouldn’t be limited to a few years in school or a few months in a bootcamp—continuing to learn is a requirement for a successful career as a developer. The most important part of the bootcamp experience isn’t the specific languages or frameworks you learn, but the fundamentals of programming that you can use no matter where your technology exploration takes you in your career and personal projects. So use them right away and pick up another area of experience!

Connect with other developers

Make sure you have ways to regularly spend time with other developers outside of the bootcamp experience. A key to success and continued learning is spending time around other people doing the same thing. The bootcamp environment provides these opportunities for you, but after the course it’s up to you to integrate it into your life. This can mean meetups, informational interviews over coffee, social media (Twitter and Slack are good places to hang out with other developers) or keeping in touch with your mentors/teachers/other students from the bootcamp. As a mentor, I love hearing about what students are learning after the bootcamp!

It’s easy for impostor syndrome to set in at this point—you might feel like you don’t really fit in or can’t hold a conversation with other developers effectively. I’ve been in conversations with other developers where I can’t follow what they’re saying at all! The best thing to do is to be totally candid about where you are. You can say something like, “I just finished a bootcamp program where I learned X, Y and Z. Now I’m exploring A, B, and C, and I’m looking for opportunities related to foo, bar, and baz.” Plug in those variables, and whoever you’re talking to will get a good sense of your experience level and what you’re looking to learn next, which makes it much more likely that they can provide ample support and recommendations, connecting you to resources and people who can help with the next step.

Share what you learn

Build sharing into your routine. Write about what you’re learning, look for opportunities to help new developers, and share your perspective in conversations. It might not feel like it, but you’re already more experienced than many who are looking to learn web development, and soon you’ll be one of the more experienced developers in the room and people will be coming to you for guidance. Get into the habit now—it will accelerate your own learning and build even more connections over time.

These three habits are essential skills for developers no matter where they are in their careers. If a bootcamp is a sprint, these are the jogging habits that will keep you moving forward and learning. So pick a project, give it a shot, and tell us all about it at the meetup!

Late Night Code Club Newsletter

Join the Late Night Code Club

Daily Scripts—A Simple Exercise to Build Your Creative Skills

Kevin McGillivray — Tue, 02 Apr 2019 01:29:47 +0000

Jim, an old family friend, is a tinkerer. He puts his endless supply of curiosity and deep intelligence to use by doing things like collecting old radios and broken telephones, taking them apart, and seeing if he can fix them. Or training his dog to do sequentially more detailed and challenging tricks. Or planting cherry trees in his yard. We'll come back to Jim in a minute.

The Artist’s Way is a classic book on creativity by Julia Cameron. One of the exercises in the book has become a standard practice for writers and artists: the daily pages. The idea is simple. Every day, you wake up and write three pages. The rule is you must sit down, start writing, and not stop until three pages are filled. This exercise inspired one of my favorite sites, 750words.com.

Like Jim's curious wandering, I think of this exercise as a kind of tinkering for the mind. Tinkering means you explore somewhat aimlessly, but not uselessly. You’re generally fixing and organizing things, but you may not have a specific plan or any grand ambitions for what you’re doing. For a writer, this wandering has many benefits. It gets your pen moving when you may not feel like moving it, it builds a daily habit of consistent progress, and it reveals hidden thoughts and connections you may not have discovered without the exercise.

As my painting teacher would say, the paintbrush should be moving more than it’s not moving. The rule to not stop writing short circuits the tendency to second guess what you're writing. Stopping to sit around and think doesn’t do a writer or a painter any good, it just blocks the flow.

This may seem counterintuitive as a programming exercise. Programming is thinking. It's slow and careful thinking, translated into instructions a computer can understand. Of course a programmer needs to think! So much of our time spent programming, either as an employed developer or as a student or hobbyist, is spent focused on a specific project. When you sit down, you already have a goal in mind. But I don't think this needs to be the only way to write code. Code can be used to freely tinker as well. Instead of daily pages, we can write daily scripts, and with a little adjustment to the exercise we can get the same benefits a writer finds in the daily pages.

Try this. Before you start your “work” for the day, write a script. You can do this in your text editor, on a site like glitch.com or codepen.io, or in your language’s command line interface. Instead of setting a number of lines of code to write or setting a rule to not stop typing once you start, set a time limit for twenty minutes. It might feel strange at first to write code without a goal. But spend twenty minutes tinkering with code. You might explore a language feature you’ve used but don’t fully feel fluent in. You might end up writing a script to automate a manual task you do every day. You might end up discovering a solution to a problem you’re actually working on in your “real work.” You might discover a cool pattern that might be useful later. You might not end up with anything useful at all. Or you might end up writing the first 50 lines of a new and very useful open source library or interesting project that you’ve quietly been thinking about for months but never had the chance to explore and recognize.

Twenty minutes a day tinkering seems almost like nothing at all. But like brushing your teeth, the daily habit has a great benefit over time. Just like writing, programming can be a way to explore and discover ideas just beneath the surface that haven't been expressed yet. What you discover might even be far more valuable than anything you write when you’re trying to get real work done. Or at the very least, it can reconnect you with why code is fun if you’ve been feeling burnt out on the job or get you started on a new idea if you have absolutely no idea where to start.

What programming exercises do you do to stretch your creative muscles?

Late Night Code Club Newsletter

Join the Late Night Code Club

Code as a Creative Practice

Kevin McGillivray — Sat, 09 Mar 2019 18:30:57 +0000

In the first Late Night Code Club email, I talked about "code as a creative practice." I don't fully understand what I mean by that! That's one reason I wanted to write this newsletter. To figure out what it means to approach programming as a creative practice.

So often when we talk about programming we focus on technical skills. That stuff is fun to learn—if it wasn't programming wouldn't be interesting in the first place. But eventually technical questions fade and we're left with harder to answer questions. What should I create? How should I do it? How do I come up with an idea or explore a problem when I'm stuck and the answer isn't that I forgot a bracket?

Technical skills and knowledge can't answer these questions. To work toward an answer requires creative meta skills. These skills aren't unique to computer programming. They can apply to anything from writing software to writing a novel or making dinner.

These skills include...

Cultivating curiosity
Taking breaks
Switching between big picture thinking and small details thinking at the right time
Being comfortable with experimenting
Generating lots of ideas (more than you feel comfortable generating)
Cutting out/saying no to ideas that aren't a good fit
Building logical structure and expressing intuitive style
Cultivating beginner's mind
Paying close attention
Going slowly and carefully
Going fast and roughly
Being disciplined and making things right when you know they're wrong
Letting go of the inner critic and inner dialog
Being patient

For every creative skill there is an opposite skill that is equally important to master. It's necessary to be able to come up with lots of ideas, no matter how silly or unrealistic they are. It's also necessary to be able to drop ideas that aren't a good fit. It's also necessary to not do those two things at the same time if you want to avoid frustration.

Approaching programming as a creative practice emphasizes benefits beyond the possibility for a valuable career. As we look to work more and more for meaning, it's helpful to remember that programming is valuable even when it's not done solely for work. An artist keeps a creative practice to create meaningful, useful, valuable, and beautiful things, and also to grow, learn, explore, and connect with themselves and their community. Keeping a creative practice is about the work produced but it's really about practicing how to live. The studio is the workshop where we can discover insights and truths and put them into a shareable form. That might be a novel or a painting, but it can also be a website or software.

A creative practice requires tending. The work is never done. It continues as a discipline of experimenting, improving, and exploring. The rewards are infinite because the ultimate goal isn't to finish this specific piece or that one, it's to keep learning and to share what you learn.

A creative practice deepens your mastery of a craft, but it also deepens your skillful navigation of life's path. The creative skills you learn in a practice can be applied to everything you do, from talking with a friend to growing a family. This perspective reveals the siren song of constant productivity as a trap. Taking breaks, having or not having kids, taking time to play a video game or watch a silly movie aren't seen through the lens of potential distraction from work, they're seen in the wholeness of the creative practice. Both support the other.

Whether you are working full time as a software engineer or a hobbyist developer exploring code, code as a creative practice has the same value: self expression and exploration and connection to the things that matter most to you. Programming is not easy to learn. It can be a frustrating process. But approaching it with curiosity and a wider sense of its value as a creative practice can make the journey smoother.

Introduction to the "Frontend" and "Backend"—Web Development Fundamentals

Kevin McGillivray — Mon, 22 Jan 2018 16:44:29 +0000

So, you want to make a website?

Yay! That's a great idea—making a website is a rewarding creative project that is not only a fun and valuable skill on its own but also a great way to explore your interests and share them with many, many people (or just a few if you want!).

Usually when someone starts learning how to make a website, the typical starting place is with HTML and CSS. And that's a great place to start!

However, while you're doing that, let's take some time to take a wider look at how websites work underneath the hood. Understanding the big picture will put what you're learning into context and help you plan a clearer learning path to dig deeper into web development.

The frontend and the backend

Two key words to understanding how websites work you might have heard before are the frontend and the backend. These are often talked about (and taught) separately and seen as two very different things, but they are both essential and closely connected in most web development projects.

In simplest terms, the frontend is any code that runs in the browser and the backend is any code that runs on the server.

The server

The role of the backend code on the server is very basic on the surface:

Listen for requests.
Respond to requests.

In a common example, a request might be someone trying to access the home page of a website. The server receives that request and sends back the HTML, CSS, JavaScript, images, and any other files associated with that page.

However, these requests and responses can be much more complex than this simple example—the backend code also typically handles retrieving and storing data in a database, dynamic page rendering, security and authentication checks, intensive image processing, and many other processing heavy tasks in response to incoming requests.

The responses generated can also take many forms. They might be straightforward like good old HTML and CSS files or assets like images and audio files, but they can also take the form of data files such as JSON.

Backend code is written in many languages—Ruby, PHP, Python, Java, and JavaScript are common options. Backend web development work often includes what could also be called "system administrator" tasks in addition to writing the actual code to make the website work. These include installing server-side tools, configuring databases, etc.

Learning a backend language opens many possibilities for what kinds of features you can build on a website. It allows you to take a static page and add a huge range of new ways to interact with the site. The best place to get started with backend development is likely a tutorial for one of the languages above, followed by exploring backend frameworks or content management systems for the language you're interested in like Ruby on Rails (Ruby), Express (JavaScript), Wordpress (PHP), Laravel (PHP), Django (Python) or many others.

The browser

While the server's response can come in many forms, let's return to our example of a common web page request. After processing the request, the server responds with a collection of HTML, CSS, and JavaScript files along with any additional assets the requester might need.

The browser then receives these files and processes them. The code in these files is frontend code because it runs on the browser-side.

The main role of the frontend is to:

Request information (data, files, etc.) from the backend.
Display or render that information.
Listen for user input (clicks, taps, scrolls, hovers, typing, voice commands, etc.).
Respond to user input.

For the first role, many requests are handled by the browser itself when a link is clicked or a new URL is entered. New information can also be requested after a page has already loaded with browser-side JavaScript code.

The display of data is defined by HTML and CSS processed by the browser. The HTML tells the browser about the structure and content of the page, and the CSS tells the browser how to display it on the screen.

As the user interacts with the display, both the browser and the page's JavaScript code listen for the interaction and respond appropriately—either with built in browser functionality or custom responses defined in JavaScript.

Writing the HTML, CSS, and JavaScript code for the browser is frontend programming. Writing this code often relies on processing from the backend, so the two are closely related despite being defined separately.

There is a huge array of libraries, frameworks, and other tools for the frontend, ranging from plain HTML, CSS, and JavaScript to tools like jQuery, React, and Angular, but the role of the frontend remains the same no matter what tool you're using. The tools are simply different ways to solve similar problems.

The world of web development is a huge playground to explore. Wherever you start exploring, having a map of the frontend and backend and what they do will help guide your next step. If you're not sure where to start, I recommend trying a little of both to get a taste and then follow your curiosity!

Questions? Comments? Clarifications? Let me know on Twitter or the comments below!

Late Night Code Club Newsletter

If you enjoyed this post and want to read more like it, I'd like to invite you to join the Late Night Code Club by signing up for the newsletter—it's a programming education newsletter all about learning and teaching programming. We're exploring new approaches to learning and teaching, code as a creative practice, and programming as part of an interdisciplinary education. In each newsletter you'll receive updates about new posts as well as other resources and ideas all about learning programming! It'll be short, interesting, and encouraging for learners and teachers. See you there!

Join the Late Night Code Club

The Four Layers of Programming Skills

Kevin McGillivray — Mon, 18 Sep 2017 15:22:52 +0000

When learning how to code for the first time, there's a common misconception that learning how to code is primarily about learning the syntax of a programming language. That is, learning how the special symbols, keywords, and characters must be written in the right order for the language to run without errors.

However, focusing only on knowledge of syntax is a bit like practicing to write a novel by only studying grammar and spelling. Grammar and spelling are needed to write a novel, but there are many other layers of skills that are needed in order to write an original, creative novel.

Similarly, to be developer and write original, creative code we need other layers of skills in addition to syntax. Here is one way to organize these skills into what I call the four layers of programming skills:

Syntax skills

This is the layer that is most often focused on in the early learning phase. Syntax skills essentially means how to read and write a programming language using the rules for how different characters must be used for the code to actually work.

Being the first layer doesn't mean it's not important! This can be deeply challenging to master and is an essential skill that needs practice to build fluency and apply the other layers.

Programmatic thinking skills and programming concepts

Programmatic thinking means how to think like a computer and translate a process into a specific set of instructions that a computer can understand. It also means understanding programming concepts like data, variables, functions, objects, etc. This isn't about writing the correct symbols in the right order, it's about how to communicate a specific series of steps to the computer that it's capable of completing.

Humans are capable of both intuitive/visual thinking and logical/verbal thinking. If you were asked to identify the tallest person in a room, you could scan the room visually and quickly pick out the tallest person. Computers can't do that (yet). So, for a computer to do the same thing, we'd need to come up with a more specific and logical process for identifying the tallest person.

Coming up with that logical process is programmatic thinking. In this example, you could ask everyone to write down their name and height, and then you could sort through the thousand slips of paper to put them in order. You could ask everyone to line up, and then compare the height of the first and second person in line. Take whoever is taller from that comparison and compare their height to the third person in line. Whoever is taller in that comparison, compare their height to the fourth person in line, and so on until the end.

To write code, you need to be able to define this type of logical process, and then understand how that translates into the way a computer processes information. The syntax is then simply the standard used to communicate the process to the computer.

Creative skills

If you know the syntax for a programming language and you have programmatic thinking skills, you still might run into difficulties writing code. When you're faced with a programming problem, you still need to answer the question, "how exactly do we get from point A to point B?" Even with a mastery of syntax and concepts, you'll still be faced with a blank page when you sit down to write.

Just like with the tallest person problem, there is typically more than one way to do something, and the more complex the problem is, the more ways there are to solve it. Syntax has one right answer—it either works or it doesn't. Programmatic thinking has many possible answers. There often isn't an answer you can simply copy and drop into your code, and even the problems that do have common solutions with examples you find online may have even better solutions that haven't been created yet.

At some point in the process, in order to write original and unique code, you're going to need creative skills. There's a myth that creativity is something you're born with and that it can't be taught, practiced, or learned. The truth is that creativity is a skill just like any other skill, and it can be practiced and improved. Creative skills include things like:

Experimenting
Rough drafting/sketching code
Brainstorming
Editing
Outlining
Taking breaks
Researching

These creative skills are necessary to figure out an answer when it's not obvious what it should be—to navigate going from a rough draft to a final draft with all the bumps and detours in between.

The best thing about these skills is that they don't just apply to programming—they can apply to anything you're doing from cooking to writing to playing a sport, and if you have other areas where you practice creativity, that can help you apply more creative skills to programming.

Interdisciplinary skills

Writing code is never just about writing code—writing code is always connected to something else. Maybe you're making a website about tea, or a fitness app, or a website for a local car maintenance shop—code always exists in a way that's connected to other topics, not in a vacuum by itself. Having skills and knowledge in lots of other areas besides programming not only helps you make projects related to those areas in a more thoughtful way, skills borrowed from other fields can influence the way you write code and help you come up with solutions you wouldn't have considered otherwise. Balancing programming with curiosity and exploration of other topics makes programming even better!

As learners and teachers, it's important to identify all of the skills we need to learn in order to be a developer. Different students find different layers easier or more challenging than others. Many people who have no problem remembering syntax struggle with programmatic thinking. Many people who have no problem with programmatic thinking have a very difficult time remembering syntax. As learners, recognizing this makes it easier to get unstuck when things are difficult because we can identify the area that is most challenging at the moment. As teachers, when we recognize the whole spectrum of skills that need to be developed, we can make sure we create exercises that cover the entire range.

Thoughts, questions, comments? Let me know what you think on Twitter or in the comments below!

This post was originally published on my personal site.

Late Night Code Club Newsletter

Join the Late Night Code Club

Mindful Code Exercises

Kevin McGillivray — Tue, 05 Sep 2017 14:58:16 +0000

One of my favorite ways to explore mindfulness is to integrate a mindfulness exercise into an everyday activity—washing dishes, driving a car, eating dinner, sweeping the floor. As the Zen saying goes, "Chop wood, carry water."

Since I spend so much time writing code, I've been experimenting with ways to connect mindfulness exercises to daily activities related to programming.

Besides being a way to have a more mindful day overall, practicing mindfulness in proximity to programming can help with many common situations that arise when coding. Writing code is a complex experience—it often requires a high level of focus, and moments of frustration or confusion can often bring up strong emotions and mental cloudiness.

Getting stuck for hours with mounting frustration
Frustration when learning new skills or concepts
Getting addicted to writing code
The complications of collaborative projects (distraction, communication)
Getting bored and losing interest in a project or programming in general

Here are a few of the mindfulness exercises I've experimented with. Many of them are simply ideas to start from, so if you try them please experiment with them and let me know how it goes!

Meditation bookends

Start each coding session with a few minutes of sitting meditation (Headspace can help) and end each session with a few minutes of walking meditation.

Pre- and post-commit breathing

Take three deep breaths before and after each Git commit and Git push.

Pull request gratitude/loving kindness

When creating or reviewing a pull request, take a few deep breaths and repeat a mantra that is focused on gratitude and kind speech. Here are some ideas that are loosely based on mantras from Thich Nhat Hanh's book, Work. I would recommend coming up with your own, formal or informal, to match what you prefer!

When reviewing a pull request:

Reviewing this code,

I am grateful to those that wrote it

and for the tools that were used to write it.

May this code bring health, peace, and well-being.

When creating a pull request:

Code can travel thousands of miles and affect many people.

I vow to write code mindfully and lovingly.
May this code create mutual understanding and peace.

Tab sweeping

When ending your work for the day or switching to a new task, review each open tab in the browser and text editor and close each one that you don't need while taking a breath.

Naps and Food

Rest when you're tired, eat when you're hungry, drink when you're thirsty.

Daily writing

I've found that daily writing (such as 750words.com) is one of the best mindfulness exercises and maybe helpful to integrate into a daily routine.

If I try any other exercises, I'll update the list here. Let me know on Twitter if you try any of these and how it goes!

This post was originally published on my personal site.

Did you enjoy this post and want to read more like it? I’d like to invite you to sign up for my programming education newsletter—it’s all about learning and teaching programming. In each newsletter you’ll receive updates about new posts as well as other resources and ideas all about learning programming! It’ll be short, interesting, and encouraging for learners and teachers. See you there!