Strict Machine

Different Domains, Different Usernames

Sat, 17 Oct 2020 00:00:00 +0000

Once it dawned on me that all my passwords are 1) secure and 2) different and 3) unknown to me, I became obsessed with the idea that I can give my usernames the same treatment. With 1Password I don’t need to worry about any of that! I can make my Twitter username 9844B381-046B-4756-BCE3-0D2006C478E3 if I wanted! Just imagine! I don’t know why this is so compelling, but having non-matching usernames is the kind of pointlessly shady move that’s very on-brand for me.

Look, it’s not in my nature to be mysterious. But I can’t talk about it and I can’t talk about why.

— Rusty Ryan (Ocean’s 12)

My thinking is that it should be at least a little harder to piece together information about me online. Back when I was a “young professional,” (I still am, but I was one, too) and I was really into meetups, it seemed very important to have a consistent online identity. Otherwise, how are people going to find me, and offer me work and opportunities? I guess I really felt the pressure and the expectation that since I’m a developer I should be all over GitHub, and I should be blogging, and, I don’t know, Tweeting my opinions about Angular or whatever. Who’d hire me otherwise? Now it’s ten years later, and I’ve become grouchy and distrustful, and I don’t want any of that, and also I’m busy and I think my resume is probably fine, and I’m not looking for any “opportunities” but thank you.

My usernames on different websites don’t have to match. I don’t need to link all my identities together. It’s okay (in fact, good) that it’s hard to get to my Instagram profile from my GitHub profile. My FOMO is not for anything real.

I think I’d rather have the thin bit of extra privacy of disparate usernames. Anyone who has a reason to know who I am can know who I am, it’s totally fine. I don’t have anything to hide! I just want it to be a little more difficult to piece it all together. Privacy is privacy, you know?

Practical JavaScript Nomenclature

Wed, 09 Aug 2017 00:00:00 +0000

This is a set of rules I set for our internal JavaScript style guide after finding nothing similar online. Having consulted a few of my colleagues and used these extensively myself, I stand by these guidelines and use them every day. I hope you find these either helpful or at least controversial. These rules are optimized for clarity and readability above all. They favour the code reviewer or code maintainer over the code author. Eventually, we are all the maintainer.

Be Clear

choose full words over contractions. options over opts, value over val, userDetailParameters over userDetParams
single-letter or otherwise cryptic variable names like o, i, u1 are strictly not allowed, even loop counters. The only exception is for mathematical formulas where such variables (like x, d1, etc.) have specific meaning
avoid vague verbs like get, set, update. A function name should indicate the level of the system where it operates. For example, fetchUser has a stronger indication that it’s getting the user from the API rather than from memory. getUserFromAPI or api.getUser are similarly unambiguous. Generally, words like get and set imply action on classes and variables, fetch and update imply the API, while read and write imply the filesystem
avoid single-verb functions unless they are also ambiguous. A reload function in a controller is ambiguous, something more specific like reloadUserData or reloadControllerData is clearer

Use Good Grammar

use plural and singular forms correctly. Array variables should always have plural names (e.g. users, promises but never var user = []). This means avoiding vague names like collection and list, and specifying exactly what the list is of (e.g. $elements, links)
use a noun-verb-noun format to name loose booleans. The name of the boolean should make sense as a sentence fragment. For example, viewCanBeReloaded, userHasPaymentInformation
use auxiliary verbs to describe property boolean values or methods that return boolean values. Choose names like view.canShowCalendar and navigation.shouldReturnHome over showElement and returnHome or showingCalendar
use primary verbs for functions and methods. Choose names like goToNextPage() and fetchUser() over nextPage() and user()
use prepositions in functions that operate on multiple objects. Choose names like setOrderAddressOfUser (or setAddressOfUserOrder as appropriate) over setUserOrderAddress
avoid homonyms if possible. For example, opening could be the progressive tense of the verb “open” or it could be a noun meaning a gap or hole, or it could be an adjective describing something that happens at the beginning of something. Make exceptions for this if the previous rule applies

Be Specific

a function’s name should completely describe everything it does including side-effects. This is accomplished either with general function names (e.g. processUser) or very specific names (e.g. updateUserAddressAndPaymentInformation)
if a function exists as a small subset or a small superset of another function, its name should reflect that. If a function called callAPI exists, an authentication-less analogue should be called callAPIWithoutAuthentication
a variable should be given a specific name as soon as it gets a specific meaning. For example, the result of Users.getFavouriteUser() should be called favouriteUser over user

Be Consistent

if a function’s name lists its arguments (e.g. changePaymentProfileForUser) it should take the listed arguments in the listed order. changePaymentProfileForUser should take the arguments paymentProfile and user
do not rename external concepts. If the system or the organization already refer to a certain concept by a specific name, resist renaming that concept in code

Examples

Ambiguous Booleans

A variable called clearSearch is ambiguous. It could specify whether a search is clear, or it could specify whether a search should be cleared, etc. Using an auxiliary verb makes them clear. Choose names like isSearchClear and shouldClearSearch, for example.

Specific Meaning

Variables that have a specific meaning should be called with their assigned meaning as soon as possible, and they should lose meaning when appropriate. Consider this example:

var coordinates = POSITIONING.getUserCoordinates();
return checkCoordinates( coordinates );

function checkCoordinates( userCoordinates ) {
  return userCoordinates.areWithin( CITIES.Toronto );
}

The names of the variables do not reflect their specific meanings. The method getUserCoordinates returns userCoordinates by definition. The function checkCoordinates checks a coordinates variable, by definition. Inside that function, coordinates don’t have any meaning aside from just being coordinates. Also, the verb check is too vague for this case. A better version:

var userCoordinates = POSITIONING.getUserCoordinates();
return areCoordinatesWithinToronto( userCoordinates );

function areCoordinatesWithinToronto( coordinates ) {
  return coordinates.areWithin( CITIES.Toronto );
}

Signatures and Arguments

Here’s an example from an API wrapper:

function getProductByID( parameters ) {
  return $http.get( '/product', parameters );
}

This is a good example of function signatures not matching their parameters. A function called getProductByID strongly implies that it accepts an id parameter, which it should:

function getProductByID( id ) {
  return $http.get( '/product', { productID: id });
}

Long Names and Ambiguity

These guidelines heavily favour long variable and function names, but there’s a pretty natural limit. Function names that have more than 5 major parts of speech (nouns, verbs, and adjectives) are candidates to be renamed. Names like createMembershipPermissionGetter (4 major parts of speech) or checkIfRecipesAreLiked (4 major parts of speech) are still fine, but anything longer needs to be renamed, especially if it’s the part of a public API for a component.

Renaming long functions requires some creativity to find a good name for the overall operation. Oftentimes, it’s also a sign that some refactoring is in order, to group common operations together. For example, consider this structure:

<div
  class="range"
  ng-repeat="range in $ctrl.ranges"
  ng-if="$ctrl.checkIfTimeSlotIsEnabledIsAvailableAndIsWithinRange( range )"
>
  { range.start } — { range.end }
</div>

function checkIfTimeSlotIsEnabledIsAvailableAndIsWithinRange( range ) {

  if ( range.status === 'unavailable' ) return false;
  if ( !range.enabled ) return false;

  var
    now = moment();

  if ( now.isBefore( range.start ) ) return false;
  if ( now.isAfter( range.end ) ) return false;
}

This name is too verbose (5 major parts of speech, by a conservative count). The best way to figure out a new name is to figure out how the result of the function is used, rather than what it does. Since this function is used to determine whether a range should be shown, shouldRangeBeShown is a good candidate for its name.

Master What You Hate

Sun, 22 May 2016 00:00:00 +0000

I used to hate ironing clothes and merge conflicts, until I got pretty good at ironing clothes and merge conflicts. Some chores are just unfortunate realities of life, or I’m just too proud to outsource them. I can’t bring myself to pay someone to do my cleaning for me, so my near future has a lot of laundry and vacuuming coming up. The best way I found to stop dreading these things is to get as good at them as possible.

One of two things will happen. Either you get good enough at the task to make it fun, or you’ll get fast enough to not notice the pain.

So do your homework. Look it up on YouTube, RTFM, ask a friend, read a book. Buy the right tools for the job. Practice, practice, practice! Be happier and more productive. You always have the option of avoiding the task like the plague down the line.

Thumbs Test

Sat, 09 Apr 2016 00:00:00 +0000

There’s a test I like to do with new co-op students to get context for how much they actually know. I call it the “thumbs” test, and I explain it like this:

Before we start, I just want to get some context for how much experience you have. This is not a quiz, I only want to get an idea for which aspects of development you’re comfortable with. I’m sorry in advance if any of this is patronizing, I only mean to get a feel for your skill set, please bear with me.

I’m going to start listing programming concepts, and for each one, I want you to give me a thumbs-up, a thumbs-down or anything in between.

A thumbs-up means “I know what this is, I am comfortable with it, I’ve used it and I can use it again”. A thumbs-to-the-side means “I’ve heard of this, maybe I’ve used it. I would have to look up some API documentation, call a friend, or check Stack Overflow to work with it.” A thumbs-down means: “I am not sure what that is, or I know what it is, but I’m not familiar with it and might even have a mild phobia of it.”

You can rotate your thumb to the exact level where you feel comfortable. Ready? I’ll start. How about if statements? Functions?

I then start listing concepts in order of increasing complexity, giving them 2-3 seconds on each one to give me a rating. It takes maybe a minute or two, and by the end I always feel like a good context has been established. The actual terms depend on their intended role, but here are some samples:

HTML/CSS: SVG, media queries, flexbox, specificity, BEM, ARIA, Sass/LESS, layout/paint/composite cycle
JavaScript: loops, functions, exceptions, regular expressions, promises, this, the DOM, ES6/ES2015, closures, constructors, event bubbling and capturing, hoisting, prototypal inheritance
HTTP: AJAX, caching and cache busting, CDNs, XSS, CORS, CSRF, websockets
Angular: $scope, controllers, directives, services, dependency injection, $watch, routing, the digest loop, $broadcast, Karma, controllerAs
“engineering”: code smells, DRY, encapsulation, abstraction, time complexity, mutability, separation of concerns, coupling and cohesion
bash: cp, mv, ssh, chmod, chown
git: commit, status, pull/fetch, merge, reset, aliasing, diffing, rebase, bisect, reflog
workflow: dependency management, npm, bower, gulp, transpilation, linting, test runners
Chrome: Chrome Canary, Network Panel, Debugger, Timeline, Workspaces

P.S. It helps to play along for the first few!

Legacy Code

Sat, 23 Jan 2016 00:00:00 +0000

I make the “joke” that any given company is either currently fixing legacy code, or generating it. It’s not a great joke.

Whatever is rightly done, however humble, is noble.

— Henry Royce

Royce was the “Royce” of “Rolls-Royce”. I can’t speak to his nobility, but because he worked on a flour mill and was bone broke for a lot of his life I assume he was forced to be humble for at least some of it. Unlike hubris, laziness, and impatience, humility is not a developer virtue.

Originally, I was going to implore programmers to be humble, and to take on the work that no one else will do because it is wrongly perceived as being boring and painful. I don’t want to convince anyone of that though, because it’s hard and kind of pointless. Instead, I’m going to defend that maintaining legacy code is some of the best work a coder can do. Legacy can and should be valuable, interesting and healthy.

Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.

— Kurt Vonnegut

Greenfield projects used to fill me with a sense of freedom and opportunity, like a half-day Wednesday. These days, instead I have dread of all the utter bullshit work that I’ll definitely have to deal with. In my heart, I know that starting a new project has the following steps:

Schedule a meeting
Fight about framework choice
Fight about the build system
Fight about coding style guides
Fight about everything forever
Wake up in a cold sweat at 5am and dread going to work
Write some code, maybe

Every new project immediately has baggage. Starting something new is hard because we start making all the important decisions ahead of time in the abstract, and this inevitably becomes a series of long meetings about nothing and/or profanities. All we can do it talk at length at how we can keep our non-existent codebase forever young.

Working on old code is chicken soup for the programmer soul, because it’s about programming. All the bike-shedding is done, all the yak-shaving is either done or irrelevant. There are bugs, there are features, and there is refactoring. There is some real honest, modest, humble work.

More importantly, 9/10 times if you’re working on legacy code, you’re fixing something that’s making company X something like Y dollars per Z, instead of wondering if having a digest cycle in your front-end framework is a good idea or not. I personally take solace in knowing that when I put time into a piece of code, the code will make enough money to pay my salary. It’s not such a bad thing to be invested enough in the success of a company to work on something less fun and be useful. I consider “workhorse programmer” a great compliment in an industry of hackers, painters, bespoke code, and so forth.

Also, I’m a cleaner. I clean things, almost perpetually. Refactoring crufty code bring me the same zen satisfaction as cleaning, and I get a lot more happiness mileage in cleaning up something that really needed cleaning than sitting there and trying to figure out how to keep something clean in its pristine condition forever. Put it this way: Sisyphus is a role model.

Lastly and most importantly, legacy is some of the dumbest and therefore hardest, most interesting, and most rewarding coding a programmer has access to. Programmers tend to pride themselves on being problem-solvers and puzzle-solvers and trying to make changes to an old, brittle, and confusing codebase is a seriously hard problem. It’s fiddly, sweaty, painful work that hurts my brain and makes me really work to find a solution.

I consider this to be one of the truest tests of my ability as a programmer, and finding a great solution to a problem under duress of bad architecture is the most satisfaction I get at work. Work like this forces me to really understand a codebase, with all its warts. It makes me learn new patterns, seek novel approaches, and think outside the box. I start to understand why certain architecture decisions are made. Changing old code is fascinating because it’s hard in a way completely different from why writing new code is hard.

Next time you’re looking at 2,000 lines of undocumented JavaScript nested sixteen levels deep, don’t flip a table. Volunteer. It’s a challenge and an opportunity to do some honest-to-goodness programming, the way it should be. Programming was never supposed to be easy, and it’s not. I just prefer my programming to be hard for better reasons, like context, constraints, obfuscation, logic. I’m tired of programming being hard because of arcane trivia, factoids, inconsistencies, unknown unknowns, untenable rate of change, distractions, stress, etc… “Legacy Code” should never have been a bad word, and it deserves better.

Humane Git Aliases

Sun, 23 Aug 2015 00:00:00 +0000

The most common .gitconfig I see is blank except for setting a username. The second most common is this:

[alias]
  ci = commit
  cia = commit -a
  cam = commit --amend
  cama = commit --amend -a

  cl = clean
  cldf = clean -df

  res = reset
  resa = reset HEAD

  ...

  # 82 more 4-character aliases

This config basically trades space in your head for keystrokes. Save on typing by remembering short command aliases. I don’t love that. I make typos, and sometimes I don’t get enough sleep, and generally this is just going to make life harder on me. I shouldn’t be bending to suit the computer’s language, the computer should learn mine. I don’t care so much about having short commands, I have a shell with autocomplete that works. Instead, I use real words and try to make the whole thing more human.

My goals with git aliases are:

smooth out git’s unwieldy UI
make a few common workflows faster

For example, in git, trying to just get a list of something in the repository is insanely inconsistent. I fix it like so:

branches = branch -a
tags = tag
stashes = stash list

How about common operations for undoing work? I never want to Google “how to unstage a file”, there should just be a %$&#ing command to unstage a file.

unstage = reset -q HEAD --
discard = checkout --
uncommit = reset --mixed HEAD~
amend = commit --amend

I even have a nuclear version:

nevermind = !git reset --hard HEAD && git clean -d -f

which unstages changes in the index, discards changes in the working directory, and removes any new files.

I also really like having

graph = log --graph -10 --branches --remotes --tags  --format=format:'%Cgreen%h %Creset• %<(75,trunc)%s (%cN, %cr) %Cred%d' --date-order

to see real timeline of who is working on what and when. Another good example:

precommit = diff --cached --diff-algorithm=minimal -w

This is a key part of my workflow. I run this before every commit to make sure I don’t need to use the undo commands.

Bend the aliases to how you think and work, not the other way around. Let your aliases reflect your values, instead of just saving you keystrokes.

I got a few great suggestions from Reddit comments on this post:

unmerged = diff --name-only --diff-filter=U by kasbah and remotes = remote -v by WrongSubreddit are my favourites. Thank you!

Quantum Entanglement in Plain-ish English

Thu, 05 Feb 2015 00:00:00 +0000

This morning I was challenged to explain quantum entanglement. Normally I’d blow this off, but I’m sick and unemployed and this is interesting, so I’m taking it on. Quantum Mechanics is a really interesting field and it has the fun property of sounding really intense and magical. If I wave away even a bit of the voodoo, I’ll feel good about it.

Working From Last Principles

Where did we get that (equation) from? Nowhere. It is not possible to derive it from anything you know. It came out of the mind of Schrödinger.

— Richard Feynman

If you want a great rockstar scientist story, here you go. Schrödinger was a scientist who came up with the fundamental equation for how we describe particles while ostensibly cheating on his wife at some chalet. This equation is what we’ve used to understand quantum mechanics as a whole, and it requires some background. Let’s work by analogy.

Imagine you’re Newton. You want to figure out the relationship between an object’s mass and its velocity as it falls. You’d probably get a bunch of objects of known mass, drop them from a known height a few thousand times, and then chart the results. You’d find that all the graphs look very similar and they follow some sort of pattern. Once you see the pattern you can figure out what law it follows and express it as an equation. The equation will have some variables and some constants. You might see that the speed doubles as the mass doubles (spoiler: it doesn’t). You might see that the speed is always 9.81 times the mass. Your equation has to have a mass variable, and a constant of 9.81 in it, then. If you have a constant that doesn’t have a name yet, you give it a name. So far so good. Working from first principles!

Okay, now imagine you’re measuring something really complicated. The graphs look really complex and have many, many dependencies. You work really hard and figure out that there is a pattern, though! Your formalized equation has like twelve different constants and another dozen variables. Still workable.

Now, imagine that instead of an equation that gives you a number it’s an equation that gives you another equation. Say you want to find the speed of a particle, but the only equation you know doesn’t give you the speed, it just gives you another equation that you have to solve to get the actual speed. So, it’s a two-step process. Okay.

For the final trick, imagine you’re working in reverse. Imagine that someone out there gives you this wacky-looking equation that you solve to get more equations and that equation gives you some numbers. You don’t know what the fuck the numbers are at all, but they’re something and now we need to work in reverse and run experiments to figure out what in the hell is happening, even. Welcome to quantum mechanics!

Erwin Schrödinger came up with the wave equation. The wave equation describes something about a particle. We’re unraveling it and starting to learn what all the constants and the variables are. We’re running experiments to verify our findings. Slowly, we’re figuring out what it all means. Most importantly, though, we’re learning that this magical equation is right.

We have Schrödinger’s equation. When we solve it for a particle we get another equation that describes the particle. This is called the particle’s wavefunction. The wavefunction has some variables and some constants in it, and even though we might not be 100% sure of how exactly they work, we are making conclusions. We started with math. We looked at the equations and we saw that if the equations are right, this has consequences for how the world works. We ran experiments and found out that those consequences are real.

Unraveling The Wavefunction

So, what did we learn from this equation?

Energy is quantized. Let’s think about that by analogy again. A piece of metal looks like it’s continuous. We can cut it in half and then again and again into smaller and smaller pieces and we’ll just have metal, right? Well no, because it’s made of atoms. An atom is a single, discrete thing. You can point to it using a microscope. A chunk of metal is not actually continuous, it’s made of blocks, units. Energy, turns out, is the same. An electron can’t have any arbitrary amount of energy. Its energy can only be one of a set of possible energies, a quanta. That’s what quantum means, that energy is not continuous, but discrete. Experiments confirm this a thousand times over.
You cannot solve for the momentum and the position of a particle at the same time. Due to the way the math works, you can only know one with certainty, and never both. This is Heisenberg’s Spooky Uncertainty Principle you might have heard about. You can’t know both where a particle is and where it’s going at the same time.
Some variables can only be determined when others are determined first. You know the whole dead cat in a box experiment? There is an intermediate step in wavefunction solving in which you’re presented with a set of possible partial solutions and all of them are equally likely. You then proceed with solving and arrive at the Right One. If you like thought experiments you might say that a particle exists in all of those states at the same time, and solving for the right state forces (or collapses, as it were) it into onto a single one. You might even say that measuring the particle affects the particle. To me, this smells like warping the English language to sensationalize a mathematical concept, but whatever.
In some systems, the wave functions of the particles depend on each other. So far we’ve been talking about a single particle, but what if you have a bunch all in the same place? You start trying to solve for the wavefunctions of them all and you see that they all depend on each other. For example, imagine you’re trying to solve for particles A and B which are in the same system. You might learn from the equations that if particle A has the property X = -1, by definition particle B has to have property X = +1. The equations depend on each other in a very specific way. If you solve X for A, you’ll get the answer for B. That’s basically the idea of quantum entanglement. The particles are dependent and are therefore “entangled”. Sensational!

Implications

What are the implications of this, then? Here is the basic premise of what we’ve talked about:

when we try to solve for two particles at once, the solutions are mutually-dependent
whenever we’re solving for a particle we choose a single correct solution out of a set

So. We take two particles that we’re solving for and move them across a room from each other. We solve for A. We learn something about B. Cool. What if they’re across the whole universe from each other? We solve for A, and we learn something about B. Except … B is a million light-years away. We just got information about something infinitely far and we did it infinitely fast. Did information about this particle just travel to us faster than light?

Einstein called this “spooky action at a distance.”

Here’s the thing though: We didn’t actually transmit anything. We can’t change properties of particle A to change the properties of particle B in a useful way. If we change particle A and solve the equations again, as you remember, the answer we get is random from a set of potential answers. The information at B, then, is also random. We’re “transmitting” noise at this point, with no actual influence from us. This is all at the thought experiment stage, too, there is a whole set of other physical complications that make the whole thing really difficult.

This phenomenon, while cool, is not actionable.

References

Michio Kaku: Why Einstein Gets the Last Laugh

Recursively-Cleaning Parameters

Sat, 03 Jan 2015 00:00:00 +0000

One of the best ways I know to learn idiomatic patterns for programming is to read the source of libraries written by people who know what they’re doing. I do this every now and again and go spelunking for tips. I spotted this in page.js:

function page(path, fn) {
  // <callback>
  if ('function' === typeof path) {
    return page('*', path);
  }

As in, if instead of a path and a callback the function is passed a callback and nothing else, we assume they meant to use the * path with the callback they passed. The function arranges the arguments into the right order, and calls itself. I call this pattern recursively-cleaning parameters.

Sitenote: this is friendly API design. It’s effectively overloading a function, which isn’t supported natively in JavaScript.

That example could have just as easily looked like this:

function page(path, fn) {
  // <callback>
  if ('function' === typeof path) {
    fn = path;
    path = '*';
  }

which is a lot less tidy. Plus, if the function accepted more parameters, it would just get dirtier and dirtier from there. Cool!

Code Hierarchy of Needs

Tue, 02 Dec 2014 00:00:00 +0000

Physiological: the code compiles, runs successfully, and fulfills its purpose on specified platforms. No one has bothered to even ask about bugs yet.

Safety: the problem solved by the code is worth something to someone, or the code is otherwise of enough interest to be kept around. Someone might have checked it into a repository somewhere or copied it to a USB key labelled “Tim”. So far no one has thrown their computer out of a window while using it.

Belonging: someone out there maybe even actually uses the code and maybe even likes it. Maybe it has an API that makes it possible to integrate it into something else. It’s sufficiently good that its competitors are not obviously better.

Esteem: the code is written to a high standard, with care for style, conventions, performance, maintainability, etc. Someone looking at the code would groan only once, maybe twice.

Self-Actualization: the code transcends its own purpose, carrying enough impact to influence the context in which it exists. Someone on some website has talked about the code in a positive light.

Bizarre, Crazy, Bad Stupid Ideas For a Social Network

Thu, 09 Oct 2014 00:00:00 +0000

I just woke up one morning and was filled with all these insane ideas for an online social networking website. I’m surrounded by people pissed off by the lack of innovation in social media, and the lack of safe and interesting spaces online. I seriously doubt any of this will solve anything, but I’ve never seen any of this implemented, so I thought it worth sharing. I don’t want to call it a social network though, I’m just going to call it “this thing”.

Generally

I don’t think this thing needs many features to be fun. I’m rooting for just three:

topic-based chat rooms
tinkery profile pages
community projects

That’s it. So the plan is this: the whole “website” is basically just a set of these chat rooms, filled with people who have profile pages who chat and joke and laugh and cry and think and collaborate elsewhere and just generally hang out and have a good time. The point is to set up some wacky features to see if we can make that whole process nicer and maybe even safer and hopefully just more fun.

No Usernames Ever

There will be no usernames. There will be no usernames anywhere. All you get is a person’s face (if you’re nice, maybe a clip of a person’s face) and that’s all. Even if you get a link to their profile, that link won’t have their username on it. More on this later.

Invite-Only Profiles

Did I say later? I meant right now. A person’s profile is only accessible to approved people. Did you have a fun time talking to someone, and want to be able to find them again? Well, you’ll have to click their face, and ask. If they approve you, you’ll get a link to their profile, but here’s the kicker: that link only works for you. That is a link that represents your connection to them, which they can cut at any point. It’ll be useless to any other person.

Why bother? I don’t know, to make it more private, more personal? To force people to step out of their comfort zone a little, to make it a little more like real life, I suppose.

Online-Only Profiles

What about this idea: a person’s profile is only filled with content if they’re actually online. If they’re at work right now, and don’t have the site open, you get nothing. Maybe you get a photo of them, if they decided to put that on their page. Nothing else is even visible. Why? I don’t know, honestly, it just feels like it could be an interesting twist. I want to encourage people to very frequently update their profile with whatever they’re feeling or listening to. Fluid personality, you know?

Nonsense Profile Content

What would even be on a person’s profile page? I think the most fun thing would be some kind of franken-profile filled with just random junk and links and bling and stickers and God knows what else. No stream-of-information à la Twitter or Facebook. Just their current state. That page should be the equivalent of taking a glance at a person to see what they’re wearing, how they feel and what they’re listening to. Here are the only reasons to open a person’s profile:

they told you to, because they put something funny there
you’re curious what they’re listening to, or how they’re feeling
privately message them

I want to bring back the GeoCities mentality and just let people go nuts. If it’s done right, people are screwing up their profile every three days.

No Passwords

No username, and no password. You just provide an email address, and get emailed a login link every time, kind of like resetting your password. The Magazine did this, and it worked really well. Plus, this makes it super easy for people to supply fake emails, anonymous emails, temporary emails, whatever. It would barely store any user information anyway, who cares?

Face-Space Chat Rooms

I love Meatspace, so given the choice, I think the chat rooms should be Meatspace rooms. Because it’s fun, because it works and because it’s interesting and follows the whole no-usernames idea. Every chat message you send appends just a picture or a short clip of your face to it, and that’s your identity.

No Global Room List

There is no global list of chat rooms to peruse. Interested in something? I suggest finding another person or two with the same interest, and just breaking off into a new room. The room list is fluid, of course, and new rooms can be created arbitrarily.

If you think that interest already exists, you have to search for a room by keyword and see if anything pops up for you to join. This is clearly a terrible idea, but having no global list to start with just puts everyone in the same pool, and the interests branch off organically, which is neat. Plus I like the idea of being bored one day, searching for “butts” on the site to see if that’s a room that exists already.

Peeking

There is a need for private rooms, I find this more or less obvious. What would be cool though is if the rooms were (optionally, of course) peekable. Let’s say you get curious and search for a room called “butts”, and whoa it exists, but it’s locked. Well that’s weird, but hey, the people in the room let you peek in. You can press a button and get a truncated little text-only feed of what’s going on, just to see if it’s your cup of tea. That’s a dumb idea for sure, right, but hey, it’s kinda cute.

Knocking

This idea feels less dumb. What if you can knock on private rooms? You find a room, but the people inside are a little bit protective of it. What if you could just “knock” on a room, and everyone inside gets a little alert that your smug mug is curious to come in and check it out. If someone inside knows you, they can just open the door and let you in, just like that. That’d be kinda cool, right? Hell of a lot better than just begging people for passwords. Or maybe not better, I don’t know, I’m not a social scientist.

Distribution

What if you can host chat rooms on your own server and somehow link them to the main site? That way, some rooms can be controlled by a non-central body, which means they can have their own rules, their own bots, their own logging policies, their own hosting fees and fundraising, etc. Let’s internet like it’s 2014. Maybe one room is only pictures and no text. One room maybe runs everything through revisit.link, the sky’s the limit.

Disposability and Ephemerality

I like ephemeral things. Chat rooms that lose the scrollback remove the pressure a little bit. I like disposability, too. Profiles that are easy and fast to edit encourage experimentation and remove that crappy “how do I describe myself” anxiety. I like when things have an expiration date, because that way people don’t get invested in the specifics.

Community Project Hosting

I just get this hunch that people, generally, like being creative and collaborative. A kooky ridiculous social network like this one should have mods who love and respect that fact, and there should be a whole section of the site dedicated just to hosting community projects. The mods and the founders should be hands-on. Support the people! Show off their work! It’ll be fun, probably!

Non-Scalability

This won’t scale at all but the good news is that this thing is so stupidly niche, it will never be a successful business. Ever. That means it’ll be up to the community to rustle up the money to keep the servers hot, and put in the time to keep the codebase clean and moderate the whole affair. What a nightmare scenario that is. That’s a stupid idea for sure. I’d get laughed out of YC in 20 seconds flat.

Fin

These ideas are terrible. No one would go for this. I hope someone makes it, though.