Testing is widespread in the Rails community, which is awesome. For most new developers, learning to test is not simple. New developers often think testing should come naturally if you can code well. I mean, I wrote the code, I should be able to write a test for it, right? Over the past 2 months at thoughtbot I’ve come to learn why this is false and now I’m learning to test.
Testing is like any other skill, you have to practice to get good at it. Good test driven developers use previous experience to figure out what tools to use when presented with new challenges. Don’t get discouraged when you don’t know how to test something, just take a step back and evaluate the problem. Improving your testing skill also requires discipline and persistence.
No matter how dedicated you are to testing, there are times when it will slow you down. At that point, its really easy to skip testing, just this one time. It takes discipline to make sure that doesn’t happen. Take the extra time, invest the extra effort and find out how to test it, and then in the end your development process will speed up.
The Rails community has tons of people willing to help. If you get stuck on testing something, google first, then check out the Rails forums or the Rails IRC channel. Don’t hesitate to comment on blog posts which come close to solving your problem, but fall short. I’ve found the Rails community to be very helpful so don’t be afraid to ‘drink from the firehose.’
Learning to be a good at test-driven development is hard, but being a developer is hard in general and testing skills must be practiced. Once you start writing tests more regularly, you also learn how to write code that is inherently easier to test. I joined apprentice.io to become a great developer and learning to test well is half the battle. It’s ok to suck at testing when you begin, but practice makes perfect. A great place to start learning is our Intro to Test Driven Rails Workshop, we have a course coming up later this month. Soon enough, you will think in tests before thinking in code.
I’ve been speaking about and teaching people vim for several years now, and I’ve noticed a surprising pattern: people are literally afraid of learning the editor.
Over the years, the popular mythology around vim has become that it’s insanely difficult to learn; a task to be attempted by only those with the thickest of neck-beards. I’ve heard dozens of times from folks who are convinced it will take them months to reach proficiency.
These beliefs are false. Here’s what’s true:
Go to your shell and type vimtutor. The tutorial that’s presented is excellent and you’ll be through it in no time. Once you’re done, you’ll have the rudiments needed to get your work done. You won’t be fast yet, no; but you’ll be competent. And even after those 30 minutes, you’re going to start grasping the ideas that make vim so amazing: the brilliant design decision that is modal editing, the composability of commands, the clever mnemonic naming of commands. These will be enough to make you want to learn more.
No one ever says “I’d love to learn Street Fighter 2, but there are just so many combos!” People don’t say this because learning a game is enjoyable. You start off with just the basic kicks and punches, and those get you by. Later, you learn more advanced moves, maybe even by accident.
Learning vim is like this. At first, you do everything as simply as possible. Then you start to wonder if there are faster ways to get things done, and there are! If you chain those commands together they just work! You bump into things accidentally, or maybe you spend some time in the extensive help files. Over time, you burn a few advanced tricks into your muscle memory.
Soon, you realize there are many ways to accomplish your edits, and you strive to do them in as few keystrokes as possible. This can be incredibly satisfying, particularly to us technical-types that seem to have a higher-than-average appreciation for efficiency. It may be hard to believe that trimming one keystroke off a command will one day trigger a dopamine response, but I swear it’s true. Just ask these guys.
If you use vim all day and make an effort to use it well, you’ll be editing code faster than you did in your old editor within two weeks. A couple tips to help you on your way: keep a cheat sheet of commands you’re trying to commit to memory, find a friend that’s an experienced vim user for the many questions that you’ll have in the beginning (ask in #vim if you have no such friend), and pay attention to things you do that feel inefficient (there’s almost definitely a better way). If none of that works, reach out to me on twitter and I’ll try to help you out.
There’s a reason everyone at thoughtbot is using a 20-year-old text editor. There’s a reason I’ve flown to other countries to try to convert more vim users. There’s a reason people love this editor. Maybe you should find out why.
Good luck! And happy vimming.
