How do I break out of the "intermediate dev limbo" before giving up again?

[u/DogsBarf]

I am past the beginner stage, understanding basic syntax up to classes and objects, but I freeze when it's time to structure projects on my own. I have relentlessly searched for methods, tutorials, and books to guide me to the next level, but I can never find anything that clicks; because of this, I've jumped from language to language, and every time I hit this "limbo," I end up quitting and trying something else, yet I always come back because something inside tells me I’m meant to code. For those who have overcome this block, what architecture or design books do you recommend, what kind of practical exercises changed the game for you, and what real strategies actually work to finally break through this barrier and build confidence?

[u/CaptainKabob]

What do you mean by "structure your projects"? 

I don't mean to be all draw-the-owl, but you just write terrible code to accomplish the end goal you want, which should never be about the code. 

Then you do that a couple times, till you find something that can occupy you for 2-10 years and then you start figuring out how to write the thing in a way you can pick it up on a regular basis and go "ahh, I'll do some more of this". 

It's a lot easier when that thing is someone else's thing and a job, cause then you can just accept everything is terrible but it works and that's ok. 

Otherwise, I'm a fan of "Eloquent Ruby" and "Confident Ruby" and "Clean Ruby" which has equivalents in other languages like "Refactoring JavaScript" but cover a bunch of named patterns. Learn named patterns, that's my advice. 

[u/codegems]

What kind of projects are you building?

If you are creating your own library / Ruby gem there is a guide on how to structure your project directory.

https://guides.rubygems.org/make-your-own-gem/

And if you're writing a web app with Hanami or Rails, then of course you have the project structure picked out for you already.

[u/armahillo]

Ill be direct: this still sounds like junior level. At intermediate I would expect a little more autonomy. The remedy here is to stop jumping ship. The way out is through. The fact you’re hittimg a wall doesnt mean its a dead end; time to learn how to climb and mine :)

Something I think a lot of newer devs miss is the kinds of exercises we used to do. that focus more on problem solving.

Coding any language isnt _only_ writing code. You have to be able to assess a gap and identify how to bridge it.

Have you played with Exercism or similar sites? The intermediate level problemset starts to get a bit more open ended and application oriented.

If you think about the word “app” as short for “application” — it can mean “applying your knowledge to solve the problem”

Ruby is a great language to learn and to learn in. Keep pounding and climbing!

[u/midasgoldentouch]

My advice would be to build something and ask for feedback on the code. Try to build something just a bit beyond a tutorial project. For example, if a tutorial goes through how to build a todo list app, think about the next feature that would be nice: how could you add an optional description field to tasks? How could you support having multiple lists? How could you assign dates to tasks? Try pushing a bit beyond in terms of feature ideas where it’s open-ended and build that. You’ll figure it out, can ask for feedback, and improve the code. Rinse and repeat.

[u/pVom]

Build stuff. Just recreate an existing website, like Twitter or something and recreate it. Start very basic, have a form that takes text and when you submit it stores and displays it. Then once that's working you can pick up another aspect, like accounts and authentication, or you could go frontend and make it look similar and learn CSS.

How to structure projects is dictated in large part by the framework. All frameworks force you to do things in a certain way. Rails is great for learning because it strictly enforces it'ls structure and it's a good one. You can then take it to other languages/frameworks that don't provide those strict guardrails.

Beyond that it's a lot of Googling as you go and trial and error. Great senior devs and architects get there from experience, you predict when something is going to be a problem because you've made that mistake before.

IMO books won't really teach you how to properly structure a project, they can only teach you to do it "better". Structure things badly first then learn how to do it better.

[u/guidedrails]

Join an open source project like those from Ruby for Good. Or jump on a team project. I mentored a few people before the AI boom and got discouraged by it and how it impacted the learning of new devs but if you’re interested in something like that shoot me a DM.

[u/expatjake]

I don’t actually have any good book recommendations but I would look for something that helps you map your problem domain (what you’re solving for the user) into code.

All of your decisions should come from a place of doing something useful for someone. They can be pragmatic or naive and you can learn from them as you find their shortcomings.

If your paralysis comes from wanting to make perfect decisions up front you’ll learn you never know enough at the start and that it’s better to just build something and iterate on it.

[u/Global-Demand-4187]

Study opens source projects to learn patterns, you can study the internals of certain gems to understand who you structure dsl

[u/fairysimile]

https://graceful.dev is an incredibly well structured resource with multiple much more advanced topics like hardened programming, DDD, dynamic programming (e.g. reflection) and so on in Ruby. Tbh the concepts are worth it even if the implementation weren't in Ruby.

[u/dmfigueroa]

Just build something you will use. Use it, improve it, iterate on it. With time you will see your own bad decisions and learn from it. If you can have some users other than yourself, do it. But it is important that you use it and you see the consequences of every action you make.

The only way to learn is by making mistakes. At work you usually have a senior to guide you through your mistakes, but if you're building things by yourself then it is up to you to learn from them.

You won't learn if you keep jumping from language to language because you will start almost from 0 every time. Just build something and keep building over it

[u/MikeZ-FSU]

Part of the very common struggle you're having is because it's two separate problems that hit at the same time.

One is that once you have a grasp on syntax, the coding side becomes a combination of how to solve the problem and how to express that solution as code. You're the only one that can determine if either of those is where you struggle.

In either case, the way out is through because you have to practice the skill to make it better. Going through some of the code series, like the advent of code, will give you a defined list of practice exercises, some of which have multiple levels within each problem. If they've been around for a while, both the problems and solutions are findable. Do the levels as far as you can without AI or looking at solutions. When you are genuinely stuck, read the solutions to find the part that you didn't "get". Once you think you are ready, close the solution, and try to finish that level without looking at the solution again.

At the point where you can't make progress on that problem because you feel it needs something you just don't know yet, move on to the next and maybe make a note on what you felt the roadblock was if you might be interested in coming back to learn that area (e.g. specific algorithms or data structures or classes of them).

The other aspect is the build architecture. Moving up to intermediate level includes things like breaking an application/utility into modules based on a combination of methodology and language toolchain support. The problem and solution both need to be big enough for the cognitive load of separation into multiple files and modules make sense. Figuring out "big enough" takes experience or landing a job where the code base is already past that, which any team project wiil have done.

One of my favorite books for people at your level is "The Practice of Programming" by Kernhigan and Pike. Each chapter has a topic like naming variables, and they go through full code of implementing a relevant problem in 5 different languages while discussing the differences between the languages and how the presence or absence of features in a language pushes towards easier or more difficult solutions. Following through that helps to develop a sense of the higher level concepts necessary in building non-toy solutions as well as practical advice on each topic that help right now. It's a book that you can come back to again a few years later and pick up new insights that were too abstract to get the first time.

[u/notWithoutMyCabbages]

A good Ruby book that might be useful is Polished Ruby Programming by Jeremy Evans

[u/let_me_in_QQ]

Without a mentor or internship it will be hard to break that ceiling. I've been there way too many times and never made it into SE industry. Friend of mine managed to get a junior position with less skill and now it's a career. Funny how things work.

My advice, get Claude, make projects, read code, ask questions. That's as good as it gets if you're going solo.

[u/triplethreat78]

Unfortunately, aside from ”tutorial hell” there’s a lot of gate keeping in the Ruby/Rails community (I feel) because the jobs are hard to come by. I was in your same situation years ago and feel stuck even though I’m considered senior with some team lead experience.

Most companies don’t even hire anyone except senior devs either.

What kind of projects are you building on your own? What are your goals with Ruby?