It's been a bit over a week since I've started the Software Development Foundation training with Discovery Partners Institute in Chicago. And I've learned a lot.

One main thought that keeps coming to my mind is the way we learn. The course has been very well thought, every new capabilities is built on what has been previously learned.

If I were to do this all by myself, I'd usually look up the industry standard, and aim for the mountain top. In our case here, it'd probably be Ruby on Rails for making web apps.

In doing so, I'd be cutting off the (seemingly) unnecessary steps. But it would make the whole process to be much more difficult. Let's go through a few of these steps that allowed me to climb a bit higher every day.

From Sinatra to Rails

I remember when we were introduced to Sinatra. We learned about HTTP requests at the same time. I had a general good sense of how the way internet worked, but doing it myself was a revelation ; it felt like new doors of possibilities opened up to me.

And yet, the first day of our in person class we replaced Sinatra with Rails. Now I understand that Sinatra can have its use case, for smaller apps, or apps where we don't need such a strict layout of files.

But moving forward, Rails will probably be the go to framework for web app development. But it wasn't lost. If I were to be digging in Rails while learning about HTTP and routing at the same time, it would have been exponentially more difficult. So I am grateful that people have thought through it, and trail blazed the way for us.

From SQL commands to Active Records

This process of building upon what was just taught just keeps going on and on with every new day that goes by. The next one is database interactions.

While being introduced to Rails, we learned about basic SQL commands. I've try to polish my understanding and get some muscle memory in by practicing on SQLZoo and the Firstdraft in-house exercises.

Quickly after that though, we were introduced to Active Records, which is built in Rails and facilitates interactions with databases.

Having gone through the process of working directly with databases through SQL, it made me more comfortable with working with Active Records because I have some sense of what is happening in the back-end.

Relationship databases: one-to-many, many-to-many

Speaking of database, I've worked with large data in my previous jobs, mostly with Excel. I would sit there behind the computer, and think of the best way to organize it. For the most part, I would come up with something fairly good and usable. But there were some cases I found hard to manage, and I never quite knew why they were different until now.

Putting words on the concepts of a one-to-many and a many-to-many relationships was truly eye-opening. For the latter, I discovered a third, "hidden" table (the join table). I also understood why some data type were giving me trouble to organize: they were describing a many-to-many relationship, and I was constraining myself with two tables, not knowing the existence of the join table.

Refactoring

When learning how to code, it is hard to find the right balance between laying solid foundations, and aiming for clean, industry standard code.

In this course, we learned to write code mostly from scratch. When we needed to find the director for a movie, we'd use a .where() method to match the id from the Director table. It's can be long and repetitive.

And then after typing these for the n-th time, we learned to set up our own class methods to do this more easily. I do know now though, looking back, that this was the right way. If I was taken straight to this point without the grinding, it would probably take me more time down the road to fully understand what is going on.

Association Accessors

Take the previous point, and throw in Rails built in Association Accessors method like belongs_to or has_many.

Even though I had written these class methods before, when I first was reading about the Association Accessors it felt like climbing up a very steep hill.

But then because we had spent time writing these, and the exercise was narrowed to a quick refactoring, it made it so much easier to understand.

Learning to learn

Learning can be a painful process at times. Good mentorship is key, and concepts broken down in strategic bits is really impactful in how we learn.

With these conditions, learning feels like a game. Every day, I unlock new capabilities, and I just want to keep playing and keep unlocking the next thing.