Interested in learning Ruby? I several pieces of advice, if you’d like them.

If you’re in bootcamp, first, stick with it. If you’re in a bootcamp at the moment, you’re probably very busy. I wouldn’t add a lot of active education outside the bootcamp until you’ve finished inside it.

Books and Resources

Once you understand the basics, there are a number of good books. Metaprogramming Ruby is near and dear to my heart. “Learn Ruby the Hard Way” can be good, but may also be a bit basic for you, depending.

99 Bottles of OOP is both a good early-career book and one of the best practices of the fundamentals I have ever seen - I had over 20 years of experience when I worked through it and it’s still one of the most valuable books I have ever read. 99 Bottles was a big inspiration for my book Mastering Software Technique.

ConFreaks records a huge number of technical conferences every year. So if there’s anything that’s been given as a conference talk at any Ruby conference, you can probably watch the talk for free.

As you get more advanced in Ruby, consider learning more about its internals. Patrick Shaughnessy’s book Ruby Under a Microscope is still the classic for that, and almost all of what it teaches is still valid for the current Ruby interpreter.

One important thing about books and resources is that you don’t want too many. In my experience, buying lots of them means you won’t read deeply or do too much with each one. I’d recommend you pick up something work-based such as 99 Bottles or my own Rebuilding Rails and put serious effort into working through it, probably over multiple weeks or months. Alternately, pick a “deep dive” background book like Ruby Under a Microscope or Metaprogramming Ruby, but then do a lot of exercises from it.

Working deeply will teach you more than working broadly in the long run, as long as you change up what you’re working deeply on.

Speaking of which…

Generalists and Specialists

A common question is, “should I go deep on one specialty, or generalise?” If you’re reading this, there’s an excellent chance you’re a Ruby programmer and a web programmer. In that case, good news! This choice has already been made for you and you just need to accept it.

As a web programmer, you’re going to wind up as a generalist. JavaScript, HTML, CSS, SQL, a surprising variety of devops and deployment-type tools… Those are table stakes, along with your preferred language. Even if you use Node.js and skip Ruby you’re still going to have to learn a lot of Node-specific tools and libraries, which isn’t much less work. That means the surface area of your knowledge will be enormous. And at least initially its depth will be limited. You can’t learn that many very different tools to the point of mastery without putting years into it. While you can decide to do that, it’s going to take a long time.

That doesn’t mean your level of expertise will be the same for all these technologies. It’s uncommon for any developer to have the same level of expertise in both CSS and SQL unless that level of expertise is quite low. Normally you’ll specialise in “front end” or “back end” or “devops” or “data science” (some front end, some graphing and some statistics) or some other pattern of skills. “Full stack” is normally a euphemism for “good at one of these patterns of skills, but willing to do others at a lower skill level.”

For myself, I’ve wandered from specialty to specialty over a long career. I recommend it highly. You’ll know a little about everything. And it’s not like any one of these specialties will stay “the right thing” forever. By changing what you learn, you’ll usually know a bit about any new thing that comes down the road.

Can you specialise as a web programmer? Sure. But you’re going to be quite limited in what you can do. There are absolutely DBAs (Database Administrators) working on web sites, and they’re more specialised than the vast majority of developers. But a DBA can’t easily set up a project on their own, while you would like to be able to do that. And that requires being a generalist.

As a Ruby (and Rails?) programmer, you’re unusually well-positioned to do that for yourself.

What’s Holding You Back?

Once you have a basic understanding of programming, the question is always: what is between you and what you want? What’s holding you back?

(This requires having some idea of what you want.)

In my experience, the steps for a full-time developer go roughly like this:

• I don’t know the basics of coding (non-developer or junior)
• I can code, but I don’t understand working on a team (junior developer)
• I can build a project on a team, but I don’t yet have a professional, methodical and disciplined approach (“just a developer”, maybe senior)
• I can build software solutions reliably on a team, but I have trouble working with whole company, not just engineering (senior dev)
• I can work with non-dev professionals, but I have trouble convincing people of my approaches (senior/staff engineer)
• I can work in harmony with my whole company, but the world is large and these tasks are hard (everybody, forever)

None of this is a hard-and-fast rule, obviously. You can easily be in a position where it’s career or coding ability or something else holding you back in a different way.

And of course, a different career arc has different obstacles. Freelancing? Starting a company? Investing it all in real estate and keeping rent low while you keep your head down? You won’t necessarily run through steps that look like these at all.

I have other general career advice, which may or may not be of use to you.

How Can You Fix It? How Can I Help?

Most advice on learning assumes you already know what you want. Advice only works if you know where you want it to take you.

For all the criticism of “The Secret”-style positive visualisation, let me sing its praises a moment: if you do positive visualisation of your goal then you know what success would look like for you. In my experience, one of the most common causes of failure is having no idea where you’re going or what it would look like.

With that said, once you know where you’re going, you’re pretty likely to know what’s in between you and it. What do the people who have that success already look and act like? What can they do that you can’t? Now might be a good time to think about those skills and how to gain them. We live in the age of Google, which makes questions like, “but how would I learn to draw?” or “how would I gain confidence?” surprisingly easy to answer. The trick is figuring out what skill will fill in your own personal blank.

Of course, if you guess wrong, you still get the skill. So there’s that. A lot of success is happenstance. Keep doing good work and eventually good things will tend to come your way. That’s maddening. You can’t plan on it! But it’s true anyway.

With that said, I have a few suggestions of skills that may be helpful.

One thing you’ll have to do in software development forever is to work with other people’s libraries and frameworks. To do that, you’ll want to dig deep into them. I have a workshop on that, or if you’re willing to spend money, a book that expands on the same thing.

If you’re having trouble with coding — not algorithm design, not big-O notation, but just turning a problem into code that solves it — then it’s hard to find good sources. Mostly you need to find a real-world problem and solve it… mostly. I have a great form of coding exercise that fixes all the traditional problems with it. With coding studies you don’t need somebody else to design them for you, you can benefit from the same ones over and over, and they keep helping you improve forever, not just at the beginning of your career. My 2019 RubyConf talk covers the basics, and I have blog posts that may help you as well. Or I have a book about that as well, which goes into great depth.

Alternately, drop me a line! The email address you get from me (by buying a book, or signing up for my email list, or various other ways) is my personal day-to-day one. If you email me, I’m pretty much guaranteed to see it within GMail’s normal limits.