Javascript is the Right Flavor of Bad

People are often very hard on Javascript. They make fun of it in “Wat” videos, its community produces a 23 new frameworks every nanosecond, and it’s a common target of criticism among people looking for a dynamically typed language to ridicule.

Yet Javascript is one of my favorite languages to work in, and I think I’ve figured out why: it’s just the right flavor of bad.

Some traditionally bad languages out there (*cough* PHP) are bad deep in their core, buried under layers of pull request makeup and major release plastic surgeries.

It’s a subtle pain. Like stealing socks from your dryer, or unscrewing the lid on your soda bottles while you’re out of the house so that the carbon dioxide escapes and the flavor changes and becomes too sweet and you’re forced to acknowledge that you had planned to drink a bottle entirely filled with corn syrup all along.

It’s a slow burn, a thousand papercuts you can’t put your finger on, and eventually you resign yourself to the pain. You get diabetes from all the soda you’re no longer ashamed to admit to drinking and you’re permanently forced to walk only in smelly circles because you only have one sock left and you’re too afraid to wash it.

But Javascript is different. When it’s bad, it’s a sharp pain, with no attempt to disguise it. It’s like having your cat jump up on your desk and then vomit on it.

It’s clearly, openly, unapologetically rude, and yet the cat just stares innocently, unblinking back at you. As though it just happened to notice your eye contact and is now waiting for you to comment on the weather. Why shouldn’t it throw up on your desk? This looked like a good spot. Why shouldn’t the result of adding two arrays be empty string? It seemed like a good return value.

So you yell at the cat in English, vainly expecting it to understand you in Cat (hint: it does, that’s why it ran away.) Then you clean it up, and the problem is gone. No slow burn. Just something so stupid you can’t believe it happened, with a clear and direct, easily Google-able solution which you quickly apply and then move on with your life.

Javascript is cat puke.

Most of the time it works exactly as you expect, doing cat things and turning strings which contain numbers into 64-bit floats so you can math with them, converting the same numbers into 32-bit integers so you can bitwise operate with them, then converting them back into 64-bit floats so you only have to remember 20 powers of two while working with Javascript numbers.

The good and bad parts of the language are very clear and obvious, which is why it’s possible to learn how to work around them within the lifetime of a mortal. Then you just get the Good Bits of Javascript, and you’re able to enjoy working with it.


Javascript, the Good Parts

And then one day you discover Typescript and you elope together and live happily ever after.

Learn to Build Bridges in Only a Day!

So I’ve been reading the Joel on Software blog pretty religiously lately, and I’ve decided that part of his success was that most of his blog posts were so short he could probably do them in one sitting. I’ve been trying to blog more, and I think that short, hastily edited blog posts facilitate getting into the habit of writing more, which is a skill I want to keep sharp. So expect more, lower quality content from me from now on!

Everyone should learn to code!!!one1

Something that seems to keep coming up on the programming subreddit and Hacker News lately is the popular movement to teach programming as a skill to everyone. This is generally the point where the career programmers crawl up into their tree fort and pull up the ladder prior to sneering at the optimistic newbies who think that they can learn to code in a day! What fools! How gloriously they shall fail! Come, brothers, and let us await the schadenfreude and “I can haz teh code?” questions on Stack Overflow! Guffaw!

The biggest aspect of this movement that rubs programmers the wrong way, I think, is the fact that these campaigns seem to target themselves specifically at people who understand very little about computers in general, and conveys misinformation to the people who are already least informed. Sometimes they do this because the media networks themselves know nothing about programming, and other times this is done to take advantage of people by offering them $99 one-month online courses in how to get rich in the computer industry.

The following video was probably the most egregious example of the ignorant media. They don’t even manage to make it through the first minute of what purports to be objective coverage of the Year of Code movement without describing the code as “baffling” and “gobbledygook.” It gets better when one of the directors of the program admits to not knowing how to code immediately before making broad assertions about the role of programming in our modern world.

So the career programmers are probably understandably miffed at these sorts of descriptions of their profession, combined with the suggestion that anyone can do it without much effort and that “you can build a website in an hour!”

When your livelihood is based on using over a decade of ongoing education and experience to charge $100/hour to build websites, a task which normally takes you between days and weeks, ignorant assertions like that are both insulting and have the potential to deter prospective customers.

“If it’s that easy, I’ll just do it myself!” the potential customer scoffs, before teaching himself PHP and building a website that exposes his database to SQL injection attacks, lacks even the most basic of usability features, is unusable on mobile devices, and errors frequently (but he’ll never know because he doesn’t even have logging to tell him of the terrible experience his prospective customers are having!)



But on the other hand, some programmers welcome the idea of our profession gaining more mainstream appeal. We work hard and care about what we do for a living, so seeing our friends’ eyes glaze over whenever we talk about what we’re passionate about can be frustrating.

Furthermore, with most employers complaining about having difficulty finding good programmers on the market, we could do with having more talented people entering the field from all walks of life.

If nothing else, it would be nice to get rid of the gut-wrenchingly naïve way that programming is portrayed in popular television.

“It’s a military grade encryption!” – writers of Arrow. Hate to break it to you guys, but that code doesn’t even compile.


That scene is essentially the programmer equivalent of a plumber announcing to a room full of contractors that he’s going to “Use a wrench to check the valves to see if there’s some sort of aquatic discharge” before rushing off, clearly in a hurry to get to work before his buzzwords get cold.


Ultimately I think it comes down to educating people and setting realistic expectations. I really believe that people can learn useful programming skills in a limited amount of time. I also believe that coding is an excellent way of helping people to hone their analytical, logical, and problem-solving skills.

Let me put it this way: I’m not a carpenter. I’ll never be a carpenter, and if a genie suddenly appeared and offered to give me the skills of a carpenter, my reaction would be an unenthusiastic “Meh, why not?” or perhaps “Genies aren’t real. Where’s the projector and fog machine?”

Yet I own a tool set, and an electric drill. I used these just the other day to assemble a liquor cabinet for myself and to mount some surround sound speakers on the wall of my living room. But I would not attempt to build a bridge.

People already understand the difference between someone who owns a drill, and someone who makes a living doing carpentry. They also understand the difference between someone who does carpentry as a contractor for a living, and someone who has spent 60 hours per week for most of their life working with wood because it is both their passion and their profession.

Chinese artist Zheng Chunhui’s world record breaking 40-foot long wooden sculpture.

This, I think, is the key distinction that is often lacking when teaching people about programming. Hobbyist, professional, and artisan are all different levels of skill in the same discipline. But many of the most common tasks people need computers to perform are also ones that can be achieved by a hobbyist programmer. Tweaking the CSS on a wordpress blog, automating some simple paperwork task the office, or simply being able to identify which tasks might be automated so that one can make better suggestions to the creators of software.

Thanks, XKCD!

Thanks, XKCD!

Conveying the appropriate expectations to those learning to code and teaching useful basics to a wide audience of people is a Good Thing. But misleading people into thinking that difficult tasks are easy will hurt more than help. People should expect to learn to create simple applications to perform tasks that are both simple and useful.

They should also be told that given what they already know, expanding their knowledge of programming to include new things they’re interested in accomplishing with their skillset is much easier once they know some basics.

They should not be led to believe that they can quickly slap together a fully-featured, multithreaded, asynchronous, peer-to-peer file sharing system on a Saturday afternoon. Nor should they be led to believe that their programmer friend’s work as a computer security expert for an online financing company is actually pretty basic, but she’s just really really bad at explaining it.

Conveying realistic expectations of what these sorts of introduction to programming courses can and can’t achieve is imperative to their success, and so far we’re failing pretty miserably at that task.

3 Ways to Avoid Being Burned by State

If I were to ask you to tell me what the return value of x were after the following lines of C# code executed – could you?

var y = 5;
var x = example.Foo(y);

You’d probably ask me to see the implementation of Foo before feeling comfortable guessing the behavior of the method. So let’s take a look at Foo’s contents:

public int Foo(int num){
  return num + this.z;

Now could you tell me the value of x? Nope, not until runtime, because you don’t know the state of example.z. Depending on state, particularly mutable state, is one of the most common ways to build complexity into your code. The result of a single line of code that depends on state could potentially be affected by every line of code that has executed before it which modifies our program’s state. This increases our program’s complexity exponentially.

So let’s take a look at 3 simple techniques for avoiding state in our code.

Write Functions and Methods as Pure Functions.

Let us contrast the previous implementation of Foo with a new one which will allow us to achieve the same thing:

public int Foo(int num1, int num2){
  return num1 + num2;

And then invoke it like so:

var y = 5;
var z = 10;
var x = example.Foo(y, z);

Now you can tell me exactly what x will be after Foo executes, at compile time. This is because we no longer depend on the internal state of the object example. We have created a pure function, which is one of the most powerful ways of avoiding being burned by state. Pure functions have two properties:

  1. The function always returns the same result when invoked with the same arguments.
  2. The function has no side effects. None of our program’s internal state is modified by invoking the function. (until we store its return value.)

Because they are explicit about the state they depend on (the function’s arguments) and because they do not mutate any of the program’s state, they reduce the complexity of our code tremendously.

We can compose an arbitrarily complex series of calls into pure functions, and if we know the state of the inputs to those functions, we can prove what the output will be with 100% accuracy. This is the great power of functional languages, however it is important to note that one can program in a functional way and reap the benefits of pure functions in nearly any modern language.

Sometimes however, we need state. After all, sometimes we want to store data somewhere and retrieve it later. Databases, File I/O, DTOs, and Caching are all great examples of this. We can’t get away from state entirely and still be able to do anything useful.

So let us look at another way we can avoid being burned by state:

Make Stateful Data Structures Immutable

We can relax the first property of a pure function when needed (depending on outside state), while still enforcing the second property (not mutating data). With this in mind, let’s take a look at one possible implementation of our example object’s constructor:

public class Example
  public int z;
  public Example(int zValue)
    z = zValue;
  public int Foo(int input)
    return input + this.z;
  // Other object methods here

Now let’s use this new implementation of Example to accomplish the same task we did before:

var example = new Example(10);
var y = 5;
var x = example.Foo(y);

By looking at this code, can you be certain the value of x without running it? It’s true that we could inspect the ModifyZ method to see whether and how it mutates Example.z – but there is a better option. What if we made z immutable? Then we could be certain that z would always have the value assigned during the constructor of Example:

public class Example
  public readonly int z;
  public Example(int zValue)
    z = zValue;

Now let’s take another look at the same code snippet above:

var example = new Example(10);
var y = 5;
var x = example.Foo(y);

This time, because we know that z is immutable, we can be certain without executing this code that x will be 15 after these lines execute. The behavior of the ModifyZ method no longer has the ability to affect the state we depend on because z is immutable.

But what can we do if we can’t make some of our state immutable? A database, cache, or file system are all designed to be modified and accessed from many different locations in code.

Make Dependency on Mutable State Explicit.

In the last section, we looked at what would happen if we relaxed the first property of mutable functions while still enforcing the second. Now let’s look at how we can benefit from relaxing the second property while still enforcing the first. Let us assume that our Example class contains a DTO parameter which is an arbitrary struct. Below is a possible implementation of the Bar method on our Example object:

public void Bar(int input)
  this.fileStream.WriteLine(input + this.DTO.z);

We write a single line to the file, containing the sum of the function’s input and the z parameter of the Example object’s DTO. Now let’s use this new Bar method:

var example = new Example(10);
var y = 5;

Looking at this code, we have no way to be sure what will be written to the file without examining the contents of the ModifyDTO method. But let’s look at another way we might implement the Bar method to achieve the same thing:

public void Bar(int num1, DTO data)
  this.fileStream.WriteLine(num1 + data.z);

And let us assume that the implementation of our DTO struct was as follows:

public struct DTO
  public int z;

And the following sample code:

var example = new Example();
DTO data;
data.z = 10;
var y = 5;
example.Bar(y, data);

Now we can be certain what will be written to the file because we can easily follow the DTO struct throughout its entire lifetime within our function. Even though its state is mutable, we can limit the code which might modify its state to code which has a reference to it.

By using functions that have no external dependencies outside of the function arguments, we make our dependencies explicit at the time the function is invoked, which makes debugging much easier. And by ensuring that objects like the above DTO which have mutable state do not give out persistent references to themselves, we can drastically reduce the scope of code capable of modifying them.

A good way of identifying candidates for these sorts of changes are methods that either have a void return value, or accept no arguments. Methods with no return value have no reason to be invoked except for their side effects. Methods with no arguments either do something extremely trivial, or depend internally on state in order to accomplish something useful. Every time you find yourself writing a void function, or a function with no arguments, consider whether it might be better implemented in a less stateful way.

The more we reduce our dependence on state, the more we untangle the complexity in our code. Often times widespread dependence on mutable state introduces a lot of complexity and uncertainty into code which could easily be rewritten to avoid most or all of its state. Avoiding state where possible, and using it in deliberate and careful ways when it is needed, are excellent ways to write much more maintainable code!

Troubleshooting Steam Matchmaking Servers for Dummies

So I recently spent several hours troubleshooting my Space Engineers server, and learned a lot about how Steam does matchmaking while I was at it. I figured I’d make a blog post to share and hopefully save others some time.

First let’s take a look at some pretty pictures that describe how the Steam Matchmaking service works in terms of hosting and joining a game server:




It’s not too complex of a process conceptually, but our computers are doing a lot of work in the background to make it happen. So how can we be sure that we’ve set them up properly so that they can do their job?

Reference: Steam server port information from Valve:

Let’s start from the beginning with items 1 and 2 from the diagram above:

Can our server identify itself to Steam?

To be sure that this is working, start the Local/Console server and read what pops up in the console window. It should tell us near the bottom that it connected to Steam.


If this fails, then we need to ask ourselves the question: why can my dedicated server not send information out to the Steam servers?

We’ll need an internet connection on the machine hosting the server, and our firewall configured properly to allow outbound traffic on the Steam ports in the link above. If you think a firewall may be the problem, turn it off entirely and try to start the game server again.

If it can connect with no firewall running, then turn your firewall back on and do some Google searching to find out how to configure outbound traffic on your firewall software for the Steam ports in the link above.

Can Steam tell a player about any game server?

This will cover items 3 and 4 in the above diagram.

The player needs to be able to talk to Steam to ask about the server. This means they will need an internet connection and no pesky firewalls getting in their way. If you fire up your game and can see other people’s hosted games, then this part is working. If not, then your problem is that the game client can’t talk to the Steam matchmaking servers.

Check the internet connection

Can Steam tell a player about MY game server?

This is the part that burned me. This refers to items 5 and 6 in the diagram. To understand this, you need to know a little about networking. Routers and firewalls are very generous when allowing traffic from a computer to go elsewhere, AND when allowing responses back from the server you just contacted. They assume the connection is a response to a request you just made and allow it through.

However when another server tries to connect to your router/server without you having made a request from them first, by default your router and firewall will treat the unsolicited connection like an intruder: denied!

To check if this is the problem, use the Steam Server Browser built into the Steam client to see if you can connect to your server and find information about the game. If not, then Steam won’t be able to tell Space Engineers players about your game either. In the Steam client go to View > Servers, then select Favorites, “Add a Server” and enter your server’s IP/domain name and optionally port. Then click “Find games at this address…”

For people hosting their servers at home, go here ( to find your public IP. This will be different from your computer’s IP address if you use a router. Routers set up a local network for you and give out local IP addresses to the computers on them.

If your server is communicating with Steam correctly, you should see information about your games:


So if you want Steam to be able to make an unsolicited connection to your server to scan the 30 Steam matchmaking ports, and then tell players what it found, your router and firewall need to allow inbound traffic on ports 27000 – 27030 (or possibly just the one port you’re actually hosting the game on.)

How to do this will vary based on your setup, but routers will need port forwarding turned on, allowing unsolicited connections to your router on the game’s port to be forwarded to your computer instead of rejected. If you host your own web server, routers won’t be a concern, but both public web servers and home computers will need their firewall to allow inbound connections on the Steam ports for this to work. A Google search for your router/firewall should teach you how to do this.

Items 7-9 should work well if you’ve gotten this far. Your client can talk to Steam, your server can talk to Steam, and Steam can scan ports on your server. All that’s left is Steam Groups!

Is the player allowed to join based on their Steam Group ID?

To find out your Steam Group ID, use this link, but put your Steam group name in the URL. The ugly XML you see will include the group’s full ID near the top of the page. here]/memberslistxml/?xml=1

Once you have your Steam group ID, you can add it to your server information:


0 will allow all connections. If you change the group ID field to something other than 0, then only Steam players in the designated group will be allowed to join. To test this, the Space Engineers game client can show us a list that is not filtered to exclude games which won’t allow you to join based on your group. Simply unckeck the ‘Allowed Groups’ box to see the full list of all servers:


And that’s about all I know about Steam matchmaking and troubleshooting Space Engineers dedicated servers. I hope this helps some folks out there!

Legacy Code Explained for Non-Programmers

You do not truly understand something unless you can explain it to your grandmother.

– Albert Einstein

I often get asked by non-programmers what legacy code is. I’ve heard many programmers try to answer this question over the years, and have yet to hear a good explanation that a layperson could be easily expected to grasp (and haven’t yet delivered one myself, either.)

However I think Einstein was right when he said the quote above. In order to truly understand anything, regardless how complex it is, you need to be able to draw parallels between a complex system and something simpler and easier to picture in your mind.

In software development, we call this an abstraction. It’s essentially the way you understand what a car is. Cars are extremely complex, with thousands of parts and many makes and models. But because we have a simple and broad understanding of what a car is, anyone can quickly identify whether something is a car or not, all without needing to pop the hood and understand its inner workings.

So in order to further solidify my own understanding of how maintaining code, especially the dreaded legacy code works – I have set myself the task of explaining it in the simplest terms I can.

Legacy code is basically old code that is no longer well understood (and indeed, may never have been.) Yet such code often runs many of the oldest and most important software systems in the world. The more important code is, the less likely we are to change it, and the easier it is to let things stay in a bad state simply because they’re working. 

You probably don’t want your bank to change the code that keeps track of how much money you have unless there’s a dire need. If it ain’t broke – don’t fix it.

I think the best analogy I can give for being asked to maintain a code base is that it is like being asked to edit a novel series. (Choose your favorite here, Game of Thrones, Harry Potter, etc.)

There are enough books that you cannot easily read them all every time you have to make a change, so you’ll often rely on your memory of the last time you read it. Some changes may seem fairly straightforward: rename a character. Let’s say you want to change Eddard Stark’s name to William Stark. This sounds simple enough, simply use a text editor to find and replace Eddard with William.

This works great, but what if there were two characters named Eddard? Now we have a problem. We’ll need to find each place the name Eddard is used, then read the paragraph around it and understand it so we know which character’s name we’re changing. And if we make a mistake, calling one character by another’s name can be very confusing for the reader.

So we can see that even the simplest of changes may require us to have at least a basic understanding of the book near where we make changes. But that can’t be too error prone, so where do bugs come from?

Well let’s assume we want to make a change that’s more complex: let’s say we want to rewrite the series so that the winners of a battle are instead the losers. This can have serious implications for the characters and groups in the book, and we can’t just search for a character’s name to find all the places affected – this will require plot changes.

So we’ll need to understand what areas of each book are ones that would be affected by the outcome of that battle. Future battles may never have happened, different characters may have died or survived. This will have an impact on how we want the plot to go in many future chapters.

This is a pretty big task. If we are intimately familiar with the books, we can speed the process up, but if the book series is large or if we’re new at our job and haven’t read them all, this may necessitate a whole lot of reading simply so we know what changes to make. Many chapters may have to be read just so we know how to rewrite a single paragraph. In a large series, we may have so many changes to make that we have two people working on it – they may even accidentally contradict one another.

So this is all pretty standard practice for authors, they work slowly and deliberately, and have editors to help them, and manage to get books together without too many glaring errors (at least after all the grammatical and plot errors are found, and the editing and rewrites are done. In the software world those are called ‘bugs.’)

Why can’t software developers just do the same thing?

This is where Legacy Code comes in: let’s assume the plot weren’t so straightforward. Let’s say our book is about time travel, and the actions of one character in the past could have many implications for many characters in many places at any point in the future.

If a character overthrows an evil government 100 years in the past, we may be looking at a complete rewrite of the rest of the book series, or at least a complete read through of the whole series to be sure we haven’t missed anything.

There’s no longer any convenient ways for us to know what characters and events may be affected by this plot change we’ve made, so the list of things that may have to be checked and changed is essentially “everything.”

But let’s say our publisher wants our book series published by 5pm on Friday (or you and thousands of other users have told the company that publishes the software in question that you really want that bug fixed right away, in no uncertain terms.)

Then maybe we don’t take the time to reread the whole series. Maybe we talk to the guy who knows it best and ask him for a list of every place that may need to be rewritten. After a few hours he comes back to us with the most exhaustive list he can come up with on short notice and says “I think that’s everything.”

A few days later, we’ve rewritten our books, changed everything the guy who knows the series best told us to, and we make our 5pm on Friday deadline. We got everything.

We’re pretty sure we got everything.

We’re kinda sure….

And this, ladies and gentlemen non-programmers, is where bugs come from. This is how legacy code causes them. So how do we make it better? How can we have good code instead of icky legacy code?

Let’s say that instead of our book series, we instead had an anthology of short stories. The stories may share characters, take place in the same world, and occur at some of the same locations.

Because each story is meant to stand alone, there’s only a limited number of ways one story can affect another. Because each story has its own plotline and a small list of characters and locations, it’s easy for one of our editors to remember which are involved in each story.

We could even draw a diagram of which characters and locations are shared between which stories, allowing us to change one story and know immediately how our changes will affect others.

We may even give each story a handy name to help us remember what goes on in it, such as “Critical Bank Account Balance Code.”

So now we’re in a much better spot if we want to make changes. A quick read-through of a single short story will let us know what characters and locations are involved. The title will give us hints to tell us about a story we haven’t read or jog our memory about one that we read several months ago. We can even consult our not-too-complex diagram about the relationships between the stories to understand what impacts a change may have on our series as a whole.

So that’s it then. That’s what programmers are talking about when they use phrases like “legacy code”, “good code”, and where a lot of bugs come from. Basically programmers complaining about legacy code are complaining that the last writer left them a huge novel series with a convoluted plot to edit, and they’re wishing that instead they had a nice series of self-contained short stories to work with.

When they say they want to “refactor” code, they want to take a novel (or a big chunk of code) and turn it into a series of short stories that will be easier to work with and discover errors and plot holes in.

So bear this in mind from now on when you hear your programmer friends throwing around jargon and lamenting things like ‘NullReferenceExceptions’ – we’re just trying to make sure we can keep writing a story that ends with you using some software happily and then going to do something more important, rather than a bad ending where you’re screaming at your computer or a hacker gets your data.

The Dancer’s Code

The Dancer’s Code is a list of reminders I’ve made for myself on how to be a dancer who gives and gets the most out of dancing. All the dancers I know could do a little better with at least one of these things, myself included. But just like with dancing, perfection isn’t the goal. The goal is to strive to be your best.


The Dancer’s Code:

Dancing isn’t just something you do with your feet. It’s a community. When you see someone you don’t know, be an ambassador. Don’t just dance with them – befriend them.

Sharing a dance is generosity. It’s not something anyone is entitled to. When someone dances with you, appreciate it. Likewise, be generous to others with your own dancing.

Dancing is a talent, not a virtue. Being a good dancer doesn’t make someone a good person. That’s something you do off the dance floor.

Dance hates drama. Whenever someone comes up in a conversation, imagine that they’re listening. If that makes you uncomfortable, end the conversation. You have better things to talk about.

We don’t practice to learn how to dance “right.” We do it so that when the music comes on, your partner takes your hand, and you feel a desire to express yourself, your body doesn’t get in the way.

Above all, have fun. Stress has no place on the dance floor. Great music, great people, and the freedom to let your feelings move you. All that’s left is to smile and let it happen. That’s what dance is all about and it’s the thing we have in common that brings us all together.

Moving to

I’ve had a self-hosted WordPress site for many years. But have decided that keeping it up to date and managing the Vm it ran on were not worth it. So I’m moving my blog content to a new home on to make things easier on myself.

Back to top