Codeulate.

40-Minute Conference Talks Should Die

In the dozens of conferences I’ve attended, I’ve almost never seen a 40-minute talk that wouldn’t have been better with 10 minutes of junk cut out.

Conference organizers think they are doing speakers a favor by giving them ample of time to cover their topic, but I believe this is mistaken. It is far better to give speakers too little time than too much. The first forces them to present the essentials quickly and leaves the audience wanting more. The second makes one worry about filling time. You can guess which leads to better talks.

When I coach speakers, my advice is almost always “get to the point faster, then stay there.” Shorter slots encourage this positive behavior.

If you take this principle to the extreme, you get lightning talks; often only 5 minutes long. These are nearly always a highlight of a conference. Speakers have no time for wandering introductions or apologies, and instead dive immediately into their best stuff. Then, before you have a chance to get bored, they’re forced to wrap up. If you’re interested in learning more, a quick Googling does the trick. This, by the way, is what I think conference talks are best at: providing just enough information to convince you to research something more deeply.

Shorter slots help a speaker focus their material, but they have another benefit: eliminating the colossal challenge of holding an audience’s attention for long periods of time.

In my experience, there are maybe one or two speakers per conference who can keep an audience engaged for 40 minutes. The speakers that can’t are not necessarily bad, they’ve just been giving an incredibly hard task. Consider this: nearly every attendee has a laptop. Speakers are competing against the internet amongst a group that will switch to a browser if their tests take more than 2 seconds to run.

If I were king of the world, I’d make 30 minutes the absolute maximum talk length. New speakers start with 5-minute lightning talks until they prove they can handle more.

As always, there are exceptions to this rule: some speakers can plumb deep topics in entertaining fashion for 40 minutes. But for every speaker I’ve seen who can pull this off, I’ve watched twenty more slowly lose the room to Twitter, Hacker News, and the irresistable appeal of unread emails.

A Short Guide to Landing Your First Rails Job

A short guide to landing your first Rails job.

In order of importance:

1. You will be judged foremost by the quality of your code, so have an app you’re proud to show off. Aim for small classes, short methods, and full test coverage. More generally, make sure the code is the best work you’re capable of. Submitting a code sample and saying “I know this has some problems” is an antipattern.

2. Make friends with at least three other Ruby developers. My first Rails job came to me through the friend of a friend. My second came through an immediate friend. This is how good jobs get filled. You should also ask your Rubyist-friends to critique your sample app.

3. People who are in the market for a programming job should blog every day. Write about what you’ve learned so far. Don’t make the excuse that you’re just a beginner. Imagine someone who is two months behind you and write for them. An active blog shows passion, demonstrates skill, and helps you make more Ruby friends.

4. Distinguish yourself from the applicant pool. Particularly because you lack experience, you need to stand out. Doing so is 95% creativity and 5% effort. Your goal is to make your application more interesting than “somewhat promising but inexperienced Rubyist number 32″. For inspiration, you can read about how I stood out to get my first conference talk accepted.

Simple Rules for New Programmers

Introduction

Hello, and welcome to the programming community! It’s great to have you.

I’d like to offer a few tips that will help you avoid the mistakes made by most new programmers. Following my advice will cause you to do the right thing about 85% of the time, which is a great percentage when you’re getting started. As you gain experience, you’ll learn to spot the other 15%.

The rules

Short methods are vastly superior to long methods.

The ideal method is one line long and takes no arguments. It is an instance method.

Methods that are longer than one line are not as good. Methods that take parameters are not as good. Class methods are also not as good.

During development, it’s fine to add lines to an existing method and bloat it up. Once your code is working, begin extracting one- and two-line methods until everything is svelte again.

As a beginner, your tendency will be to create methods that are too large. Make yours “too small” for a while instead. Pay attention to how it feels to work with them.

Consider an 8-line method to be large, and a 24-line method to be enormous.

Short classes are vastly superior to long classes.

Just as your classes should contain tiny methods, so should your system be built of tiny classes.

Just like methods, you will tend to write classes that are too large. They will do too many things. For now, try to overcompensate in the other direction.

During development, it’s fine to add methods to an existing class and bloat it up. Once your code works, look for a cohesive set of methods to extract into a new, smaller class.

Code that is easy to change is better than code that is not.

The hard part of programming comes when you’ve got everything working correctly but now you want it to work differently.

The best time to evaluate some code you’ve written is when you’re trying to change it three months later. If changing it is easy, congratulations! Celebrate your victory. If not, try to figure out what’s making it hard to change. Then, use refactorings to make your upcoming change easier.

Duplication is the reason that most code is hard to change.

When a codebase has no duplication, changes tend to be localized; only a small portion of your system needs altering. This is ideal because changes that can be made in just one class are easier than those that require changes to many.

Imagine your state’s Senate passes a law that all SaaS companies must now charge sales tax on their subscription fees. If your system has exactly one class that is responsible for calculating these fees, your change will be simple. If the logic for calculating fees is duplicated even once, it becomes more difficult. Imagine you’ve copied `total_subscription_fee = monthly_subscription_price – discounts` into three different places. You must track down and change all three. This is not ideal.

Code written via TDD is vastly superior to code that is not.

While you’re new, don’t worry about testing at all.

Once you’ve got your footing, make it a priority to learn the practice of test-driven development (TDD).

Then, once you understand the mechanics of TDD, do it all the time. When it feels hard and unnatural, important learning is taking place. Redouble your efforts.

Practicing TDD will have more impact on the quality of your code than any other habit.

It’s extremely important to name everything in your system well.

You should exert significant effort in making sure every variable, method, class, module, file, and repository has an excellent name.

You are likely at first to choose names that are too short. Don’t be afraid of longer, more descriptive names.

If a name becomes slightly inaccurate due to code changes, rename it eagerly.

Be consistent: always name the same concept the same way in all parts of your system. If you discover an inconsistency, fix it eagerly.

Be warned

Some fraction of experienced programmers will disagree violently with my recommendations.

This is mostly because most programmers are extremely detail-oriented. The omission of subtleties enrages this group more severely than the general public. These rules are simple because they are for beginners, but that will not assuage some portion of people. They will be angry that these rules are sometimes wrong.

Other programmers will object to these rules on different grounds. For example, some will say that creating too many methods is equally bad as having large methods. I believe these people are wrong. But even if they weren’t, beginners so consistenly create methods that are too long that they need not worry about the other extreme.

Want to learn more?

You can see me discuss all these topics, refactor code to follow the guidelines, and explain my TDD workflow in this 96-minute Peepcode screencast.