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 Should I Learn?

The world of technology is very fragmented, or at least it looks that way to a young techie. It’s hard to know what is and isn’t in demand, and therefore, it’s hard to know what to focus on. If you’re equally good at three different languages, which one should you pick?

At the time of this writing, I have solid entry-level skills in HTML, CSS, JavaScript, and Java, as indicated by my MTAs. I’ve also got some skill in SQL, though I haven’t taken the MTA exam yet. For some time, I’ve been trying to decide what area to focus on.

My general idea was that I would focus primarily on web development (HTML, CSS, and JavaScript) because it was really difficult for me to learn all three languages, and I figured that the difficulty would make it a highly marketable skill. I knew from my mom (who works with SQL and SQL programmers) that SQL was also a pretty marketable skill, so I thought I’d put some effort into learning that.

I never put much systematic effort into learning Java. I took the AP Java and a class in Java from CCAC, and I did difficult projects for each, but that was it.

The reason I wasn’t big on Java was that I’d heard from a number of sources that Java was on the decline. I only learned it at all because it was one of only two computer-related APs, and at that point, I still wanted to get into a top-tier college with a major in tech, so I needed it.

This is why I thought it was really weird when a bunch of recruiters started asking me about full-time Java positions on LinkedIn. I have all my skills listed on my profile, and it’s not like Java is the most prominent in that list, so I didn’t know why they would want me for Java in particular if the market share wasn’t that big. Why weren’t they asking me about JavaScript instead?

I caught a glimpse that my perception of reality might not match reality—in Eliezer Yudkowsky’s words, the map might not match the territory—so I started looking for where I might have been wrong.

I found all kinds of stats saying that JavaScript was the most popular programming language. That should mean that it doesn’t pay as well since it’s more abundant. But still, I wasn’t looking for popularity among programmers. I was looking for demand among employers.

In comparison to the huge number of articles talking about language popularity, there were relatively few talking about actual job postings. But when I did find some, I was pretty astounded. In most of the lists I found, Java was solidly in first place. Some lists put SQL first and Java second. But JavaScript was almost never ranked higher than third, and it was frequently ranked lower, below languages like Python and flavors of C.

As I looked at the colorful bar graphs, I realized what I’d done wrong. I’d falsely assumed what many people assume: that because something was hard for me, it’s hard for everyone else (and thus will pay well since it’s scarce), and likewise, that because something was easy for me, it’s easy for everyone else.

Further, I’d also committed the fallacy of base rate neglect: when I’d read that Java was on the decline, I hadn’t considered where it was on the decline from. Evidently, it was declining from a truly overwhelming majority on the market.

With this knowledge, I decided to change my path. I’d stop worrying so much about web development and split my efforts between the languages with the most market shares: Java and SQL.

If you’re considering going into tech, take a quick look at those articles I linked. There’s a lot of advice out there, with a lot of hidden assumptions behind it (ex. assuming that just because you’re a beginner programmer, you don’t want to try a language that’s difficult to understand, such as SQL). Figure out what pays and make your own judgments. It’s never too early to start: my sister, who’s halfway through her accounting certificate, decided she wanted to be an accountant at the age of 6.