Month: December 2013

I’ve been thinking a lot about performance this past year. Both on the client side and the server side as well. While it might not come as a surprise, the number one thing you can do to improve performance is to do less.

And this applies to most everything that you can actually do.

Code should do less. The more your code has to do, the longer it’s going to take. Obviously, not all operations in your language are equal, but beneath the covers, the computer has to do more.

But we need to do more

That network call out to Facebook has to do a lot. It has to travel a much larger distance than keeping things local. It has to perform DNS lookups, or it has to wait around for the remote machine to do more stuff.

When that user signs up and you decide to send out that email? That’s doing more. Fetching something from cache that you’ve already got in memory? That’s doing more than you should.

It seems fairly obvious, but at every step, you should seek to do less. And the problem is that while it’s obvious, it’s something we overlook. We forget that every action, every line will add to the cost of running the program. And no, I don’t mean that one line is equal to another. As I said before, it’s what’s happening beneath that really matters.

Of course, you can’t help but do more. After all, first it was just a simple signup. Then you needed to send out an email. You also needed to update the mailing list database on signup. And now you need to run another set of operations for fighting spam.

The Solution to doing more with less

The easiest solution to doing more is to not do more at the time you would normally do it. Push what you need to do off to a later time. Either using a messaging system like RabbitMQ or even later using crons, you can probably find something that will suit your needs. The best part is, if you architect it that way, instead of adding more code to the part where you’d normally add it, you are instead just adding code some place else, listening for that event.

This really emphasizes the Open-Closed principal in SOLID. Open for extension, closed for modification. Every time you find yourself modifying existing code to add a new action on a particular event, ask yourself if you really need to have that action take place at that exact time. Ask yourself if all the other processing should be held up waiting for that action to take place.

I used to have a problem learning new programming languages. It wasn’t that I found the syntax difficult, or that concepts eluded me. Rather, it was the idea of learning an entirely new language a fairly time consuming task. It hasn’t been until recently that I’ve come to accept that my definition of what learning a new programming language means was wrong, or at least poorly thought out.

What learning does not mean

First, let’s clearly define what learning a new language really means. For a long time, I always assumed learning a new language meant understanding the ins-and-outs of the ecosystem surrounding the language. What I mean by this is best explained in an example.

If I said I knew Objective-C, I’d most likely mean I know iOS development. Of course, one can know Objective-C without knowing iOS development, so I’d make sure to write both Objective-C and iOS development down. But when I said I knew Objective-C, it meant I also understood the tooling around it. I understood how to use Xcode, I knew the ecosystem, how to write Podfiles, I understood the various blogs and communities surrounding Objective-C. I would also use Objective-C as the implication that I knew the Cocoa Touch framework (helped along by using iOS development). The idea here is that I knew much more than just Objective-C. And learning all this stuff couldn’t happen in a few weeks.

How people can learn in a few weeks

So, using this as a standard, I always shook my head whenever someone would talk about picking up a new language in a few weeks.

“A good programmer can pick up a new language in a couple week,” was a mantra I never quite agreed with. The problem, however, wasn’t the mantra. It was that we were defining what was being discussed in different ways. A programmer can pick up a language in a short period of time. Especially in an environment where there is support for that language. Take any language you sort-of know, and put yourself in an environment where you are working alongside people you’d consider experts in the field, and you’ll probably agree that you’ll pick up the language fairly quickly.

At the end of those few weeks, you’ll be productive. You won’t be perfect, and you’ll still have much to learn, but than we can use that to describe anyone, really.

What learning a new language means

When looked at through those eyes, learning a new language is really a matter of understanding how to use the language to be productive. It doesn’t mean you understand every nitty gritty trick. Rather, it means you know enough to move forward. You have a foundation in that language.

If asked to write a program in that language, not only could you evaluate whether the language was suited for the program, but you would know where to start.

When looked at in that light, learning a new language becomes a much less daunting task.

How to learn a new programming language quickly

This is the part of my article where I make a bold claim. That claim is “quickly.” However, the idea is sound, and not originally mine.

The quickest way to learn a new language is to implement a program you already know how to build. The classic example for the web is to build a blog. You already know how to build a blog. There is a good chance if you are a web developer, you’ve built one yourself at some point. So, by building a blog in your new language, you are focused on the language, not the problem.

Now, don’t get stuck up on building a blog, as this is just an example. Your program for learning can be anything you want. It can be an IRC bot, a mail client, or your own personal image upload server. It can be a Twitter client as is popular with iOS tutorials, or it could be a game server for tic-tac-toe. The point isn’t the program. Rather, it’s that it’s complex enough to incorporate multiple technologies you’d want to know.

Going back to our blog example, you could say that the blog needs a database, thus ensuring you’ll need to learn how to connect to various databases. You’ll need to learn how to cache those results, so you aren’t connecting to the database when you don’t need to. You’ll need to handle data input, comments, and tempting. You’ll need to understand quite a bit, but it’s not difficult enough that you are caught up with what you are doing. Rather, you are focused on how to do it in the language you want.

A new year

With the new year approaching, I’m sure there will be a lot of people resolving to learn new programming languages. Instead, I’d like to challenge you to change your thinking. Don’t learn a new programming language. Rather, write a program in a new programming language.