## Algorithm Design for Minimization of Time Complexity

This project requires a bit of background, for those who aren’t familiar with Google Ads. (For those who are, please skip down to the horizontal bar.)

When you search for something, some ads may show up at the top of the results page. Those ads were paid for by companies who had decided those ads were bringing in enough profit to be worth it.

This particular project involves automation of a specific portion of step 2. To try to maximize their ads’ conversion rates, marketers only want to serve their ads to people who have the highest chance of clicking, and ultimately, converting. A very important tool in the marketer’s arsenal for this goal is the negative.

Negatives, short for negative keywords, are keywords that tell the search engine that they should not display your ad if that keyword is part of the search query. For a quick example of why you might want to do this, consider that you’re running a bakery and you have two ads, one for cake recipes and one for carrot cake recipes. Now, obviously, you want only the cake recipe to show up when someone searches “cake recipe” or something similar, not when they search “carrot cake recipe” – you have a separate ad for that for a reason! So what you can do is make the word “carrot” a negative for your cake recipe ad.

This concept of negatives is useful for any circumstance where you don’t want your ad to show up – including because the keyword has a low conversion rate. And this is what this project is about.

This project involves taking a list of search terms and finding individual words which are always associated with a lack of conversions over an extended period of time and bringing them to the attention of the marketers running the ad campaigns so they can negative them. Therefore, it involves taking a table with a column of strings and a column of ints and isolating individual words (separated by spaces) which are associated with, and only with, int values of 0.

I considered a wide variety of possible algorithms in the course of working on this problem but ultimately wanted to find something which had a minimal time complexity and could run moderately quickly over tens of thousands of data points (six months or more worth of keywords and conversions).

I wanted to make sure I was looping through the dataset as few times as possible, so I would make sure to fetch the data, only store what I would absolutely need, and store it in a separate array so I didn’t have to deal with the hassle of deleting elements and having the machine shift everything else back, since I was liable to do a lot of deletions.

I will admit that this problem took me a long while to crack. I had too hard a time visualizing a massive dataset with so many different terms to think about doing any logically complicated data manipulations to it. So my first step was to simplify it to a little table, like this:

Strings | Ints
"a x" | 0
"a y" | 1
"b x" | 0
"b y" | 1

Abstracting away everything but the bare bones of the problem helped me finally realize what I succinctly described at the beginning of this essay, that I wanted to find all the elements with, and only with, an int (# of conversions) value of 0.

Once I removed that block, the ideas started pouring out. I went through about twenty different possibilities before settling on this basic concept:

1. Fetch the data from an Excel spreadsheet to a Pandas DataFrame.
2. Loop through the DataFrame, splicing each individual search term and splitting it into component words.
3. Add each word associated with the number of conversions of the search term it’s a part of into another array, in alphabetical order.
4. For each word in the resulting array, while the word is equal to the one in the next row after it, check if all conversion values are equivalent to each other and to 0.
5. If they are, add the word to the final array; as soon as they’re not, skip to the next word and run that through step 4.

Now what’s left is to actually implement that. *exaggerated sigh*

What did you think of this post and this algorithm? Is it a good idea? Did I screw something up colossally? Please let me know in the comments below!

## Thoughts on the Basics of Go

Disclaimer: I’ve been studying Go for two days. There are some neat things I learned about it, so I decided to document them, but if anything in this post is factually inaccurate, please let me know so I can correct it. Thanks!

Go is an object-oriented, statically-typed programming language created by Google in 2007, which makes it the only language I know that’s younger than me. (Python and JavaScript aren’t as young as you think they are, they were both created in the mid-90s. Yeah, I was surprised too.) Go seems to me like a weird lovechild of Java and JavaScript, but then again, I have heard it’s more like C, I just didn’t make that connection because I don’t know C.

That being said, if you already know both Java (or some other statically-typed OO language like C) and JavaScript (or some other dynamically-typed language like Python) most of the basics of Go aren’t going to seem odd to you. Go is statically typed, but it’s much smarter than Java in terms of inferring variable types, so the actual top-level programming feels somewhat like JavaScript or Python.

For some examples: Go has a main method that works just like Java, and one variable initialization style, var x int = 10, looks Java-esque. However, the idiomatic style for initializing variables looks somewhat like JavaScript: x := 10, since there’s no explicit type declaration. Overall, in Go, you type way less characters than you do in any other language I’ve used before. Look at the idiomatic initialization above. Or look at how you get a character from an array: arr[2], unlike Java, arr.charAt(2). The + operator is also overloaded to both addition and concatenation, like JavaScript, unlike the Java string.concat() method.

Now for the weird stuff that’s not like any other language I know – though it might be like some other language.

Go only has one loop, which happens to use the for keyword. Using different syntax patterns, it can operate like a for loop, a for-each loop, and a while loop, just to name a few. There’s also a range loop for k := range arr, and if another language I know uses them it’s definitely esoteric.

Go also does a weird thing with arrays. There are three standard types of array-like things: arrays, slices, and maps. Arrays pretty much work like Java: they have a set type and size and can’t be expanded. To fix the “arrays can’t be expanded but I wannaaaaa” problem, instead of going the Java route and making an array-style expandable object type which everyone then uses instead of standard arrays (ArrayList), Go has “slices”. These are segments of arrays which can be expanded when new elements are appended, until the length of the slice exceeds the length of the array, at which point the contents of the array are copied to a new array which is big enough to hold the appended elements. …I think. Maps are, fortunately, simpler. They’re sets of key-value pairs, where the keys and values can be of any single type. So you can map strings to ints, ints to ints, strings to strings, etc.

There are two things about Go which I find neither good nor bad, just very interesting. The first thing is that, among the variously-sized numeric types, there exist numeric types for complex numbers. This sparked a sudden desire in my mind to do something involving quantum physics with Go, although I have absolutely no idea what about quantum physics I would want to write a computer program for. The second thing is that Go does a lot of stuff in the Terminal, which makes me wonder how one goes about writing desktop applications in the language. (According to this article, it’s difficult.) I’m not a huge fan of web development stuff in general, and it’d be kind of annoying to have to make all my advanced Go projects web-based.

Besides slices, nothing about Go seems too awful or counterintuitive, so I’m optimistic about my future studies. As soon as I’ve got something a bit more complicated than Hello World, I’ll post projects and write-ups here. Please look forward to it!

## What is a Feature Flag?

As a digital marketer, I wind up writing a decent number of articles for clients’ blogs. And as always happens when writing about a topic, I’ve learned a decent amount about these clients’ products. Our current biggest writing-focused client is Split, which is a B2B SaaS company selling feature flags as a service. But hold up, what on earth are feature flags? Well, I’m about to tell you.

A feature flag is a piece of conditional code that you wrap around any new feature, which links that feature to a dashboard. From this dashboard you can turn off the feature, release it to only a subset of your userbase, and generally manage all your features so you can see which ones are in use.

Now, how exactly is this useful? To start with, imagine a pre-existing codebase for a currently-working app. You don’t always start with this—one of the ways to implement continuous deployment is to start with a blank canvas—but this is usually how it works and is one of the most common feature flag use cases. Now, imagine a dev team working on a new feature to add to that app.

Without feature flags, this looks like a number of things, all of which are sub-optimal. You end up releasing only a few times a year because you need to do endless testing to make sure things aren’t broken before you push to production. You get crazy long-lived feature branches that take forever to merge back to trunk (“master” in Github terminology) and make a huge mess when they finally do. Or, worst, you accidentally break something but don’t realize until after you’ve already pushed to production, and you have to do a painful rollback to the previous version to fix the bugs, then re-release afterwards, and deal with the fallout from

With feature flags, the scenario looks much better. Instead of testing with your staff before pushing to production, just test in production on your real users—starting with just a select few of them, who have perhaps opted in to be guinea pigs. Instead of making branches which may or may not outlive their welcome and/or create a merge hell when you try to get them back to trunk, you can do everything straight in trunk. And if you break something anywhere in this process, you can just turn the feature off, no rollback required.

Beyond simply making development less of a headache overall, there are some specific things you can do with feature flags that are much harder otherwise. Some notable examples include continuous integration/delivery/deployment, canary releases and phased rollouts, and dark launches.

Continuous integration is the process of constantly and deliberately merging every code change to trunk (/master). Continuous delivery is constantly pushing each change to a production-like environment where there’s only one step of manual testing before it goes to end users. Continuous deployment is similar to continuous delivery, but without the manual testing: automated testing is the only step between the code deployment and the end users.

Canary releases and phased rollouts are similar in that they both involve releasing new features to only a subset of the userbase at first. With a canary release, the userbase subset is chosen and targeted to be test subjects, and they act like a canary in a coal mine, letting developers know whether the feature is safe to release to the broader public. With a phased rollout, you begin with a subset, which you then slowly ramp up until you’ve released to your entire userbase.

Dark launching is, literally, the process of launching a feature while keeping your users in the dark. Specifically, you use all the portions of your real infrastructure that would ordinarily be used in serving the feature, but you don’t actually show it to users. Feature flags can make this happen by letting you restrict access to only internal users, which lets the developers activate the feature in absence of a real code deployment.

There are a bunch more uses for feature flags – some of which are detailed on Split’s or FeatureFlags’s use cases pages, others can be found on Martin Fowler’s blog.

## 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.

## Rubber Duck Debugging: What It Is and What It’s For

Debugging in general is the act of fixing errors (called “bugs”) in computer code. Rubber duck debugging is the act of debugging by explaining your code to a rubber duck.

That’s a simple enough explanation, but why would you want to do that?

Have you ever heard the phrase, “If you can’t explain it to a six year old, you don’t understand it yourself”? The concept is that if you truly understand something, you can explain it to someone who knows nothing about it.

This isn’t just a test of understanding for concepts you already know are sound. You can use the power of explanation to find problems with concepts you came up with yourself. If you explain your logic to someone who knows nothing about it, you’ll be forced to start over from the logical beginning and explain in simple terms.

When you’re the one who created the logic, you can sometimes accidentally accept unreasonable assumptions without knowing it. If you then have to explain the logic, though, you’ll need to spell out your assumptions. And if those assumptions aren’t reasonable, you’ll know it right away.

The best part of this is that it doesn’t require a human. Your brain is good enough at personifying inanimate objects that explaining a concept to another human who simply isn’t replying is functionally interchangeable with explaining it to a rubber duck. So, a lot of programmers explain concepts to rubber ducks (or stuffed rabbits, in my case) instead of inconveniencing fellow humans.

So. What is rubber duck debugging? It’s using your brain’s powers of explanation and personification to fix logic problems.

Rubber duck debugging is hardly the exclusive domain of programmers. Anybody who can use language can explain something to a rubber duck (I don’t even have to say “anybody who can speak”, because I’m sure rubber ducks understand sign language). Writers do it to fix problems with their story plot, for example.

So if you’re ever working on a tricky problem, try stepping back and explaining it to a rubber duck.

## What Is a Tech Cert, and What Is It For?

Last month, as a part of my portfolio project, I got three MTA (Microsoft Technology Associate) certifications, in Java, JavaScript, and HTML/CSS. I documented this fact through my project updates, but if you don’t know what those are, I didn’t offer a lot of explanation.

So, let me take this opportunity to explain what a technology certification is, why it matters, and why if you had to choose between some certs and a college degree, you should choose the certs.

There are a wide variety of different certs, offered by a large number of companies, which demonstrate proficiency with a ton of disparate technologies. Each cert is accorded a certain level of respect in the tech space, based on how central the company offering the cert is to the area of technology tested by the cert. For example: SQL Server, one of the most common flavors of SQL, is owned by Microsoft. As such, the MCSE (Microsoft Certified Systems Engineer) in SQL is one of the most highly respected SQL certs.

Most companies who offer certifications offer them in tiers. I’ll use Microsoft as an example. The MTA is the lowest level of Microsoft certification. After that, the next level is the  MCP (Microsoft Certified Professional), and then the MCSA (Microsoft Certified Solutions Associate). To get an MCSA, you need to pass three or four related MCP exams. The top tier is the MCSE. To get an MCSE, you need to already have an MCSA, then pass one or two additional (much more difficult) exams.

These certifications demonstrate specific things to employers. For example, “I have an MTA in this” means “I am skilled enough at this to get an entry-level job doing it”. “I have an MCSE in this” means “I am an expert at this and have a lot of experience using it”.

Tech certs and college degrees occupy very different niches. Where tech certs demonstrate that you have a certain level of hands-on skill with a specific technology or technological area, a college degree demonstrates (hopefully) that you have a broad proficiency with technology in general. Where a certification is product-specific, company-specific, and clearly leveled, a degree is more subject area focused and doesn’t necessarily include any particular language or technology, and while it does  come in levels (AS, BS, MS, PhD),  the levels correlate to time spent, more than skills earned.

If I say “I have a CCIE”, you know that I have a very high level of technical knowledge about routers and networking in general, and Cisco routers specifically (Cisco being one of the main manufacturers of routers). This is incredibly useful knowledge to employers, who now know exactly what I can do for them. If, however, I said “I have a Master’s degree in computer information technology”, you only know that I’ve spent six years immersed in technology. You don’t know what kind of technology, and if you’re an employer looking to hire someone who knows how to work with Cisco routers, you’ve got no clue if I can do that. My degree might have required one class in networking, or ten, or none at all. You have no idea.

It’s not just that degrees can be highly unspecific and not very useful to employers looking for specific skills. When someone says “I have a degree”, you don’t even know if their knowledge is up-to-date.

Certifications are always up-to-date, in one of two ways. Some certifications are only valid for a certain amount of time. For example, the CISSP (Certified Information Systems Security Professional, a cybersecurity certification) expires after three years, at which point it needs to be renewed. Other certifications are version-specific. For example, if you get an MCSE in SQL Server 2012-14, you have it forever, but you’ll probably want to get one in SQL Server 2016 as well once the newer version becomes ubiquitous.

But a degree doesn’t work like this. Once someone is taught a thing in a class, there is no requirement that they maintain that knowledge to keep the degree up-to-date. Furthermore, the thing taught in the class may not even have been up-to-date at the time it was taught. A lot of colleges have reputations for teaching things that are out of date, not out of malice, but because tech changes faster than colleges can. It’s rare to find college classes that teach the latest and greatest, and it’s common to find colleges teaching material that’s out of fashion, unnecessary, or just plain obsolete.

There’s yet another problem with degrees: they aren’t vendor-specific. I mentioned the CCIE before: the networking certification offered by Cisco. That last part is important. The benefit of a CCIE isn’t just that it says “This person knows routers.” It’s that it says “This person knows routers. Sincerely, the guy who makes the routers.” With a degree, it’s like “This person knows how tech works. Sincerely, a college that you may or may not have ever heard of.” So it’s not just the lack of information, it’s also the lack of credibility behind that information.

It is also important to note something kind of unique about tech: many of the seasoned working professionals in the tech space don’t have degrees in tech. This is because when these professionals were starting out in tech, the field was so new that there weren’t many degrees in it. They got degrees in other things: math, electrical engineering, underwater basket weaving, whatever. The thing that made them tech professionals was their technical knowledge, not what came after “BS in” on their resume. And nowadays, with the advent of certifications, these professionals have MCSEs or CCIEs, not college degrees.

Basically, if you have to choose between a candidate for your job who has a college degree in technology, and a candidate who has no degree but has several certifications and a good portfolio, you’re going to pick the latter. Even so, there is a reason for degrees in tech to exist besides “colleges wanted to jump on the tech bandwagon”.

Firstly, college degrees in tech demonstrate a commitment to learning technology over an extended period. Since you can get certs over however long you want so long as you keep them up-to-date, an employer has no idea whether the candidate with three certs has spent one year or five learning that material. College, by contrast, has a consistent, fast pace, so an employer can infer from a college degree that the candidate is capable of maintaining a high workload for an extended period of time.

Second, college degrees are designed to give you an understanding of the fundamentals of the field you’re entering, including at least the basics in the breadth of the field, plus some significant depth in at least one area. A major downside of having only certs is that you may not have a good foundation: you may be a one-trick pony who knows only one thing, and may do that one thing well, but may not know about how it fits into the bigger picture, what it depends on, or what depends on it.

The big advantage of a degree is that you’re going to come out of it with a general understanding of every major sub-discipline. You come out of a degree in tech with a general knowledge of networking, operating systems, electronics, math and logic, and programming. This is generally how every degree works, and it is in fact a valuable service that colleges provide.

The theoretical ideal candidate has both a degree in technology (for the breadth of knowledge and commitment) and multiple certifications (for specific, up-to-date knowledge about vendor technology). Often in the real world, though, employers will pass up someone with a nice shiny degree in favor of someone who has the right certs and a good portfolio.

## 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:

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.

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:
/********************\
\********************/
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!