If You Want to Be a Digital Marketer, Learn Web Development

I ended up in marketing nearly by accident. My plan was always to be a developer—it still is—but I knew I eventually wanted to start a company, and I so I knew that I would at some point need to learn a bunch of other stuff in addition to pure programming: sales, marketing, economics, accounting, business law. So when I was offered a marketing job, despite a work history full of building websites by hand and utterly lacking in anything even containing the letters “SEO”, I took it.

This gave me an interesting background for a marketer, where though I was extremely junior, I understood all the technical jargon that made my coworkers flinch. And looking back, I think my technical background was a boon to me; so much so that I recommend taking at least one beginner web development class to anyone who wants to be a digital marketer.

Why Learn Web Dev?

Knowing web development is so useful for digital marketing because the two are hopelessly intertwined. For example, take the two most important pieces of metadata for SEOs: the meta title and description tags. Knowing where they are in the code, how they show up on the SERP, and how Google indexes them is extremely helpful to use them effectively for on-page SEO. Take another example: it’s all well and good to know by rote that appropriately sized images will make your page load faster, but if you understand the reason—that CSS takes a moment to resize the image, and if you give it an appropriately-sized image, it can prepare it faster—you’ll know exactly how to fix the problem. In general, being able to read the code when you “view source” on a webpage, along with knowing the general architecture of the internet, will help you immensely.

If you’re currently working in marketing or you’re planning to start soon, you may be thinking, “okay, in theory that sounds nice, but I’m already working so hard on marketing itself, and I don’t have time to learn to code – isn’t it super time-consuming and hard?” Fortunately for you, the answer is no, it’s not harder than any other marketing skill – if you have the right resource. And I have the right resource for you right here: HTML, CSS, and JavaScript Web Publishing by Colburn, Kyrnin, and Lemay. This book taught me a majority of what I know about HTML and CSS, which says at least something given my portfolio. It has one oddity: it doesn’t tell you how to actually host your site on the web until chapter 24. You’ll want to read that chapter very early on – probably either right before or right after chapter 1. Getting used to pushing your changes live with FTP is both easy (you can teach it to a 7-year-old) and important. Besides that little quirk, this is one of the best resources I have ever found for HTML/CSS/JS, and definitely the most useful for beginners. It even has a nice section on SEO at the end!

Learn to Use Chrome’s Developer Tools

Besides building your own websites, there is a techie tool that’s also helpful if you’re going into digital marketing: Google Chrome’s Developer Tools (or “DevTools”).

You can access the Developer Tools by clicking the three dots in the top right-hand corner of the Chrome browser, then selecting “More Tools” about 3/4 of the way down the menu, then selecting “Developer Tools” from the bottom of the next menu. The developer tools are a window that pops out from the right-hand side of the screen, and they’ll let you do all sorts of awesome stuff, including seeing in real time in a real browser what would happen if you made certain edits, without ever changing the real source code. You can do this with not only your own website, but with other peoples’ sites, even those which are way more complicated than yours. Here’s a nice tutorial to get you started with Google DevTools.

These tools are very useful for the beginner web developer or digital marketer because they’ll let you toy around with massive, complex sites without having to build those sites from the ground up yourself. I tend to just open the DevTools on random websites and play around with making changes to see what they do. It’s not a systematic process, but it’ll improve your web development skills, and it’ll also be fun. Who said work couldn’t also be play?


Do you agree that digital marketers should learn to code? Do you have more useful tools for beginner web devs (those who are or aren’t marketers by trade)? Let me know in the comments!

Speset.com: The Process

You know that thing you used to do as a kid in elementary school, where you learned handwriting by copying boring phrases and sentences over and over? That has a name. “Copywork.” And several years ago, my mother decided she wanted to make it interesting. How? Instead of those boring phrases and sentences, she would create copywork books with quotes from great fiction, literature, and even U.S. presidents.

Here’s the story of how I helped make that into a company.

Growing up homeschooled as the kid of an entrepreneur, I ended up using a lot of resources that were created by my mother. I took whole classes that my mom made up, start-to-finish. (These, of course, were in her areas of expertise.) One of these resources that she created early in my homeschooling life was copywork books.

If I hadn’t stood in awe behind her red patchwork recliner as she typed up a line in one of them, I would never have known that she created the books. They were professionally formatted and bound—my dad is a graphic designer, so I imagine he did that part— and there was even one of those little promotional blurbs on the back.

As we all gradually grew out of needing copywork books, she moved on to selling them to other homeschooling parents in our area. And then, one morning when I was around fifteen, she sat me down in the living room.

She talked to me about the fact that she wanted to make this into a real business, which would be able to sell not only her copywork books but also other homeschooling resources that she might come up with in the future. In order to do that, she would need two things: an online presence, and a name. Evidently, she wanted my help with those.

Having only recently started web programming, I decided to tackle the easier thing first, and I started brainstorming names. After a few minutes, I came up with the Latin half-sentence “spes et”, which means “life and”. I figured that leaving the part after “and” blank would let the reader fill in whatever they wanted. My mother and I contracted the phrase into one word, and at last, Speset was born.

Once I had a name, I got started on the graphic design. I sketched out on paper the general idea for what I wanted to do—a young person standing in front of a bookshelf with “S P E S   E T” spelled out on book spines—then imported the image to Adobe Illustrator to create the real vector. I made sure that the image was a web-worthy 960px wide and used the “save for web” function in Illustrator (back when that was a thing, it’s called “export for screens” now) to make sure that everything rasterized nicely.

One of the biggest problems I had when creating the graphics for Speset was the color scheme. My dad’s aesthetic is dark wood and leather, so he created the book covers with that in mind. Unlike a book cover, though, a website looks kind of ugly with a leather texture, so I had to find a way to convey the same idea with only flat colors. I ended up settling on a bright gold, a dark red-purple, and a light reddish-brown. I thought I might add a wood-grain texture to the background of the site, but I decided it would be too distracting and opted for a simple warm grey instead.

After the graphics were finished, I had to get started on actually coding the website. To start with, though at this point I knew almost no PHP, I used the .php file type because there was one thing I’ve always loved to do in PHP: includes. Though I knew how to import an external stylesheet or script, I didn’t know it was possible to import another HTML file. Because I wasn’t a fan of copy-pasting code over and over, or of accidentally failing to copy a closing div tag and thereby ruining everything, I loved to use PHP includes. I still do; though I now know that HTML can do includes, and though HTML5 can do forms now (I used to need PHP for that), PHP is still more powerful than HTML, so I use it to keep my doors open.

I put my nice header image into an include, made other includes for the nav bar and footer, then went about writing content. I already had the blurbs I wanted to include—they were the same ones on the backs of the books—but I needed to figure out how to format them. Given the very small amount I knew about CSS at the time, creating a two-columned list next to an image that used a specified font size and amount of space between columns was a daunting task!

After a lot of fiddling and finnicking, I’d added all our books, the final thing I needed to do was add the mailing list from Mailchimp. The code wasn’t the hard part, since they provided the form and I just had to style it; setting up the account in the first place was a little more challenging. I eventually managed, though, and I set it up to send me emails whenever I gained subscribers to the mailing list.

Over the course of the next few years, I made a handful of improvements to the website, but mostly just added new books as they were published. One thing happened that I wasn’t expecting, though. I didn’t figure it out until earlier this year, when I started cleaning out my inbox, but when I did, I realized I had a lot of emails from Mailchimp.

At that time, I hadn’t sent out a single email to any of the Speset subscribers. I hadn’t even done a single ounce of marketing. Beyond the mere existence of the website, I had done nothing at all. And yet, I kept seeing emails from Mailchimp. After a few scores of them I thought to log in to my account and check the subscriber statistics. I blinked a few times when I saw the number. Over a hundred?! Dude!!

I’ve since realized the probable reason this happened. Before I’d created the website, the books already had a niche following on homeschooling forums: my mom had done a good job at word-of-mouth marketing. But, they were all just floating about in the Amazon aether, without anything connecting any of the books to each other. Once they all had a single home, the people who’d already cared about them were able to get to them more easily, and to recommend our products more easily. The mere existence of the website promoted both brand loyalty and word-of-mouth.

Here’s the website, by the way. Thanks for reading.

Why to Use CSS Instead of JavaScript for Your Menus

Before I start on this post, if you haven’t read Good Tech Things to Know, I recommend you read that one first. I’ll be referencing what I wrote in that post for purposes of explaining the tech in this one. If you already have a basic understanding of what both JavaScript and CSS are and what they do, you’re welcome to hang out here, but the link’s still there if you need it.

That said, let’s dive into a lesson I learned very recently: why to use CSS instead of JavaScript for menus.

To start off, let’s explain what I mean by “menus”. A menu is just a place that a user can go to choose from different options; just like in a restaurant. In the context of websites and applications, menus can be used for navigation, selection, input, and more. There are a number of types of menus, but one of the most common, especially for navigation on websites, is a drop-down. Here’s an example. You can hover your mouse over the square labeled “Two” and get four additional options. Here’s another example. You can click on any of the squares with arrows and access additional options. This example is a bit more complicated, since hovering over some of the options shows yet more. Still, both are the same style of navigational menu.

The first example menu is created with CSS. The second is created with JavaScript.

It’s pretty easy to understand how you could create a menu like that with JavaScript. After all, JavaScript is a programming language, and programming languages can make decisions and do things. The decision for a drop-down menu goes something like, “if the user hovers over the square labeled ‘Two’, then display the drop-down; if the user stops hovering over any part of the menu, then stop displaying the drop-down.”

But if you recall, CSS is a markup language. It doesn’t make decisions and it doesn’t do stuff, it just styles HTML. So how exactly is it possible to make those decisions using CSS, and why am I saying it’s preferable to do so?

To answer the first question, I’m going to delve a bit more into how CSS works. Don’t worry; I’ll make it easy.

The basic structure of CSS is a bunch of commands that look like this:
property: value;
For example, take the statement “color: blue”. Color is a property which tells the computer what color a piece of text should be. It has a huge range of possible values. Blue is the specific value of the color property that we want to use in this circumstance.

A lot of the time, CSS properties don’t have such obvious names. For example, what do you think “margin: auto” does? It’s not obvious by reading the property name, so the programmer needs to know by rote. (Which this programmer does. “margin: auto” centers something.) So, the process of coding CSS is essentially translating between what you want the computer to do, and what properties you should set to what values to make that happen.

For purposes of creating drop-down menus with CSS, the single most important property is “display”, and the most important value of that property is “none”. Basically, “display: none” removes something entirely from the page. It’s like a CSS backspace key.

This “backspace key” is really useful for doing things like removing a drop-down menu from the screen when the user stops hovering over it.

So if that’s the “then” part of the statement “if the user stops hovering over any part of the menu, then stop displaying the drop-down”, how do we code the “if” part? How can we tell whether or not the user is hovering over the menu?

Fortunately for us, the part of the computer that figures out whether or not the user is hovering over the menu is not programmed in either JavaScript or CSS. It’s built into the web browser itself. So, both languages have the capability to figure that out. In JavaScript, it goes
if (!event.target.matches('.nav'))
In CSS, it goes
.nav a:not(:first-of-type) { display: none; }
Don’t worry about not understanding those code snippets, I just wanted to show them to you to demonstrate how different the same basic code looks in different languages.

So, we’ve got both pieces. We’ve got the decision, and we’ve got the action. And so, we can program drop-down menus with CSS, even though it’s not technically a programming language. Pretty cool, eh?

Now, I did previously say that not only is programming menus with CSS possible, it’s actually preferable. There’s one simple reason for this: ubiquity.

An unfortunate fact of life for web designers is that not everyone is going to be seeing your website in the same way. Their screen size could be bigger or smaller, or have different proportions. Their browser could be different from the one you use, or it could even be text-only. They may have some extensions enabled that you’ve never heard of, and they may not have extensions enabled that you use daily. And every one of these differences affects how that user will view your website. If your website isn’t usable to everyone on every device with every setting, you’ll drive away a ton of potential customers.

I bring this up because JavaScript is actually one of those potential differences between you and your users. There are a lot of people who don’t have JavaScript enabled. If you program your website’s navigation using JavaScript, your website will be completely unusable to someone who doesn’t have it enabled.

Nobody wants to disable CSS, however: while JavaScript is frequently used to make pop-ups and ads visible, and otherwise isn’t used for integral functions; disabling CSS would not prevent ads from being displayed and is one of the most integral parts of a webpage.

So, CSS is ubiquitous whereas JavaScript is not, and a crucial piece of your website should not be created with a non-ubiquitous language. That is the reason that I recently deleted all the JavaScript code I had for my website navigation and decided to start over with CSS. And that is the reason that you should program your menus with CSS instead of JavaScript.

Good Tech Things to Know: An Incomplete List

In today’s technology-saturated world, it’s very helpful to know some stuff about tech even if you’re not yourself a technologist. However, I’m very aware that good explanations of tech for non-tech people are few and far between. So, in this post, I’ll give some simple explanations of some of the most common tech things you might want to know.

The Structure of the internet

If you’re reading this, I’m going to presume you use the internet, and I’m also going to presume you know that it’s primarily composed of web pages. You probably don’t know, however, how exactly those pages are constructed.

Fortunately for you, it’s surprisingly simple. There are three main components to a web page: HTML, CSS, and a big bucket of other Miscellaneous Things. HTML and CSS are what are called “markup languages”. They create the structure and style of a page, but for the most part they don’t do anything. Miscellaneous Things, which include SQL and JavaScript, are “programming languages”: they actually do stuff, like perform actions and make decisions.

Think of markup languages like a static piece of text, and think of programming languages like a button.

Now let’s add some more detail about all of those components, starting with HTML. HTML stands for HyperText Markup Language. (The markup language bit you already understand, and I’ll get to the hypertext bit in a moment.) Essentially, HTML creates the framework for a webpage, by itself, with no stylization (color, layout, etc). Now, when you think of “framework”, it can be tempting to think of a wireframe: a website wireframe

But this isn’t what I mean. See, though there are no images or color, there is still style, because there is still layout. There are distinct sections. The spots to put images are different sizes. Text is organized in columns. HTML, by itself, contains none of these. HTML, by itself, looks like this.

ultra-basic pure html page

Kinda boring, eh?

Text is organized in a single column. It may be bigger and bold if it’s a heading, but that’s the browser’s default style; technically, HTML doesn’t do that, your browser does. If you display pure HTML, you get a single left-justified column of black text with images and links on a white background. (The presence of links, by the way, is the definition of hypertext. Remember I said I’d get to that? It really is that simple: “link” stands for “hyperlink” which is another word for hypertext.) Overall, it’s really uninteresting to look at.

This is where CSS comes in. CSS stands for Cascading Style Sheets, and it’s that middle word we care about: Style. Essentially, CSS creates the colors, fonts, layouts, and almost everything in a website that you care about. The fact that the text you are reading now exists at all is because of HTML, but the fact that the text uses the font Merriweather is because of CSS.

All HTML is supposed to do is tell the computer what stuff is: what part of the webpage is a heading, or body text, or an image, etc. CSS is the thing that makes all of that visually interesting: for example, it tells the computer that the headings should be blue, the body text should use a serif font, and the images should be on the right-hand side.

CSS is actually the reason that wireframes exist. You don’t program a wireframe, you draw it, and the reason is that wireframes don’t exist for the benefit of computers. Wireframes are planning tools that exist for the benefit of humans. Computers already have something to tell them how a webpage should be structured without CSS: it’s called HTML. But a human needs a picture to know that, because humans think in pictures, not code.

You now understand a good third or so of how the internet works. HTML creates the website structure by telling the computer what stuff is. CSS styles that structure into something aesthetically pleasing to humans. Before we move on, let’s dip our toes into the Miscellaneous Things bucket, otherwise known as programming languages.

You already know the most important thing about programming languages: they do stuff. And essentially, they do two things: they perform actions, and they make decisions. (Frequently they do both.) An example of an action is changing the color of an icon. An example of a decision is figuring out which browser the user is viewing the page on. An example of doing both is changing the color of an icon depending on the user’s browser.

The above examples can be done with JavaScript, which is probably the most popular programming language used on the web. JavaScript is also frequently used in the creation of navigation menus, login forms, and various site-enhancing animations.

As a side note, it’s important to make the distinction between the actual, visible piece of the webpage—the buttons, links, input fields, etc.—which are created using HTML and CSS like any other visible website piece, and the decisions and actions that are attached to those visible website pieces—the action to be taken when the button is clicked, when the link is hovered over, when the input field is typed into, etc.—which are created using JavaScript. These are separate components of the webpage.

Here’s another, slightly more complicated programming language that’s frequently attached to websites: SQL (pronounced “sequel”). SQL stands for Structured Query Language, and yet again, the middle word is important: Query. Essentially, a query is a request for information. Here’s an example. When you log in to a website, you type your login information into the input fields and hit the submit button. When you do that, the server (the electronic place where your data is stored) is asked by the webpage for the login data. The answer to that question is fetched by SQL.

Fetched from where? Well, on the server, the place where the data is stored is called a database. The database is built, managed, and queried with SQL. When a new user creates an account, their login information is stored in the database, and whenever they log in again, the information they typed into the input fields is checked against the data stored in the database. All of this happens with SQL.

Everything we’ve talked about on the web so far—HTML, CSS, Javascript—happens “client side”, aka, on the user’s browser. SQL, by contrast, happens “server side”, aka, on the server where the website data is located. Client side processing happens where it does because the experience is different for each user, depending on the size of their browser window, what type of browser they’re using, etc. Server side processing happens where it does because the data is collected from a huge number of different users, so it makes the most sense for the resulting gigantic amount of data to be stored in one centralized location.

Here is the major takeaway: Computers think dramatically differently than humans. HTML is the basic structure of a webpage from a computer’s point of view. A wireframe is the basic structure of a webpage from a human’s point of view. People who program computers need a foot in both doors: obviously, they think like humans, but they also need to understand how to think like a computer. Computers don’t speak English, computers speak code, and if you want a computer to do what you want, you had better be able to talk to it in its native tongue.

Search Engine Optimization

Now that you generally know how the web is structured, let’s talk about a surprisingly little-understood but incredibly crucial aspect: search engine optimization, or SEO.

If you’re reading this, I’m going to presume you know what a search engine is. What you probably don’t know, though, is how exactly search engines decide what results go first. When you search for something on Google, you see results in a certain order, but what algorithm generates that order?

The answer is constantly changing for two reasons. First, as soon as companies figure out what the criteria are for higher search result placement, they capitalize on it like crazy, because higher search result placement leads to more customers. (The process of doing this is SEO.) Second, it’s in Google’s best interests for its algorithm to promote the kinds of search results that people actually want to see. If Google’s customers’ criteria for what makes a good search result is different from the kinds of results Google’s algorithm actually generates, the results are skewed in a direction that isn’t beneficial to the customers, and they get mad.

So ideally, if Google makes a good algorithm, the companies will actively try to make their websites better in order to get higher search result placement.

As a side note before I get into the rest of this, one thing a lot of non-techie people don’t realize is that when they search something, there are some results—typically the top ones—that are paid ads. People have paid a certain amount of money to have their product/service shown whenever that keyword is searched. Frequently these are labeled “AD”, but frequently this label is inconspicuous or otherwise difficult to see. In this section, I’m talking about “organic” or “free” top results, not results that are at the top because somebody paid for them to be there.

I don’t know the whole of the algorithm Google uses, since it’s obviously a closely-guarded secret, but here are some of the well-known portions of it that are commonly used by companies for SEO.

  • Improving page load time. Visitors to a site really hate having to wait a long time for a page to load, so search engines put websites that load quickly higher in their rankings.
  • Having other websites linking to yours. This was a much bigger thing ten years ago, but it’s still a part of the algorithm. Essentially, if a good number of other websites link to yours, then the people posting on those other sites probably think your content/product is good, so search engines put your website a little higher. The reason this is a smaller component of the search engine algorithm is it’s really easy to cheat. Back when this was a larger portion of the algorithm, companies would create a ton of small sites that linked liberally to their main site.
  • Visitors click on your page, stay on your page longer, and/or visit other pages on your site. If you can get, and more importantly keep, your visitors, your page is probably giving them what they want. The ranking in search engines for these things is as follows:
    1. The user clicks on the page, spends a decent amount of time there, and proceeds to navigate around on the rest of the site.
    2. The user clicks the page and spends a decent amount of time there.
    3. The user doesn’t click the page.
    4. The user clicks the page, but clicks away almost immediately.

That last one might seem strange. Shouldn’t those last two be in the opposite order? No, and here’s why. If the user doesn’t click the page at all, they may think “no, that’s not what I want”, or they may have just not noticed it. By contrast, if the user clicks the page and then immediately clicks back, the search engine can be reasonably sure that the user thought “no, that’s not what I want”. The difference is between a pretty certain “no”, and a merely possible “no”, hence the ranking.

  • The page uses words/phrases contained in the user’s search. In the 00s, this actually used to be almost the only method of SEO. The reason this changed was that, like my second point above, it is very easy to cheat. Companies would create a ton of webpages on their site that came very close to spamming a particular keyword, while still looking enough like a genuine article to fool a search engine. (Some of the first paid work I ever did was working freelance writing articles like these; I remember writing 500-word articles on black mesh, swimming goggles, and other miscellaneous junk.) However, due to its importance in determining a good search result given how search engines fundamentally work, this remains a pretty large portion of modern SEO. They’ve gotten around companies doing the 00s-SEO by making “stuffing”, or the overuse of keywords, a penalized practice.
  • Search engines can move easily through the pages to find what they need. This one is kind of blatant self-interest on behalf of the search engines, but it still makes a lot of sense. Search engines have a ridiculous amount of internet to “crawl” through (that is the technical term, I’m not kidding), and they want to show their users their search results as quickly as technologically possible, so they prioritize pages that are easy for search engines to find information in.
  • The site works well on mobile. Nowadays, a lot of people view webpages on their mobile phones, not just on desktop. However, mobile-enabling a website is hard (trust me, I know). So, to incentivize developers to do it, search engines give heavy penalties to sites that don’t have good and usable mobile versions.

These are just some of the most crucial and important ones off the top of my head, but there are a huge number of other factors. For further reading, see this insightful SEO Periodic Table.


That’s all for right now! I will probably update this list whenever I find another tech thing that somebody doesn’t understand. If there’s a tech thing that you’ve been hearing about but don’t get, absolutely post it in the comments: I’d love to hear from you and update this post accordingly.

How to Write CSS That Doesn’t Suck

A few days back, I read an article that ended up significantly improving the way I wrote CSS. Given how quickly and easily stylesheets can get horribly disorganized and out of hand, I found the tips to be immensely useful.

The article is primarily for teams of coders, who need to keep a ton of CSS organized such that many different people can understand it. Even so, I found a lot of it useful as an independent developer. Here are the things I found most useful:

  • Group related styles together. If you do absolutely nothing else this article mentions, do this. It is so helpful to scroll through a stylesheet and know that since you’ve run across your <p> tag styles, your <h1> styles have got to be around here somewhere.
  • After you’ve grouped related styles, try to arrange them by which page or set of pages they apply to. After that, create some suitably humungous, obnoxious, and obvious comment headers and make section headings, like this:
    /********************\
    ** ABOUT PAGE STYLES**
    \********************/
    This makes it infinitely easier to know which page you’re styling and also helps save your ass if you accidentally name a class or id something stupid and uninformative.
  • Make constructive use of white space. For closely-related styles, put only one blank line between styles; for more loosely-related styles, use 2 or 3. Put 4 blank lines before a new heading. This groups stuff up visually and makes it even easier to find what you’re looking for.
  • In terms of individual styles, use this standard format. It’s easy to read, it’s the near-universal standard, and more. Single-line CSS is almost never a good idea.
    .foo {
      display: block;
      background-color: green;
      color: red;
    }
  •  Indent full rule sets if they’re nested. For example, if you’re mobile enabling, indent all the styles inside the brackets after the @media tag.
  • If a style relies on another style elsewhere, or if the meaning of the styles is otherwise at all ambiguous, add a comment! CSS never has enough comments. I know it’s annoying that there’s no single-line comment, but seriously, you can afford to type that extra asterisk and slash to make your code readable.
  • Last tip: be very, very literal about your selectors, because the computer certainly will be. Do not say “header ul” when you mean “.nav”; even if you don’t have another ul in your header, this kind of selector generality is a very bad habit that can and will come back to bite you. Whenever you’re writing a selector, ask yourself: “do I want ALL x, or just some x?” If you want just some x, write a more specific selector. Even if you don’t think you’ll ever use the other types of x.

If you want more CSS tips, go on and read the full article! It’s a fun and helpful read, full of great info. Otherwise, that’s all for today: happy coding!