Don’t believe everything we say

While you are learning to program you’ll talk to seasoned developers, ask questions, and listen to their advice, tips, and experiences.

That’s great! We recommend you listen closely, try to understand, and ask more questions.


Always try to put things into perspective. Whatever you hear, try to understand, compare with other opinions, and judge for yourself.

As in any other field, developers, as much as any other person, will always give answers based on their own perspective, based on their own experience, and based on what they think is a helpful answer to you. Now, being a great Ruby developer (“knowing your stuff”) and being a great Ruby coach (“giving the right advice”) are not the same thing.

Developers who have never coached, or are new at coaching, tend to, for example, overload you with information. They know all this stuff, and, as said before, they aren’t even fully aware of it. They just use the language, and all these features.

Now, when asked to explain things, and may suddenly remember: “Oh, right, and then there’s also this other language feature, and that one, and another one, and …!” They may be excited to explain all the things at once, without realizing that, at this particular point, you actually don’t need to know them all at once.

Also, they might present a conclusion, and omit the learning process. In programming, as much as in any other field, there’s rarely any silver bullet. There are always alternative solutions, with different advantages and downsides. Often it’s hard to fully understand them unless one tries a particular solution and sticks with it for a while.

On top of this, whatever is considered a “good” solution by the community at any point of time, is always the conclusion of a decades-long evolutionary learning process. Often it makes sense to start practicing with an older and simpler solution that worked well enough a couple of years ago, and experience some of the problems it caused, and only then try using the latest, more modern solution.

Developers often tend to be excited about their current preferences, and things they’ve learned just recently, and will happily explain at length why one solution works better for them than another. Often you can learn a lot from listening to these explanations. However, keep in mind that this doesn’t necessarily mean a tool that’s great for an experienced programmer is also a tool that’s great for learning to program.

On top of all this, there’s also the problem that the tools we use, over time, become more and more optimized for advanced users. New features are being added that make our day-to-day work easier, and over the years, up-to-date documentation and tutorials will focus on these features.

While that’s great for advanced users, it’s sometimes bad for beginners, as you now not only need to understand the basic concept, you also need to understand this additional, more abstract feature that sits on top of it.

A good coach will try and adjust to these things, but doing so also is a skill that needs to be learned. Try to give feedback, and help your coaches improve.

Of course, everything said above also applies to ourselves :)

Here are a few examples of decisions we made for our study groups. Don’t worry if you don’t understand what we’re talking about at this point. You’ll fully understand them once we get there during study group.