Author: Maëlys McArdle

An interesting article came out on FiveThirtyEight called How to Tell Someone’s Age When All You Know Is Her Name. Based off of only a name, you could make a pretty good guess as to when they were born. It was particularly cool read given that I had actually been going through the same dataset myself.

My research had to do with the name of transgender men. I kept seeing the same names popping up, and I wanted to know whether:

• The names reflected their popularity at their time of birth.
• The names reflected their popularity at the time of their selection.
• The names reflected their popularity among their peers.

This wasn’t for academia or anything; I just wanted to know for myself. I decided that I would answer this by seeing what the most popular names were for trans men, and compare that with the popularity of those names with the general population over time.

The first step was to figure out what the most popular names were. There’s a blog with posts from the trans male diaspora where first names are often mentioned. So I wrote some software to take a peek at the names being used. I utilized a database of names from the Social Security Administration to pick out first names from the noise. The results were interesting.

The software was written in two parts using Python 3.4.

Part One: Blog Scraper

import http.client
import html.parser
import pickle

class TumblrPageParser(html.parser.HTMLParser):

    def __init__(self):
        super().__init__(convert_charrefs=True)
        self.is_caption = False
        self.results = []
        self.entry = ""

    def parse(self, page_contents):
        self.is_caption = False
        self.results.clear()
        self.feed(page_contents.decode("utf-8"))
        return list(filter(len, self.results))

    def handle_starttag(self, tag, attributes):
        if tag == "div":
            if "caption" in [content for attribute, content in attributes]:
                self.is_caption = True
                self.entry = ""

    def handle_data(self, data):
        if self.is_caption:
            self.entry += data

    def handle_endtag(self, tag):
        if tag == "div" and self.is_caption:
            self.results += [self.entry]
            self.is_caption = False

def parse_blog(blog_url):

    conn = http.client.HTTPConnection(blog_url)
    conn.request("GET", "/")
    response = conn.getresponse()
    page = 1

    while response.status is 200 and page < 2000:
        captions = TumblrPageParser().parse(response.read())
        yield page, captions
        page += 1
        conn.request("GET", "/page/" + str(page))
        response = conn.getresponse()

def download_blog(blog_url, filename):

    with open(filename, "ab") as output:
        for page, captions in parse_blog(blog_url):
            print("Processing page " + str(page))
            output.write(pickle.dumps(captions))

download_blog("a-blog-name.tumblr.com", "scraped_posts.pickle")

Part Two: Name Analysis

import pickle

def load_names(year):
    with open("names/yob" + str(year) + ".txt", "r") as name_file:
        for line in name_file:
            first_name = line.split(",")[0]
            yield first_name

def load_scraped_data(filename):

    with open(filename, "rb") as input_file:
        while 1:
            try:
                for tumblr_post in pickle.load(input_file):
                    yield tumblr_post
            except (EOFError, pickle.UnpicklingError):
                break

def extract_words(line):
    return line.replace(",", " ").replace(".", " ").replace("(", " ").replace(")", " ").split(" ")

def extract_names(scraped_data_file, name_year):

    first_names = list(load_names(name_year))
    tumblr_posts = list(load_scraped_data(scraped_data_file))
    names = dict()

    for counter, post in enumerate(tumblr_posts):
        print("Processing Post " + str(counter) + "/" + str(len(tumblr_posts)))
        for word in extract_words(post):
            potential_name = word.capitalize()
            if potential_name in first_names:
                names[potential_name] = names.get(potential_name, 0) + 1

    return names

def trans_name_popularity():
    trans_names = extract_names("scraped_posts.pickle", 2013)
    names_sorted_by_popularity = sorted(trans_names, key=lambda name: trans_names[name], reverse=True)

    for name in names_sorted_by_popularity:
        print(name + " (" + str(trans_names[name]) + " hits)")

trans_name_popularity()

The Results: Most Popular Names for Trans Men

1. Alex
2. James
3. Oliver
4. Ryan
5. Jake
6. Cameron
7. Dylan
8. Aiden
9. Tyler
10. Andrew
11. Lucas
12. Max
13. Andy
14. Adam
15. Daniel
16. Noah
17. Eli
18. Liam
19. Sam
20. Charlie

Take the results with a healthy dose of skepticism; there’s loads flawed about this approach.

The most popular baby names for 2014 were well represented in the top names for trans men. Names like Eli, Liam, Noah, Jayden, Aiden, etc. Presumably when many of them had come out. Thus you could actually make a guess as to when someone came out based off of their names.

The other top names would have been the most popular around the time of birth of the individuals. So it seems to be a little bit of column A, a little bit of column B. I didn’t answer whether social networks had an influence on it. Would be an interesting question but not one I’ll explore.

It was a cool little experiment.  I answered my question and deleted any data that was on my computer pertaining to this. I became uncomfortable with the idea of a blog scraper and I don’t think I’ll ever design one again.

I’ve been programming professionally for five years now. Since I’m likely to be in the field for many years to come, what I intend on writing here is a reference to see where I was at in terms of my approach.

Reduce Opportunities For Errors

Everything I do is focused around reducing the opportunity for error.

The first step is I pick a programming language that will require the least amount of code to achieve the task while satisfying other requirements around performance, longevity, and deployment. Sometimes that’s Python. Sometimes that’s C. The less code there is, the less opportunity there is the opportunity to introduce error.

I remove any repetition as to make the contents of my functions only be what makes them unique. Every repeating instance is an opportunity to forget applying a change I did to some other part. I also code in such a way to make some bugs appear at compile time rather than run-time. For instance, I’ll store strings as defines in C/C++ as to remove one type of repetition and make typos pop up as compile errors.

Employing practices like unit testing is another big way to reduce errors. It’ll catch some bugs that might otherwise fail to show up until a specific set of conditions occur in a running program, which can make it a pain to locate.

Write The Idealized Code

I structure code from the most abstract down. I specify what would be the function/method calls to make with the perfect library, one after the other, to solve a given problem. I then populate those functions after the fact, applying the same approach. Each invoked function/method is just a single-line return statement until properly populated. I refactor continuously.

I find that the top-down versus bottom-up approach leads to code that’s better structured and more legible.

Keep Code Legible

If there’s a Venn Diagram for ideas, this is one that is impacted by a slew of other practices.

I follow the conventions of the language. For C++, my functions follow the lowerCamelCase pattern. In Python and C it’s the underscore_name_pattern. If common practice dictates to use four space indentation, then that’s what I do. That consistency improves legibility for developers which reduces opportunity for error.

Likewise I always avoid those clever one liners. If it’s meaning is not immediately clear, I get rid of it. I want to remove as many barriers to understanding my code as possible. Leave cycle-level optimizations to the compiler. The losses that matter are usually several levels of abstraction up.

My lines of code never exceeds 80-120 characters, my functions rarely are more than a handful of lines, my files rarely exceed 200 lines. The more you have the more someone reading the code will have to track in their head, which makes the code less approachable. You want approachable. It also forces some level of modularization. The easier it is for someone else to pick up the code, the less likely they are to miss out the ways their changes could have unintended consequences.

I never comment out parts of code permanently as a way to disable it for potential future use. That’s what code revision is for. It just clutters up the code.

Only Code What’s Unique

It’s really fun and cool to solve problems on my own. Figuring out how to write an email client from the TCP level. Learning how encryption works. I’m all for that.

However, I avoid the Not Invented Here syndrome for production code. If there’s a library to do a given task, it’s probably better than what I could have put together on my own. I focus instead on writing the glue to interface with that library. I focus on the parts that make my software unique.

Sometimes it’s necessary to re-invent the wheel, but I only do so when there’s a demonstrable need.

Document The Code

I also document the code following whatever standard is set by the automatic document generator for that language. For Python that’s docstrings. For C/C++ I use JavaDoc for compatibility with Doxygen.

Comments are invaluable for maintainability. I hold the view that leaving it to the code is insufficient. Comments bridge the gap between how a computer thinks and how people think. The code explains how, the comments explain what.

I also automate as much of the documentation process as possible. I consider commit messages a type of documentation and use generators like Doxygen. For outward-facing code, if it’s not documented – it doesn’t exist.

Learn To Get Uncomfortable

Software development is unlike many fields in that there isn’t a relatively stable body of knowledge to work towards. Rather, that body of knowledge changes drastically every few years less you work as a programmer for NASA.

General skills around the process of software development are more static, but only just. Core knowledge around data structures has looked the same over the last thirty or forty years, but processes such as Agile and test-driven development are quite new.

So it becomes necessary to keep learning new things and to avoid staying comfortable with a body of knowledge.

I do this for two reasons. The first is that it really improves my workflow. All of these are born out of the lessons learned by other developers. Integrating those lessons saves me much time and effort, whether it be debuggers, revision control, unit testing, agile, etc. They were always prefaced with a learning curve that made me question their worth but it always proved invaluable.

The second reason has to do with my reality in which I’m seen as disposable. Every one of my friends in the private sector, with few exceptions, have recently been laid off. Some multiple times. My own company has reinforced the notion that I’ll be dropped the second it’s convenient to do so. In this environment then I have to be my own agent so that if I’m laid off tomorrow, I’ll be employable. I seek to hold myself up to the standards of the top developers I know.

Take Care Of Yourself First

The most important lesson of all though has less to do with code.

There’s only one person out there that can put your well-being first: you.

Don’t miss out on spending time with those that matter in your life (including yourself) because you were working nights and weekends. Take those impromptu days off for self-care. Spend time with your chosen family. Don’t look at your work emails after 5pm.

There are many companies and people within them that would rather you didn’t do this. Those people have different priorities. That’s okay. This is why you’re there.

There’ll always be people who make more than you. Maybe most people. But if you make a livable wage, have full-time work on regular hours, have your health, and a network of people that love you – then you’re pretty much golden. Those other people will have nicer things. Let it go.

At the end of the day, it’s the people that matter most.

And your time with them is the one thing you can’t get back from working evenings and weekends with a company.