DEV Community: Devon Campbell

Make your users happy by keeping it RYL in documentation

Devon Campbell — Fri, 04 Aug 2023 20:17:39 +0000

One of the first principles you learn as a developer is DRY: don't repeat yourself. In some cases, DRY should be ignored — like to avoid over-abstraction or tight coupling, and when it might have a problematic impact on performance — but, in most cases, it's a principle that serves developers well. It makes code easier to maintain, easier to test, and less buggy (since there's just less of it in general).

Many of us find ourselves at some point writing documentation for the software we've built. DRY is so useful when writing software that we want to bring it over with us and use it when we write our documentation too. It can have benefits in documentation… but it can also do more harm than good. Let's look at some examples from the EdgeDB documentation to show when DRY works and when it doesn't.

The most repeated piece of EdgeDB documentation

This is the most foundational thing we document… and it's, by no coincidence, the most repeated bit of documentation on our entire site. If we don't tell you how to install EdgeDB, there's not really much point in telling you anything else. 😅

We have at least four instances of the installation instructions:

Installation instructions on the EdgeDB home page

Installation instructions on the EdgeDB quickstart

Installation instructions in the EdgeDB CLI documentation

Installation instructions in the EdgeDB Next.js blog tutorial

Messy, right? Now, if the command for installing EdgeDB changes, we have to change it in four different places — and that's the best case scenario. What happens if the person updating it doesn't know to look for these additional instances? Then, three instances don't get updated and end up leading someone in the wrong direction.

This is exactly the reason we use DRY when writing software. So, why wouldn't we also apply it when writing documentation? The DRY approach would be to pick a single location to house the canonical installation instructions and then to link back to it from anywhere else we need to tell someone how to install. Why make life hard on those of us writing and maintaining documentation?

Only because the alternative is worse.

The cost of DRY documentation

It's not that there's never a cost associated with keeping code DRY. There is. It can mean code is spread across more files and that things are a bit harder to work with. The nice thing though is that, usually when you're re-using code, you by necessity leave a breadcrumb trail that leads to the one canonical source of the code in question. Most of the time, those pains a small price to pay for the gains.

But the critical point is who pays the cost of DRY code: your developers. Maybe they have to search around a little to find the function they need to refactor… but that is the job. It's just part of what we do as developers.

When we use DRY in documentation though by insisting every atom of documentation is located in one and only one place, the largest cost is paid by our users when they try to use the documentation. Take our Next.js blog tutorial shown in one of the examples above. Imagine that it instead linked out of the tutorial to the "Install" page for installation instructions. Now, instead of the tutorial being a one-stop shop for pretty much everything you need to build the app, the user has to jump out to another page, perform that step, and then come back.

OK, now I can hear you across time and space saying: "Big deal! It's one click and a few seconds on a different page." This is true, but the problem is that the Next.js blog tutorial aggregates all sorts of information from all across the documentation and even from documentation for other non-EdgeDB projects. To avoid repeating ourselves — or repeating anyone — we would have links out to:

Next.js documentation
our CLI documentation
our schema quickstart
our migration quickstart
our JavaScript client documentation
our page on the JavaScript query builder
Vercel documentation
and probably a few others I've missed

The Next.js tutorial would no longer be a tutorial, and instead it would become just an aggregation of links. Instead of one click and a few seconds to figure out how to install, the tutorial now requires globetrotting all across the internet just to build a simple project. This creates a subtle shift in what this piece of documentation is: it's no longer teaching users to build a Next.js blog; it's teaching users to learn to build a Next.js blog. The burden of the actual "teaching" though now falls to them.

Now take that friction and multiply it by every instance of repeated documentation across our docs. You can see how the constant added friction would make learning and using EdgeDB incredibly frustrating.

Wait, what's that? It's another whisper across the void. I hear you saying, "but if DRY is good enough for developers and we're documenting a project targeted at developers, then DRY documentation should be good enough for them." The key difference is DRY code forces developers we employ to do a little more work whereas DRY documentation forces our users or maybe customers, who granted might also happen to be developers, to do more work. Do we really want to start that relationship by making their lives harder? (Spoiler: the answer is "no, we don't." 😜)

Many users will check out. They just won't do it, and I can't blame them. I wouldn't do it either if I were in their shoes! It's not that they don't want to learn. It's that there's someone out there writing documentation that will make their heart smile by not forcing them do so much work. It's easier and smarter to jump ship instead of jumping through the hoops we erected to make life easier on us.

In software, DRY is transparent to your user. To them, your app would work the same if you rewrote the same function 14 times for the 14 different contexts you call it in or if you wrote it once and calling it in those 14 contexts. But in documentation, DRY changes the user experience, often for the worse.

Instead, we want to use a principle I'm calling RYL: repeat yourself liberally. (Not only does this accurately describe the concept, but it also allows me to giggle to myself as I use it to riff on a slang idiom with "keeping it RYL." 😁)

The "liberally" part does some heavy lifting here. I don't mean to imply you should repeat everything all the time. Let's look at why.

When DRY works for documentation

DRY is bad for documentation, so maybe you should ARY (always repeat yourself), right? Well, no, that's not really the best solution either. As with so many questions in software development, the answer to the question, "Should I reproduce an existing piece of documentation in this other context where it might be needed?" is the dreaded "it depends."

If we skip down near the end of the Next.js tutorial, we'll find a section on deploying the app. The first step in deploying is to deploy an EdgeDB instance.

Readers have as many ways to do this as there are cloud providers, and we have instructions for many of them. Each of these deployment guides is fairly extensive which means including even one of them would have a massive impact on the tutorial's word count. A user will probably have a strong preference for one deployment method over the others — maybe they already have some infrastructure on Google Cloud, or maybe they're familiar with AWS because they used it at a previous job — and only need to deploy to one target, so seeing all of the deployment guides inline in this tutorial will almost never be useful.

☁️ The easiest way to deploy EdgeDB is now in beta: EdgeDB Cloud! Sign up to try it for yourself.

Repeating the deployment guides here also doesn't work because it will create a ton of noise in the guide, and there's nothing particular to this tutorial about setting up the EdgeDB instance. You simply set up an instance. Then, the Next.js guide takes over again when it's time to connect that instance with your app. Repeating this mountain of deployment information within the tutorial would make it harder to use.

Maybe at this point, you find yourself convinced that RYL is a useful principle when applied to tutorials which naturally aggregate information from different sources. Can RYL still be useful in other kinds of documentation where aggregation isn't their primary purpose?

Being RYL outside of tutorials

In addition to giving the basic information about how features work, documentation needs to tell users about behavior that may not be intuitive or that they might not expect. This kind of information is a great candidate for RYL. My philosophy is this: if the behavior is likely to cause a user frustration when they're using EdgeDB, make the warning about it easy to trip over in the documentation. Here's an example where we describe how to specify your server version for EdgeDB.

edgedb instance create

edgedb project init

edgedb.toml

There is no "right" way to specify a dependency version. People have different expectations about how it should work. This means that, if you build a way to specify a version that is intuitive for one group, it will surprise another. Even though the way we do it will be surprising for some, it isn't "broken" and as a result, it can't be "fixed." What we can do is to document it properly and put that documentation where users can find it.

You can specify your version when you create an instance or when you initialize a project. Maybe you want to hand-write an edgedb.toml file and bring up a project from it. All three are perfectly valid. It would be silly to try link users from the edgedb.toml documentation across to the edgedb instance create documentation for information on how version specification works, especially since we're just talking about repeating a paragraph or two of text. As part of maintaining our documentation, we will take on the burden of maintaining this information in multiple places to take the burden of finding the information or having to bounce all over our documentation off our users. By using RYL, we can ensure our users will have the information they need no matter what circumstances they find themselves in.

One other nice thing about repeating this is that we can change up the text to fit the context. The first two examples are nearly identical, except that the command examples are changed to reflect the command we're talking about. Could someone figure this out on their own? Yeah, probably, but why would we make them?

Sometimes, DRY works tutorials better in non-tutorial docs too

Being DRY in other documentation is also useful. A great example is our CLI's connection flags. Most of the CLI's commands need to connect to an EdgeDB instance in order to be useful, and we provide many different options to make that easy for you. The current count is 13 different connection flags. They work the same way across all commands, and the documentation on them is not trivial.

Here's a case where duplicating this information across a couple dozen documentation pages doesn't make sense and linking to it is the better choice. It's just too much, and the usage doesn't change across the various commands.

Keep it RYL… when that makes sense

In plenty of cases, keeping documentation DRY makes sense, but not always. DRY is less useful in documentation than it is in code because of the burden DRY documentation shifts to your users.

Add RYL to the equation when you're thinking about how best to support your users with documentation. When you should and shouldn't use it is more art than science. It'll be up to you to define where that balance lies for your project, but you want to use every tool you can find to make sure your users can be successful. RYL is often the right tool for documentation, to make sure your users find exactly what they need when they need it.

Confessions of a 0.8x Developer 😅

Devon Campbell — Tue, 06 Jul 2021 02:07:43 +0000

This may be career suicide… but I feel like a lot of people probably need to see it.

I have a confession to make. I’m not a very good developer.

Maybe that’s a little unfair to myself. Actually, I think I am a good developer, but not because I’m especially clever or fast at building software.

There’s nothing left to be said about the legendary 10x developer, particularly about whether or not such a beast exists. I won’t weigh in on that. In the event you aren’t familiar with the concept, though, I’ll just briefly define it. A 10x developer is a developer who is 10x faster, 10x smarter, or generally 10x better than the typical developer.

Even though I can’t say whether the 10x developer exists, what I can say that is that I am not one of them. I’m more like a 0.8x developer. Here’s why.

I don’t write especially clever code. If I’m feeling my oats and want to humble myself, I’ll head over to CodeWars to do a few challenges. Once I find a working solution, I like to browse the top voted solutions. When my solution is 16 lines, the best solution is often a one-liner. I tend to brute force everything. I write code in the way that makes sense to me. I can get it done, but do I get it done the best way? Usually not.

I’m slow. You may already know that I organize a meetup group for new and aspiring devs here in Seattle. Sometimes, we have events where we code together in small teams, each team having an opportunity to present and talk about what they’ve built. I’m frequently amazed at what people have been able to build. These are people without jobs who are able to build far more in 2-3 hours than I could, even though I’ve had years of experience.

I’m not much of a computer scientist. This isn’t a huge deal because I’m not doing computer science most of the time. The only problem is that every developer interview tests you on computer science – implement a linked list, perform a bubble sort, or write a recursive algorithm.

You may be reading this and thinking, “These don’t describe me. I’m way better than Devon.” If so, that’s awesome. I’m sure you’ll find a ton of success. I’m happy to help you move forward into your career however I can, but I didn’t write this for you. I wrote this for the person reading and saying, “Me too.” I’m writing to let you know that none of these shortcomings mean you can’t have a great career as a web developer.

Now, we’re flipping to the other side of the coin. These are the things I do well.

I write maintainable code. One reason my code is generally more verbose than the top solution on CodeWars is that I’ve trained myself to write my code to be read by other developers. This is a skill I have honed for mostly self-serving reasons, those being that I can’t understand clever code and write so that later I can read and understand the code. This has the nice side effect that, if I can understand the code, most anyone can.

I am reliable. I underpromise and over-deliver. If I say I will be at a meeting, I will be there. I will not tell you that your final delivered software will be 100% bug-free and secure because no software ever is. I will not tell you I will ship a feature next Tuesday unless I’m pretty damn sure I can make that happen.

I communicate well. You know that feature I was pretty damn sure I would ship next Tuesday? I now suspect I’m not going to hit the deadline because of a number of factors, and I’m currently writing my client an email detailing all of those and asking how we should proceed. That’s because this is their business. Even reliable people miss deadlines, but reliable people also have empathy for the people they work for and give them as much time as possible to prepare for those deadlines to be missed.

I care about what happens around the code. I can’t count the number of people I’ve heard say, “I just want to be left alone to write code,” when confronted with meetings, estimating timelines, or other realities of running a business. I totally understand that impulse, and you can have that… if you just want web development to be a hobby. If you want to get a paycheck, there’s a business making the money to back that paycheck, and you should probably care about its continued success.

Now, I’m a capable person. If I wanted to, I could probably make an effort to develop those skills I don’t have. I could write more clever code and write solutions that rank near the top of CodeWars. I could develop techniques to code faster. I could sit down and really learn computer science. I’d guess most people could if they really put in the effort.

But the things I do well are things that almost anyone can do well if they make the effort and summon the empathy to care about factors orbiting around their work. These are skills that are incredibly valuable to businesses. I don’t know this for a fact, but I’m pretty sure these are the reasons people want to work with me. They don’t go on a resume, but they’re factors people pick up on when they work with you, which is why I advocate so strongly for starting with freelancing in your career. Showing is more powerful than telling. You can use freelance work to show people you have the qualities they want in a partner… or maybe an employee someday, if that’s what you want and what they need.

As I’m reading back through this, doing some editing, it occurs to me that maybe my premise was wrong to begin with. Maybe I am a 10x developer, just not measured by the metrics that are generally used to identify those. Or maybe I’m just a 1x developer… but that’s still better than 0.8x! The skills I do have allowed me to build a career that’s ~8 years strong at this point. Even though I’m not as fast nor smart as many web developers, it seems like some people, at least, have decided I’m good enough for them.

The post Confessions of a 0.8x Developer first appeared on Rad Devon.

Use DuckDuckGo to find answers as a developer

Devon Campbell — Sat, 08 May 2021 14:58:15 +0000

I pride myself on teaching the developer skills that not many people focus on – dealing with rejection, understanding business, finding work… those kinds of things. Here’s a skill that I use every day but hadn’t even considered talking about: searching.

It occurred to me when I found an article by Marko Denic on how to use Google’s search syntax. I highly recommend you check it out. It’s a quick read, and, even though I’m searching all day every day, I picked up a few new tips.

The one thing I don’t care for about the article is that it’s very Google-centric. We’re well past the “don’t be evil” Google of the past and into the “maneuver around the law and common decency in an effort to collect the most possible data on our users” era of the company. It’s why I switched over to a privacy-focused search engine called DuckDuckGo.

I’m going to be up-front with you. The results on DDG are not always on par with those on Google, and I do still use Google when I need to. What I find, though, is that for 90% of the searches I need to do, DuckDuckGo works just as well and sometimes better.

Google is much better at finding results in online discussion which is very useful when you’re trying to find the answer to a specific question. Google will return multiple results from StackOverflow, Reddit, and support forums. DuckDuckGo has these, but it seems to find fewer of them and it doesn’t always surface the relevant ones.

Here’s my simple search workflow:

Try my search on DuckDuckGo.
In the event I don’t find what I’m looking for, I add !g to my search to search on Google.

This uses a DDG feature called “bangs” that allow you to send your search over to another site. Adding !g just sends your same search over to Google. You’ll get back the Google results for your search terms (on Google; they’re not proxied through DDG, so it’s literally identical to searching on Google).

This always feels like giving up (and frankly, it is), but the bangs feature goes beyond just redirecting failed searches over to Google. DDG has thousands of bangs, and many of them are super useful for developers. Here are a few you might find useful:

!mdn- Mozilla Developer Network
!sof- StackOverflow
!csst- CSS-Tricks
!r- Reddit
!dev.to

These are just the ones I think are most generally useful to developers, but there are tons of these things. You have language-specific bangs like !py for searching the Pyton documentation, front-end framework specific bangs like !vue for the Vue documentation, and tool-specific bangs like !vscode to search the Visual Studio Code docs. I could go on, but instead you should check out DDG’s bangs page and find the bangs that will help you code faster.

You could still use site:mdn.org for example to search just on the MDN site, but this works differently from a bang. The bang searches through the site’s own search engine. Limiting your DDG search to a site using site: still uses DDG’s search and not the site’s own search. Either approach might be useful depending on the context.

You might be wondering, “Why wouldn’t I just go directly to the site I want to search and search there instead of going to DDG and using a bang to redirect my search to the other site?” I’d reply, “That’s an astute observation, intelligent reader,” and proceed to address it like so: bangs shine when DDG is your browser’s primary search engine. If you decide to set DuckDuckGo as your browser’s search engine, you can now search directly from the address bar, giving your address bar some cool superpowers.

You can now type your search in the address bar to search DuckDuckGo, or you can type your search and add “!g” to search Google (e.g. flexbox !g). Maybe that leads you to a StackOverflow article with a recommendation for a book on CSS. Awesome! Now, you hit command/control-L to focus the address bar again and type !a flexbox in css to find the book on Amazon. (Note that your bang can go anywhere in the search. It doesn’t have to be at the end.) Then, you order the book and search !mdn flexbox to find a quick reference on MDN while you wait for your book to ship. That’s the true power of the bang.

In case you’re wondering about the search tips in the Marko Denic article, most of them work in DuckDuckGo.

Quotes work the same way.
The AND and OR keywords don’t exist in DDG, but search terms are implicitly ORed.
The minus (-) operator is slightly different in DDG. Where Google eliminates results with the term, DDG gives the term specified by the operator less weight. It’s not as useful, but it can still get the job done.
Wildcards don’t seem to work in DDG, best I can tell.
Limiting search to a site with site: or to a file type with filetype: works exactly the same.
Numeric ranges and dates in the search don’t work, but you can date limit the search via DDG’s UI.

So, we’re close to feature parity, but not quite there. It’s going to be enough for most searches. If you absolutely need to refine a search by adding a wildcard to it, just do it and also add the !g hashbang to send that search over to Google instead.

There are two things I want you to take away from this article:

Take some time to improve your searching skills. It’s a massive part of what we do as developers and, even though it’s not tested in interviews like algorithms and data structures, it’s a skill you’ll get a lot more milage out of in the long run.
You don’t have to throw all your data into Google’s data lake in order to get great results. At the same time, you don’t have to quit Google cold turkey.

Thanks for reading. Hope this will help you find whatever it is you’re searching for!

The post Use DuckDuckGo to find answers as a developer first appeared on my site Rad Devon. Head over there for more help transitioning into your career as a web developer!

While you're there, grab a copy of my free book 5 Projects to Become Qualified as a Web Developer. I'll take you through 5 projects that will give you the basic skills you need to work as a full-stack developer. (Psst, you'll actually already be working. That's project 5!)

Learn Svelte by building a habit tracker app 🏎

Devon Campbell — Mon, 03 May 2021 00:49:55 +0000

In this video, you’ll work along with me to build a habit tracker app in Svelte. In under an hour, you’ll learn:

🔸 Components
🔸 State
🔸 Rendering arrays
🔸 How reactivity works
🔸 Props
🔸 Stores (with auto-subscription)

Go to this post's page on my site to get my free Javascript cheatsheet. It gives you practical examples of basic Javascript concepts in action. Having this handy will make learning Svelte faster and easier! 👇

The post Learn Svelte by building a habit tracker app 🏎 first appeared on my site Rad Devon. Head over there for more help transitioning into your career as a web developer!

How to build a responsive nav with no Javascript!

Devon Campbell — Tue, 09 Feb 2021 03:28:53 +0000

In this video, I’ll teach you to build fancy collapsible navigation without using any Javascript. Just HTML and CSS!

I love that we can make clever use of CSS and HTML to achieve something most people use Javascript for, but you won’t get far as a web developer without Javascript. That’s why I made a cheat sheet with practical examples to help you learn it. Head over to this post's page on my site to get your copy.

If you want to work along with the video, start from this pen. Open that and click the “Fork” button in the bottom-right so you can get your own copy to work with.

The CSS framework I used is Milligram. I like to use it because it takes just basic HTML and makes it look nice. I don’t have to sprinkle a bunch of wacky classes around to get something that looks decent.

I talk about the “+” selector and refer to it in the video as the “sibling selector.” More accurately, it’s the adjacent sibling selector. It only selects the UL if it is a sibling of the checked checkbox and also if the two are adjacent (meaning no elements between).

Hope you enjoy this tutorial! Comment here or tweet at me if you have questions.

When you get rejected as a web developer, it’s not personal

Devon Campbell — Fri, 18 Dec 2020 13:55:00 +0000

As a web developer, you’re going to get rejected a lot. You’ll end up not being able to close a freelance deal. You’ll make it to a third-round interview and end up getting passed over for someone else. Maybe it’s just a recommendation you make that the rest of your team doesn’t go for.

When you’re new, it’s hard not to take that personally. I did, and it led to a bunch of unnecessary pain and self-doubt. Here’s a pep talk that should help keep you from making the same mistake.

If you're just getting started in your career transition, please grab a copy of my free book 5 Projects to Become Qualified as a Web Developer.

The post When you get rejected as a web developer, it's not personal first appeared on my site Rad Devon. Head over there for more help transitioning into your career as a web developer!

Web Developer Gift Guide for 2020

Devon Campbell — Fri, 11 Dec 2020 13:25:51 +0000

Check out these gifts for a web developer in your life or for yourself! These will make any web developer more productive. Some of my picks will even make them safer through the magic of ergonomics!

The links to all my recommendations are below the video. 👇

Logitech MX Vertical Wireless Mouse
BRILA Wrist rest for mouse
XDesk Terra standing desk
A cheaper standing desk alternative
Topo Ergodriven standing mat
Ducky One 2 Keyboard
1Password password manager (for them)
1Password (for you)
Backblaze backup service (for them)
Backblaze (for you)
Sony wireless headphones (not the ones I have, but the ones I would get today)
Logitech C920 webcam
BZE tripod/selfie stick

Share your ideas here or in the comments on YouTube. Thanks for watching!

Validate Forms with Event-Driven Javascript

Devon Campbell — Fri, 04 Dec 2020 13:09:00 +0000

Validating form input on the front-end is a great way to make your users’ experience better. When I’m the user, I’d rather know immediately that something is wrong with my input than having to wait until I submit the form and get the results back.

In my previous video, I showed how you can access a form’s values which is one piece of the front-end form validation puzzle. This video completes the puzzle.

If you want to work along, go to this video's page on my site to get the project starter.

Before I teach you to write Javascript form validation, I’ll teach you ways to validate your form without writing custom JS. HTML5 forms have some validation capability baked right in, and using this is preferable to custom validations.

Later, we move on to a scenario where built-in validation either wouldn’t work or would be more difficult than the custom variety. We’ll start by hooking into an event. This allows us to start running some Javascript when the user interacts with our form. Then, we’ll check the user’s values to see if they are valid. If they aren’t, we’ll stop the form from submitting.

Be sure to leave a comment if you have any questions. Thanks for watching!

Working with HTML Form Fields in Javascript

Devon Campbell — Fri, 20 Nov 2020 13:57:00 +0000

You might want to go back and watch the first two videos in my DOM manipulation series if you haven’t already. This one follows from those two.

Forms and their controls have slightly different methods and properties from the other DOM elements. In this video, I show you a couple of those and demonstrate the foundational concepts of how you’d validate a user’s input.

Even now after writing Javascript almost daily for quite a few years, I still need to look things up, often just to see examples of them in use. I created this cheatsheet so you can have examples of the Javascript basics at the ready. Head over to this video's page on my site where you can get your own copy!

Moving Elements and Adding New Ones with DOM Manipulation

Devon Campbell — Fri, 13 Nov 2020 14:32:00 +0000

If you haven’t watched the first video in my series on basic DOM manipulation, you’ll want to catch up with that first.

In this video, we’ll dig a bit deeper into selecting elements. I’ll also show you how you can move your elements around in the DOM and how to create brand new elements in Javascript and render them onto your page.

If you want to learn Javascript faster, download my Javascript By Example cheatsheet. Just share your email in the form on the original article (back on my site). It’s like a regular Javascript cheatsheet but without all that “foo” and “bar” garbage.

DOM Manipulation with Plain Old Javascript

Devon Campbell — Fri, 06 Nov 2020 13:45:00 +0000

One of the most useful things you’ll be doing with Javascript is manipulating the DOM. The DOM is the document object model. It’s a model of your HTML document in Javascript that allows you to make changes to your web page as users are using your page.

DOM manipulation is what makes it possible to build web sites that work like applications. When you’re using a web site that changes in response to your inputs (clicks, keypresses, etc.) without having to reload a new page each time, that’s happening through DOM manipulation.

Front-end frameworks exist to help you build web apps that rely heavily on DOM manipulation, but they’re not necessary if you just need to do some small changes in response to a couple of different user interactions. If that describes what you’re building, do your users a favor and skip the framework. Manipulate the DOM yourself in plain old Javascript.

I’ve created a short video series to get you started. In this first video, I’ll teach you to select the element you want to interact with by querying the DOM, how to change CSS classes on an element, and how to style an element.

Check out this article back on my site to grab my Javascript By Example cheatsheet. Stop Googling every concept you need to recall in order to learn faster. This cheatsheet works as a quick reference for the basics of Javascript!

Learn Docker 🐳 for more consistent and portable dev environments!

Devon Campbell — Sat, 31 Oct 2020 13:43:32 +0000

Docker is a fantastic technology that lets you create repeatable and portable environments for development or even for production.

What does that mean? That means other developers working on the same project will be running it in the same environment as you. No more fun bugs to hunt down only to find out it’s because your colleague is running Node 8.x while you’re running 11.x.

The definitions of your Docker containers can be included in your repo to make it super easy for any new developers to bring up an identical version of the dev environment. It’s a huge boon to developers when it comes to collaboration.

In this course, I’ll teach you the basics by working through the Play with Docker classroom training together.

Quick question while you’re here: why are you learning web development? I don’t mean the surface level answers – “I want to be a web developer,” and “I want to make more money.” What’s really driving you?

If you’re not clear on that, you won’t make it very far. Read more about how this helps and take my free Big Goals course to finally break through that wall and make this change real! 💥