DEV Community: Timothy Merritt

It’s Okay to Feel Like You Suck: Mental Health Check-In

Timothy Merritt — Thu, 14 Jan 2021 18:41:58 +0000

Hi, friends. The world has been a pretty harrowing place lately, particularly if you live in the U.S. (although if you live in New Zealand, please adopt me). Stressors can and do come from every corner of the big bad world, and none of it makes being a developer any easier. Here are a few tips to maintain your equilibrium in an already challenging field.

⚠️ Note: These tips aren't exhaustive, and if you're dealing with more serious issues, you should seek help from trained professionals. Check the resources listed at the end for options.

Fail

No, really. A large part of being a developer is constantly learning new things: learning new tech stacks that sometimes unravel previous knowledge, new ways of doing things you’ve already "mastered", but above all learning how to learn. And along with diving into new, scary subjects comes a propensity to get things wrong. That’s okay—get things wrong. Fail. Screw-up magnificently (just try to do it before you push to main). Every mistake you make helps you understand why it was a mistake, and how to improve the next time around. It doesn’t mean you’re a failure, it just means you’re learning.

xkcd 1739

The more comfortable you are diving into the unknown and making a mess the better adapted you’ll be as you continue on your journey. So fail spectacularly, learn from what went wrong, and then pick yourself up and keep going.

Pace Yourself

Are you in a rush to learn everything there is to know about development? Do you have short term plans that involve mastering multiple languages and workflows? Great! It’s good to be ambitious and eager, but literally no one knows it all. Know why? It’s impossible. The scope and depth of even "just" learning web development is massive. There will always be people who make everything look easy. There will always be more to do, more to learn, and more to make.

xkcd 1190

Keep your focus on what you’re doing, and whether that means spending twelve hours a day coding (don’t do this long term) or trying to squeeze a half hour in somewhere between putting the kids to bed and trying to get some sleep (you’re a superstar), remember that you’re still making progress. Baby steps still carry you forward, and even if you end up taking a few steps back, you’re still moving. Acknowledge your milestones, and enjoy the ride.

Ask For Help

Just like how no one person can contain all the knowledge of the tech field, no one person built all of it on their own. Development can so often feel like a solitary endeavor (especially if you’re learning on your own), and by extension when you’re out of your depth it can seem like you’re the only one struggling. But one of the best ways to get out of the deep end is know your limits, and know when to reach out for help. Ask questions, seek advice, listen to feedback, collaborate with others, and realize that more often than not, two heads really are better than one.

xkcd 1831

Asking for help in itself can sometimes feel impossible, but taking that chance can act as a reminder that so many others have been where you are, struggled with what you’re struggling with. Giving and receiving that empathy can reinforce that we’re all human, we all make mistakes, and sometimes we all need some help. Asking for it isn’t weakness—it’s a valuable skill.

Stop Coding

Hear me out. I don’t mean quit altogether, but when it feels like no matter what you do you can’t get a print statement to work, or a git commit to take, and you’re ready to write “Hello world” with the entrails of your computer… it’s time to step away for a little while. Take a break. Take a long break if you need to. You could read a book, play a game, watch a movie, meditate, practice a hobby you have, or eat large quantities of chocolate—but what's most important is taking the kind of break that works for you. The point is to let the things you were stuck on melt away for awhile, so when you come back to them you do so with fresh eyes.

xkcd 303

Don’t feel guilty when you need to press pause for a while, and don’t let anyone tell you that you must always keep pushing on at all costs. You’ll burn out, or start to resent what you’re doing. Particularly when you’re learning, your brain needs time to absorb the new information, and it can’t do that if you’re constantly pushing it. Learn when to stop, and you’ll be surprised how often you’ll end up finding your way back more clearly.

Be Kind to Your Butt

You know what I’m going to say. Do some stretches. Get up and go outside. Go for a walk. Pretend you’re an elite hacker being chased by mercenaries and let the fear of a convoluted plot motivate your exercise. Eat as healthy as you’re able and combine that with some daily exertion, and you’ll find your brain works much better when you’re trying to solve a difficult development task.

xkcd 189

I’m not going to belabor this point, since we’re all differently abled and divided by our respective socioeconomic circumstances, but just do what you can to get some helpful nutrients in your body and some exercise, and your brain will thank you. No, the chocolate from earlier doesn’t count.

Putting it All Together

It’s a rough time right now, and if you’re learning or working in development it can be hard to juggle everything at once. So remember: it’s okay to fail, keep a steady pace, ask for help, take breaks, and try to eat something green and break a sweat regularly.

Resources

If you're in need of more serious help, you aren’t alone, and there are many resources available. And while I'm not a professional and can't vouch for the efficacy of any of these sources, they should be a good place to start.

U.S.-Based

The National Alliance on Mental Illness has a free helpline where you can get advice and get pointed towards the resources you need.
If you’re having thoughts of self-harming of thoughts of suicide, you are not alone. The National Suicide Prevention Lifeline can offer confidential help and resources.
The SAMHSA Disaster Distress Hotline provides 24/7, 365-day-a-year crisis counseling and support to people experiencing emotional distress related to natural or human-caused disasters.
Here’s a list of resources and helplines you can call to get help from a variety of organizations.

International

Checkpoint has a long list of international websites and hotlines you can contact for a wide variety of needs.
TherapyRoute has lists for suicide and crisis helplines from around the world.

If you enjoyed this...

Read more of my articles here
Check out larger projects I’ve done in my portfolio
Catch up with me on Twitter and LinkedIn

Keeping Git Commit Messages Consistent with a Custom Template

Timothy Merritt — Sun, 10 Jan 2021 17:38:33 +0000

xkcd on git commit messages

The ability to write consistent git commit messages is a skill that will serve both you and any team you’re working with well in the long run. If you often find yourself struggling to come up with a decent message format, or you’re unable to decipher what it was you were doing when looking back through old commits, this little fix might help. And the best part is it’s extremely easy to implement.

You can set a file to act as a commit message template through git’s global configuration. I tend to follow the conventional commits format, which makes it easy to decide how to format your messages, and keeps things organized across all your commits. Chris Beams also has a great article on this topic.

First, create a .txt file in a directory of your choice that will act as the template. I’ll assume you’re using the terminal for the process.

touch commit-conventions.txt

Open the .txt file with the editor of your choice. Git will ignore lines that begin with a # or ; by default, so we’ll use those to make a template of ignored lines that only you will see when you’re making commits.

Note: By default, git allows both # and ; as comment characters for configuration files, but you can set a character of your choice with git config --global core.commentChar '#', substituting # with your preferred character.

You can put whatever you want in your template, but here’s mine as an example:

# ----------------------------------------------------------
# Header - type(scope): Brief description
# ----------------------------------------------------------
#    * feat             A new feature - SemVar PATCH
#    * fix              A bug fix - SemVar MINOR
#    * BREAKING CHANGE  Breaking API change - SemVar MAJOR
#    * docs             Change to documentation only
#    * style            Change to style (whitespace, etc.)
#    * refactor         Change not related to a bug or feat
#    * perf             Change that affects performance
#    * test             Change that adds/modifies tests
#    * build            Change to build system
#    * ci               Change to CI pipeline/workflow
#    * chore            General tooling/config/min refactor
# ----------------------------------------------------------


# ----------------------------------------------------------
# Body - More description, if necessary
# ----------------------------------------------------------
#    * Motivation behind changes, more detail into how
#      functionality might be affected, etc.
# ----------------------------------------------------------


# ----------------------------------------------------------
# Footer - Associated issues, PRs, etc.
# ----------------------------------------------------------
#    * Ex: Resolves Issue #207, see PR #15, etc.
# ----------------------------------------------------------

To add the template to your global git config is enter the following:

git config --global commit.template path/to/your/file.txt

Now whenever you’re making a commit, instead of the typical git commit -m "A brief commit message", just enter git commit to open your default editor with the template in place. You’ll automatically have a guide to choose conventions from to create a structured message. For example:

# ----------------------------------------------------------
# Header - type(scope): Brief description
# ----------------------------------------------------------
#    * feat             A new feature - SemVar PATCH
#    * fix              A bug fix - SemVar MINOR
#    * BREAKING CHANGE  Breaking API change - SemVar MAJOR
#    * docs             Change to documentation only
#    * style            Change to style (whitespace, etc.)
#    * refactor         Change not related to a bug or feat
#    * perf             Change that affects performance
#    * test             Change that adds/modifies tests
#    * build            Change to build system
#    * ci               Change to CI pipeline/workflow
#    * chore            General tooling/config/min refactor
# ----------------------------------------------------------
docs: Update README with contributing instructions

# ----------------------------------------------------------
# Body - More detailed description, if necessary
# ----------------------------------------------------------
#   * Motivation behind changes, more detail into how 
# functionality might be affected, etc.
# ----------------------------------------------------------
Adds a CONTRIBUTING.md with PR best practices, code style 
guide, and code of conduct for contributors.

# ----------------------------------------------------------
# Footer - Associated issues, PRs, etc.
# ----------------------------------------------------------
#   * Ex: Resolves Issue #207, see PR #15, etc.
# ----------------------------------------------------------
Closes #9

The “header” of the commit message notes the type of the commit as docs and a brief description that does not exceed 60 characters to ensure readability (the commented lines are 60 characters long and act as guides for when to use a line break). The “body” optionally elaborates on the changes made, and the “footer” optionally notes any issue/PR the commit is related to. The final message will simply look like this:

docs: Update README with contributing instructions

Adds a CONTRIBUTING.md with PR best practices, code style 
guide, and code of conduct for contributors.

Closes #9

For more specifics on the convention formatting or how it works with semantic versioning, see my git configuration. If it's too confusing or overly complex for your use cases, just simplify as needed.

If you use Vim or Neovim, and you want to speed up the process even more, you can add this to your git config:

# Neovim
git config --global core.editor=nvim +16 -c 'startinsert'

# Vim
git config --global core.editor "vim +16 +startinsert"

This sets the default editor to Neovim (or Vim), and places the cursor on line 16 in Insert Mode as soon the editor opens. Now whenever you’re committing, when you type git commit, Neovim opens the template, places your cursor, and accepts typing input immediately. Also note that you can still use git commit -m "Your message" exactly as you did before, but the configuration will default to the template setup when you just type git commit.

See more tips for configuring your editor with git here

Setting up this template has saved me countless time and frustration, and makes it so much easier to track my commits since all my repos use the same global commit format. You can get much more creative with git defaults and complex githooks, but this is a great way to solve a common problem for most developers.

If you enjoyed this...

☕ Buy me a coffee to fuel my work
See more of my configurations in my dotfiles
Check out larger projects I’ve done in my portfolio
Catch up with me on Twitter and LinkedIn.

Consider contributing to Compuneers, a site highlighting unsung women, BIPOC, and LGBT+ pioneers in Computer Science

Timothy Merritt — Wed, 21 Oct 2020 00:02:14 +0000

If you’re still working on getting your 4 PRs for Hacktoberfest, consider contributing to Compuneers, a site highlighting important women, BIPOC, and/or LGBT+ figures often overlooked in the history of Computer Science. Most people don’t know the stories of Grace Hopper, the ENIAC programmers, Lynn Conway, and so many other fascinating people who helped create the modern computing industry, and I hope this site goes a small step towards shedding light on who they were and are.

This is a project I’ve been wanting to start for a while now, with an emphasis on opportunities for collaboration. Right now it’s a simple Jekyll blog-style site, with a good amount of issues to tackle, and the option to submit issues for adding new figures from history to the site. It won’t take a lot of technical know how right now, since the focus is on publishing posts with as many important figures as possible to create a rich amount of content. Eventually, if people are interested enough, I’d like to move it to React, but for now this will do the job.

The whole point of the project is inclusion, so if you aren’t very experienced in web development yet and want to start contributing to open source, this should be a good beginner project to help out with. Likewise, if you’re passionate about bringing the stories of these often overlooked people to light, whatever your skill level, please consider contributing.

You can find instructions on how to contribute here or check out currently open issues if you’re interested. Thanks for reading!

You can find me on Twitter, check out my projects on GitHub, or view my portfolio for more info about me.

My First npm Package - A Custom React Theme

Timothy Merritt — Wed, 14 Oct 2020 22:50:52 +0000

After being sick and tired of constantly having to delete and rearrange the create-react-app boilerplate, I finally made a custom stripped-down React template for starting new projects. So far it doesn’t include anything extraordinary (though I did incorporate my SCSS boilerplate called SPLATE), but it removes all of the extraneous defaults for new React apps. I also managed to setup GitHub Actions to automatically release new versions to the npm registry when I update the main branch.

If you’d like to try it out, you can use it via npx create-react-app [name-of-your-app] --template timmybytes-template. I’ll be adding more helpful starting features, and more automation for deployment.

#discuss What’s your preferred build process for a project?

Timothy Merritt — Fri, 09 Oct 2020 15:48:17 +0000

Do you use Webpack, npm scripts, etc.? What’s your preferred method for getting a distributable package? And what tips do you have for the process?

What I Learned From 100 Days of Code

Timothy Merritt — Wed, 07 Oct 2020 19:14:37 +0000

Yesterday was day 100 of my personal 100DaysOfCode challenge. Before beginning, I already had some experience with HTML/CSS, Python, and the command line, but my comprehension was limited and mostly fragmentary. Over these last few months, however, I’ve completely thrown myself into learning to code, web development best practices, and computer science theory (in a limited fashion). Here are some tips I’ve picked up along the way.

Feeling like an imposter can be a good thing

One of the most common aspects of being a newbie to coding and development is the dreaded “Imposter Syndrome”: the feeling of being a fraud when you don’t know as much as you think you should, or when you’re just sort of faking it until you make it. This mindset is particularly applicable to people who’ve just landed their first developer job (or even long after), and while it can be stressful and depressing to compare yourself to seasoned savants, there’s a simple solution—don’t.

If you’re new, you’re new. There’s nothing wrong with that. Not everyone learns to write DRY code before they’re out of diapers, and whatever path led you to coding at whatever age is a valid one. I’ve spent years working in retail, have an unrelated degree in English, and one of the things I’ve learned to embrace over this period diving into programming has been my lack of knowledge.

When you don’t know how a particular piece of code works, or what a tool does, or why a technology exists, it gives you the opportunity to find out. Computer Science is so dense with history and evolution that no one person can know it all, but learning to embrace going down wormholes to clear up gaps in your knowledge is a useful skill, and along the way you’ll find another dozen topics you’ll want to look into later for even more clarification. Part of learning to code is learning how to learn, and being okay with the fact that there’s always more to find out.

Resources

Stick with a central programming language

You might feel inclined to try and cram as much into your brain as possible when starting out, and desire to learn how every popular programming language works. This is a recipe for remaining confused and staying stuck at the beginner level indefinitely. Instead, focus on one language.

For me, I’ve pursued front-end web development, so after getting the hang of HTML and CSS (which aren’t really programming languages at all), I’ve focused solely on JavaScript. As a result, I’ve deepened my knowledge of the language rather than spreading myself thin over many others, and this applies to any other language you’re interested in.

There isn’t a “right” language to learn first, though some may be better suited for you if you’re looking to work with certain realms of development or engineering. JavaScript is tailored to web development, Python is often the choice for machine learning, Java is popular for enterprise software, etc. There are exceptions to all of these, but the gist is that once you start with a language, stick with it.

A language’s syntax is something you can pick up pretty quickly, or look up once you know what you need, but the important thing is to learn the concepts of programming and /thinking/ programmatically. Once you’ve become adept at one language, it becomes easier to learn another because the same underlying concepts will usually apply.

Resources

Track your progress

Publicly committing to the #100DaysOfCode challenge gave me some accountability for reporting what I’d done each day on Twitter, and eventually I started using tools like Toggl Track and Wakatime to record the time I was studying and actually working on things. Gamifying your progress can be a great incentive to keep trying to up your own “scores”, but more than anything it gives you tangible evidence that you’re really taking ownership over your own learning. Seeing weekly reports of the hours you’ve put in can give you that added boost of knowing you’re accomplishing something incrementally, especially if it feels like you’re just spinning your wheels in the moment.

Similarly, take notes! When you’re watching a tutorial or researching a topic that’s unfamiliar to you, it’s immensely helpful to write down contexts for why something is the way it is, preferably with examples you can refer back to later. I personally recommend using Bear (it’s what I’m using to write this article), a free, full-featured note app that supports markdown and syntax highlighting.

Resources

Be kind to yourself when you need a break

Just as tracking your time can make you strive for more time spent working, it’s also important to step /away/ from the keyboard. You can’t learn everything there is to know about programming by staring at code for twelve hours a day, and more often than not life will throw you curveballs that will force you to take a break (and 2020 is the year of curveballs, if nothing else). Burnout is a very real issue for developers, so try to establish good habits from the get go by giving yourself time away from the keyboard.

For me personally, that has meant juggling chronic migraines, raising my son, air toxicity (I live in Oregon, where we spent two weeks under a blanket of dangerous wildfire smoke), and any number of things on a daily basis that could either distract or derail my focus on coding. There’s always more I want to be doing, always more I wish I was learning, but I’ve learned to be patient and appreciate that even if the pace isn’t always as consistent as I’d like, I’m still moving forward bit by bit.

Resources

Push out of your comfort zone

When you finally get the hang of a concept, a framework, a tool, etc., it can be easy to fall into the habit of continuing to revisit an area where you feel comfortable—and avoid things that you grapple with. This was me with JavaScript, which was extremely intimidating to me at first, and as a result I kept putting off diving into it.

But most of the time, doing the thing that seems scary ends up being much less frightening than you thought initially, and it makes you get comfortable with the knowledge that a) you have a lot to learn, and b) you /can/ learn a lot. I spend some part of every day with JavaScript now, and I’ve come to really love it’s quirky personality and the staggering capabilities it has. I’ve gotten so used to trying things I don’t understand, at this point I’ve started making notes and bookmarks of complex topics to come back to or work towards.

Use your momentum as a spring board

Learning to code is a daunting undertaking. There’s more to learn than any one person can cover in a lifetime, and things are changing all the time. It’s easy to get overwhelmed and feel like you aren’t getting anywhere, and an important component to the process is to keep pushing yourself forward. One of the best ways you can do this is to learn in public (by sharing your journey through #100DaysOfCode on Twitter, for example), and more directly, to engage with the developer community at large.

As someone who deleted most social media accounts years ago, it can often be a hurdle for me to go from passively reading posts and following interesting people online to actively engaging with them, but I’m trying to get better about it (see the current article you’re reading...).

More than anything though, if you reach Day 100 of your own challenge, keep going. Keep learning, keep coding. Build projects, connect with others online to learn from and share with. Do a second round of the challenge, or create one for yourself.

I for one plan to keep coding everyday without exception, and am currently trying to land a job in the industry as a developer. I’ve realized the passion I have for this stuff seems to know no bounds, and completing 100DaysOfCode has only seemed to increase my appetite to learn and do more. If you’re just starting your journey, overwhelmed by all there is to learn and know, don’t worry. You’ve got this, and there are many of us here eager to support you along the way.

Beginning JavaScript - Variables and Primitive Data Types

Timothy Merritt — Sat, 12 Sep 2020 15:12:57 +0000

Note: These are some beginner JavaScript concepts explained with as little jargon or complexity as possible. However, this is not an all-encompassing guide (yet), I am not a coding genius, and exceptions exist for some of these examples. The point here is just to get used to some core ideas of programming in JavaScript.

As of a 2018 StackOverflow survey, JavaScript is the most popular and widely used programming language today. If you're learning front-end web development, it's an essential skill alongside HTML and CSS, and while at first glance it might seem like JavaScript is just for flashy menu animations, it's a powerful programming language in its own right, and learning how to use it properly will not only help you build better projects, but also teach you more about how the Web works and how your work can best integrate with it.

JavaScript is governed by the ECMAScript standard (if you ever see acronyms like ES6,ES2015, etc., this is what they're referring to), specifications that ensure its cross-compatibility between browsers and platforms, and integrate new features as JavaScript grows and evolves.

When you’re just starting out with JavaScript, it’s important to focus on the basics. In any programming language, code defines a set of instructions with data. The format that data takes is called a data type and the way those types work together is a data structure.

As of ECMAScript 2020, JavaScript has seven main—or primitive—data types, five of which we’ll focus on here:

Undefined type
Null type
Boolean type
Number type
String type

There’s also BigInt and Symbol, which are a bit out of the range of what you need to know as a beginner. If you’d like to read more about them, the Mozilla Developer docs have some great info on both Symbols and BigInts, but for now, let's focus on the others and the way in which values are stored and reused in JavaScript.

Data Types and Variables

Data types can be assigned to variables for ease of repeated use, and variables are simply symbolic names that represent a value (the data type itself). In JavaScript, variables can be declared in three ways that affect how they can behave: var,let, and const.

var someVariableName = "a value";

let aDifferentVariableName = "a different value";

const anotherVariableName = "a different value";

Three variables with separate values.

Depending on what declaration statement is used to declare a variable, it can be confined to different parts of the code, unable to be used elsewhere. This is called scope, and it affects where a variable is valid in a program.

In the first example, someVariableName is, you guessed it, the name of the variable, and a value is the value of that variable. So if we were to use someVariableName somewhere in our code after declaring it (and it fell within a valid scope of use), the code would know we mean a value when we use that variable again.

Primitives are the most basic types of values a variable can hold. Because JavaScript is a dynamically-typed language, variables aren’t explicitly associated with a particular data type, and can be assigned and reassigned values of all types—the variable name is just symbolic. What matters is the data type stored in the variable.

const someVariableName = "a value";

someVariableName = "a different value";

Here someVariableName's value of "a value" is replaced when the variable is reassigned "a different value".

Okay, this can get complex quick, but for now, let’s look at the most common kinds of primitive data types in JavaScript as assigned to simple variables.

Undefined and Null

Undefined data types are those that don’t have anything assigned to them yet. Imagine you’ve got a factory you’re starting, but you haven’t decided just what your factory is going to make. The products of the factory are undefined: you haven’t decided on their specifics yet, you just know they’re going to be something.

const factoryProduct

The variable factoryProduct is declared, but not defined with a value, thus it is undefined.

JavaScript automatically assigns this designation of undefined if you haven’t explicitly declared what data type you’re using. As soon as you say your factory makes something specific, like pots or pencils, you define the products, and they are no longer undefined.

const factoryProduct = "pencil";

The value of factoryProduct is no longer an undefined type, and is now a string type.

Undefined data types can be useful as a placeholder to come back to later in the program, if the value is going to be dependent on other factors. An undefined value is one that doesn’t exist yet.

Null, on the other hand, is a value (sort of), but it’s an empty one. A variable with a value of null is intentionally devoid of value... and that is its value. Does your head hurt yet? Welcome to programming.

A factory variable with an undefined value is a factory that doesn’t know (or hasn’t been told) what it’s going to make yet. It might be pencils or candy bars or inflatable unicorn horns for cats. A factory with a value of null, on the other hand, is one whose interior is a vacuum of nothingness as empty as the void.

Great! Let’s continue.

Boolean

This can be a scary word when you first start out, but Booleans are extremely simple: they’re either true or false. That’s it. Your factory product either is a pencil, or it isn’t.

const pencil = true;

const pot = false;

There's no philosophical debating in programming. The pencil is true and the pot is false.

Booleans (named after mathematician George Boole) can be really handy for checking for values or conditions in your code, and are often used as a kind of switch in the flow of a program. If something is true, do this; if it’s false, do something else. This can allow for dynamic operations to trigger in your code depending on if certain conditions are met:

if (factoryOpen === true) {
    makePencils();
} else if (factoryOpen === false) {
    doNotMakePencils();
}

Booleans help the logic of your code flow towards a desired outcome.

See the ===? That’s called an equality operator. It’s checking that the factoryOpen variable is true in the Boolean sense of the value, instead of maybe just representing the word true. More on those pesky equals signs later.

Number

A number primitive is just what you think: a number! In other programming languages, there are often specific data types for different kinds of numbers with decimals, whole numbers, etc., but good old JavaScript keeps things simple by just calling most of them numbers. As mentioned earlier, there is a BigInt data type for exceptionally large numbers, but we don't need to cover those yet.

const numberOfPencils = 382;

String

In JavaScript, as well as many other languages, a string represents textual data as a sequence of characters surrounded by double or single quotes (either kind work, as the quotes aren't part of the actual stored value). Strings can include numbers or letters, but their value is read literally as textual data, not as numeric data. Hence why these strings are called string literals.

const factoryProducts = "pencils";

const factoryEmployee = "Jay 8374-D7";

In the second example, Jay 8374-D7 has

A string can be as small as a single character, or encompass longer text. For text that spans multiple lines, adding a backslash to the end of the line break allows for more text to be stored in the variable.

const factoryMotto = "Make the best pencils /
we can make, from the best materials /
available."

Splitting a string into multiple lines can help with readability for anyone who might need to work on your code (including you!).

Since strings are immutable, like all other JavaScript data types, they can be reassigned after getting their initial value. Think of this as if you’re wearing a name tag written in permanent marker. Once you’ve written your name on your tag, you can’t try to squeeze new letters or words in. You can, however, replace the name tag with a new one that includes your changes.

const nametag = “Alicia”;

nametag = “Tony”;

Strings can’t be changed, but they can be reassigned to a different value.

This works with other data types as well.

const nametag = “Alicia”;

nametag = true;

nametag = 845;

Summing Up

The values you use in JavaScript are data types, the most basic of which are called primitive data types: Boolean, Number, String, Undefined, and Null. Other common data types include arrays, functions, and objects, but we'll cover those in the next article, where we'll also talk more about how data types can be assigned and compared, and start manipulating our values in interesting ways. Happy coding!