JasonLotito

Before I started using this method, I always struggled with ways to highlight parts of code I wanted to talk about when giving presentations. This method, I’ve found, is at once the easiest method to use, and provides context to the viewer. They can easily follow along, and where the code is in relation to other code you are talking about is made apparent.

A picture is worth a thousand words, and this one should show clearly how to highlight lines of code on a slide. You just add two shapes, and set the opacity to such a level that code can still be viewed, but it’s dimmed out.

You can also generate nice transitions between highlights of the same code using Magic Move as your transition.

The result is a fairly simple transition as you highlight specific lines of code.

This works with code that cannot fit on your slide as well. Simple add the code to your slide, and allow it to go beyond the edge of your slide. When you want to highlight code that is partially hidden, simply move the text box up.

Other presentation software can do this using their own similar features.

1. Practice your talk before speaking. Several times. Record yourself. Watch it. At a conference, people paid $$$ for this.
2. Assume wifi is unavailable for your talk. Don’t depend on it to run demos.
3. Assume you’ll get few or no questions. Given a 45 minute slot? Aim for 40 minutes.
4. If you insist on live coding, make sure you’ve written down the code ahead of time. We don’t want to watch you debug in real time.
5. If your talk title says it’s about X, don’t make the first quarter/half not talking about X. We probably came to listen to you talk about X, not your life story. Exceptions exist, but do so carefully.
6. Waiting for audience participation is awkward. “Can anyone see what’s wrong?” Just move on.
7. The best slides are ones that are useful after the talk. You can export with speaker notes! Have speaker notes!
8. Be professional. Know how your computer works. How the presentation software works. Show up ahead of time, make sure tech is ready.
9. Don’t save your talk for a big conference. Run through it at a user group or meetup. Adjust. Improve. Repeat.
10. You can’t please everyone. Present for a target audience. Title and description should aim to entice that target audience.

All too often on Hacker News, I come across a comment like this:

wouldn’t most of them be able to build something like this for internal use in a single day

Yes. Of course, it might only take a day to build, but it will be maintained forever. And that means dealing with potential bugs. That means testing. That means deploying. It means having a way to manage it. A way to scale it up. This means adding features as needed. And of course, still dealing with new bugs. It’s another system, another cog that you have to maintain.

So, next time you need to create a tool like this, stop and think for a moment. Is this built? Does this exist out there? If so, consider using the service. However, if what you need doesn’t exist, than maybe, just maybe, you’ve found yourself a new idea.

Last year I read 37 books. I don’t pretend that this is a high number. I know that there are people that read far more books than that. However, I also know that 37 books is far greater than the majority of other people. Still, it’s important to note that I don’t read all these books sitting down turning pages. Rather, I read the majority of them as audio books from Audible. You might consider that cheating, but I don’t.

I listen to them in my car on my way to and from work. With an hour commute, I get a lot of listening time in. I also take the books with me to lunch. It gives me time to get out of the office and to take a breather. I get to catch up on a good story. It’s a great break in the middle of the day.

I’ll go for walks, and listen to a bit then, or when I’m washing dishes, or doing chores. When others might listen to music, I’ll put on my ear buds and listen to my book.

I don’t read all my books that way. I still love real physical books, and I also enjoy e-books on occasion as well. But if one of your resolutions this year is to read more, I highly recommend audio books.

I’ve thought 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 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 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 sign-up. Then you needed to send out an email. You also needed to update the mailing list database on sign-up. 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 when 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.