Forem: CodeByBlazej

CRUD, reps, repeat - My Database Grind

CodeByBlazej — Sat, 11 Oct 2025 19:31:44 +0000

Howdy! Just wanted to share how the database section went. It was packed! Like always, I kept track of the hours and days (for anyone curious). It ended up taking me exactly 30 days, from 17/07 to 17/08, and exactly 73 hours.

I’m posting this a little later than I thought I would, because I switched up the way I track my time. I’ll do a separate post on that since it might help somebody.

Databases

When I first got to databases, there was one sentence, which my friend told me has been ringing in my ears since - “databases are terrible and I hate working with them.”.

I knew it was coming and this fact made me a little bit nervous. After I started and looked at these 2 lessons inside, I thought to myself, “something must be wrong here.”

It’s either my friend, The Odin Project or my memory. I actually preferred this to be the 3rd option!

Anyway, jokes aside, let’s start databasing.

I started reading all the basics, what databases are, what they do and how different types compare. That first lesson is really packed. Lots of links, lots to read, and plenty to absorb.

The final assignment in that lesson is the Khan Academy SQL tutorial, which has really been well put together and it’s worth finishing.

And please don’t skip the extra resources. There are only two lessons in the section, and if databases are new to you like they were to me, those links are truly gold.

You will need the practice for the project in lesson three, it’s pretty demanding. These resources are well chosen and full of clarity. My favorite was the CS50 video. Yes, it’s long but it really cements the concepts!

Databases and SQL

The second and last lesson is even longer and mostly about doing, writing SQL and actually populating a database. CRUD in action: Create, Read, Update and Delete. Get ready for proper repetition here.

Of course, again, hit the additional resources. As far as I remember, one of the links felt outdated so I skipped it, but the rest? Full of practice.

Are they boring? YES. But drilling the same patterns for a while helps your brain lock in the flow. I’m not the most clever one as you can see, so I leaned into the reps.

Project: SQL ZOO

Finally there we are! Project time! It took a while to reach this point and I thought, “Huh, this wasn’t that bad if you asked me.”

Then I started the exercises. The site feels a bit old-school, but it works and there’s a funny little face that pops up when your query is right. You’ll end up waiting for that face like it’s a treat. If you have gone through all those exercises I nagged you about, you’ll probably handle 90% of the project with some head scratching but steady progress.

Here’s the catch. The Odin Project says to complete 0 throught 9:

But the site itself also hides a few extras on the main page: 8+, 9- and 9+. They are also required but if you were going through the lessons selecting new ones from the panel on the left hand side, you might not have noticed them.

And well, that’s where I finally agreed with my friend. Some of these were brutal. I found posts from others saying the same. Some prompts aren’t super clear, which makes it tough to know exactly what results they want.

Still, don’t skip them. Most are solvable if you give yourself time to think and test. The last couple in those “bonus” sets, though… different story.

I’ve got to be honest here: I failed the last one in 9+. I looked up a few solutions and none worked for me. I didn’t bother asking AI at this point, after all the practice, the query process itself felt clear. If you crack that final one, tell me how you did it! I am really genuinely curious!

Leveling Up CSS Skills and How Grid with Better Habits Changed the Game

CodeByBlazej — Thu, 21 Aug 2025 20:37:24 +0000

Hey everyone! After wrapping up the Ruby section which I talked about in my last article I jumped straight into the “Intermediate HTML and CSS” lessons.

Honestly, I wasn’t exactly sure what was waiting for me, but I knew CSS Grid was probably going to be the biggest new thing I’d learn from this part of the course.

If you’ve followed my articles before, you know I always track how many hours each section takes. Surprisingly, this one was pretty short compared to Ruby or even Foundations, but it was still a lot of fun. Overall, it took me exactly 211.5 hours, spread out over 73 days, from 4th May 2025 (when I finished Ruby) to 16th July.

We kicked things off with Emmet, which, funny enough, I was already using without realizing it. Back when I was stuck in “tutorial hell,” I used to copy everything from JS videos without knowing that handy shortcut even had a name. Well, now I officially know what I’m doing with Emmet!

Next up were SVGs and tables. SVGs weren’t too bad, but tables gave me a bit of a headache. It took me a few solid hours to really wrap my head around them. But don’t worry, after some practice and a few good articles, things started clicking into place.

Then came the intermediate concepts, stuff like CSS units, advanced selectors, and CSS functions. There was definitely a lot of reading, but at this point in the course, things felt way easier to grasp. The trickiest part by far was CSS positioning.

Trying to learn positioning just from reading articles was a challenge, but luckily, the next project, Sign-Up Forms, gave me plenty of hands-on practice.

Speaking of the Sign-Up Forms project, don’t let the short lesson count fool you. Even though there were only two lessons, they took me twice as long as the entire previous section.

Seriously, you’ll have tons of resources to dive into, but believe me, it’s worth reading them all. Forms are a huge topic, super customizable, and everything you learn there connects deeply. If you’ve been with The Odin Project for a while, you probably already know how this goes!

You can check the code of my implementation of the sign-up form here if you’d like.

Doing this project was refreshing because we hadn’t touched front-end stuff in a long time. It was also a perfect opportunity to practice CSS positioning. Initially, I positioned the left side of the form with positioning techniques, but I didn’t love how it looked when resizing the page.

So, I went back to good ol’ flexbox. Honestly, flex just felt easier for me. But hey, if you figure out a clean way to do it using positioning, let me know. I’d genuinely love to see how you pulled it off!

And finally, we hit Grid! I had a great time with these lessons. They included a quick flexbox refresher (just in case you forgot!) and plenty of explanations comparing flexbox and grid, when to use each one, and why. Grid turned out to be pretty easy to understand, and honestly, I think everyone following Odin had been eagerly awaiting this moment.

Click here to view my implementation of the dashboard project.

Wrapping It All Up

Before I finish, I just wanted to share something I’ve noticed lately: changing my learning routine has seriously boosted how well I understand the material. Instead of cramming everything into one session, I split my learning into three shorter sessions each day. Suddenly, the projects at the end of each section started feeling way easier, and I didn’t have to constantly revisit past lessons just to remember how something worked.

It sounds obvious now, but it wasn’t until recently that I realized how powerful it is to read several articles about the same topic back-to-back. Call me slow, but better late than never, right? If you can, definitely give this three-session approach a shot, I totally recommend it!

How I Got My First Client Midway Through The Odin Project

CodeByBlazej — Mon, 14 Jul 2025 12:00:00 +0000

Hey everyone! Today I want to share how I managed to land my very first client while still working through The Odin Project.

A few weeks ago, right after finishing the Ruby section and starting on HTML and CSS, my friend gave me a call. He recently kicked off a business making custom horse stables, and as we were chatting, he mentioned a pretty annoying problem they were having.

Basically, customers could choose different styles of stable fronts and dividers, think silver, gold, or bronze. Each one needed customizable middle panels, either made from softwood or plastic, to prevent horses from kicking the metal. Every choice changed the pricing, and right now, my friend’s system was pretty manual. He’d measure everything, talk to the customer in person or over the phone, then crunch numbers using a PDF. Honestly, it sounded exhausting.

Without giving it a second thought, I told him I could whip up an app to handle all this in similar manner to an online store. He sounded thrilled, so I asked him to shoot over all the data, promising I’d get right on it. And just like that, I had my first client before even finishing Odin.

Fresh off the Chess project, I felt pretty confident about handling classes and objects, so this new challenge seemed straightforward enough. I started dedicating about an hour each evening, and within a week, I’d built a fully working console version.

While building the console version, I naturally started thinking about deploying it somewhere online with a proper UI. But I quickly realized deployment was part of The Odin Project that I hadn’t reached yet. I did some Googling, hoping there might be a quick way to deploy just a Ruby app, but no luck. Rails was the way to go.

Luckily, my friend and I go way back, so I just asked him to use this console version through a simple workaround (like running it locally) for now, until I caught up in Odin and could properly tie everything together with HTML, CSS, and Rails. Of course, I could’ve jumped ahead and figured out deployment and UI design myself, but honestly, I preferred doing things Odin’s way. Trying to unlearn something done incorrectly is such a headache. Maybe I’m being a bit too cautious, but I figured skipping ahead would just mean extra refactoring later. Plus, my friend’s business is still new enough that taking orders over the phone isn’t a huge issue right now.

For me, it’s a win-win. Once I finish The Odin Project, I’ll have a fully polished app to add to my portfolio. Who knows, perhaps my friend will even recommend me to someone else. That’d be pretty sweet, right?

My 468-Day Experience with The Odin Project - Part 2

CodeByBlazej — Tue, 10 Jun 2025 20:52:05 +0000

Hey there! After spending another 357 days on The Odin Project, I’ve finally hit a big milestone, I finished the Ruby section!

So why does the title say 468 days then? Well, the Foundations section took me 111 days, and since my last article about that journey was pretty popular, I figured you’d enjoy another update.

If you haven’t checked out that previous piece yet, it’s worth having a look! I carefully tracked my progress every day, so counting my total hours was pretty easy.

Overall, I’ve spent exactly 686 hours on this journey. My daily routine mostly stayed the same, but recently I started squeezing in an extra 30 minutes to an hour of study each morning. About two months ago, I even started waking up 90 minutes earlier to boost my learning pace.

On top of that, which not everybody might like, I began to listen to techno music while learning. Why? I have noticed that it helps me with being distracted while going through long articles, where I caught myself reading 1 sentence 15 times over and over again sometimes.

This post is basically my reflection on learning to code with The Odin Project, what I’ve picked up during this Ruby section, and what the overall experience was like.

I still clearly remember sitting on my bed, which has been my unofficial “office chair”, thanks to my weird little room, excited to dive into Ruby right after wrapping up the calculator project from Foundations.

The Basics

Honestly, the beginning was pretty rough. Diving straight into Ruby documentation? Yeah, I nearly fell asleep more than once. At that point, coming from JavaScript, I started doubting if I’d made the right choice, I mean, wouldn’t JavaScript have been easier since I already knew a bit of it? But I’m glad I stuck with Ruby because it turned out to be totally worth it, I’ll explain more about that later!

Every lesson included a lot of material covering all the necessary topics like variables, hashes, arrays, and so on.

I still struggled with loops at this point and I don’t know why. Now they seem fine after so many projects, but at that moment in the past, I remember I was still getting stuck whenever I had to write something involving loops or more complicated logic that based on them.

The debugging lesson was also interesting, as it differs a lot from JS, but it was extremely important and useful! It saved me plenty of time later on in many projects.

And finally, there was the lesson about enumerables. Remember, at this point, my brain was pretty much wired to JavaScript syntax. But when I finally grasped what these enumerables were all about, I was hooked! It felt so easy and clever to do something in just one Ruby line that would normally take me 10 lines of JavaScript. I loved it and immediately wondered how often I’d end up using them. It wasn’t long before I caught myself squeezing enumerables into every project I tackled. They seem to match exactly how your brain naturally approaches problems, quickly becoming the first tool that pop into your head when coding.

And for you JavaScript folks! Before you call me arrogant for not mentioning an equivalent in JS, just hold on! I simply haven’t reached that point yet. If there is something similar, drop it in the comments. I’d genuinely love to check it out and compare. If not, maybe give Ruby’s enumerables a try and see what you think!

Basic Ruby Projects

Finally, it was project time, perfect for testing out all these new Ruby tools.

The first one, Caesar Cipher, wasn’t too bad. Shifting letters back around after Z was the trickiest part.

The substring project was pretty straightforward, dealing mostly with strings, hashes, and enumerables. I probably could’ve turned it into a one-liner, but I split it up for clarity. Looking back nearly a year later, figuring out ‘reduce’ was probably the biggest hurdle.

Stock Picker was next. The trick there was matching two arrays, one with prices and another with days to buy and sell for the best profit.

Then came Bubble Sort, the hardest of the bunch. Luckily, some extra reading and an awesome video from the lesson cleared things up.

Whew! These four projects weren’t super long, but they sure felt intense!

OOP Section

I have to say, I couldn’t wait for the OOP section to start! At that time, I had been reading tons of posts and articles about it because I knew the entire process of designing apps would rely heavily on OOP.

Everybody seemed to be talking about it, and I kept trying to picture how it actually worked. I even compared it to a car engine in my head, imagining that each part of the app would somehow depend on another, all working smoothly together. Turns out, I wasn’t that far off!

A lot of what I imagined turned out to be true, and I really liked it. In fact, I even wrote another article comparing debugging code to fixing cars, there are more similarities than you’d expect.

There were two projects in this section: Tic Tac Toe and Mastermind. These were actually pretty enjoyable because they were a bit longer and more advanced than the earlier ones. I had a great time figuring out different ways to solve them. Honestly, who knew programming could be this much fun?

Here are the repo links if you’re interested:

Files and Serialization

This part took longer than expected because I really wanted to get it right. File handling basics were straightforward, but TTY (terminal devices) was tricky. It confused me enough to motivate me to write another article, complete with a simple diagram to clear things up.

A Bit of Computer Science

This section was sooo long! It was packed with tough, demanding projects and tons of information you probably hadn’t even thought about until now. Like how RAM actually works under the hood which I found super interesting, especially when you imagine all that data zooming around under your fingertips, completely invisible to the eye. Pretty wild, right?

You also learn how to calculate the speed of different algorithms, when to use which one, and why it even matters.

Oh! And I definitely can’t forget the Knight Travails project at the end. That one was brutal. Honestly, I think it was the hardest project so far in the whole curriculum. Most projects give you a few different ways to solve a problem, but here? Not really. As far as I remember, there were only one or two valid approaches, and you had to use a proper algorithm to get it done. It’s not even a lot of code, but the mental effort? Next level.

Knight Travails repo

Intermediate Git

Bookmark these lessons, seriously! They’re easily among the best in the entire curriculum. Git and GitHub can feel weird and confusing, but these lessons clarified everything perfectly. Up until now, every Git issue had me wondering when we’d cover it properly. Well, here it finally was.

Testing Everything with RSpec

Another long but rewarding section. Learning RSpec felt almost like tackling another programming language entirely. It was tough at first because I’m still more comfortable writing code first and tests afterward.

My last project, the massive Chess game, was so big I couldn’t manage tests upfront. I’m still practicing, though, and improving bit by bit.I’m thinking of writing another article specifically about an interesting ‘real life’ project I recently did for a friend stay tuned!

If you stuck around till the end - seriously, thank you! I hope reading this was helpful, or at least cured your boredom for a bit.

Oh, and one last thing, remember earlier when I said I’d come back to Ruby docs? Well, they’re not exactly thrilling when you first start out, but trust me, the deeper you go, the more useful they become. Sure, you can quickly get answers from ChatGPT or a speedy Google search, but when you kinda know what you’re looking for, say, something specific like enumerables, and decide to peek into the docs, you’ll often stumble onto extra gems that make your code way better. I’ve found myself rewriting whole methods a couple of times after spotting an elegant one-liner in the docs. This happened recently during the Chess project and my friend’s app, and honestly, it felt pretty awesome!

My Journey Through The Odin Project’s Chess Game

CodeByBlazej — Sun, 11 May 2025 19:40:47 +0000

Hey everyone! It’s been a while since my last article, as life got pretty busy after wrapping up my Connect Four project. Anyway, I’ve been making slow but steady progress on the Chess Game, which is the final Ruby project from The Odin Project’s curriculum. Honestly, it’s been quite the journey: fun, massive, intense, and sometimes really frustrating. I figured I’d share my experience to help anyone else gearing up to tackle it, trust me, it’s not as scary as it seems!

Starting the Chess Project

Believe it or not, I started mentally preparing for Chess long before even beginning Connect Four. I’d caught snippets of conversations on Discord, and people kept saying how huge and complicated it was. What really caught my eye was how everyone seemed stuck around the 70% completion mark. Another thing is that many folks skipped Test Driven Development because of how huge this project was. That was enough info for me at this point, I didn’t want any spoilers, so I stopped reading!

When I finally got around to starting, my first step was drafting some pseudocode and getting the basic logic straight in my head. I had a few ideas, but I couldn’t shake the memory of the Knight Travails project, which I’d thought would help me solve the Chess challenge.

my pseudo, pseudocode

Why I Paused TDD (and Why You Might Too)

Initially, I focused on designing the chessboard and creating all the chess pieces to display them clearly in the console, no moves yet, just the basics. At first, being a good student, I wanted to follow TDD right from the start. But pretty quickly, I realized why everyone had warned it was tough.

I managed to write some basic tests for early methods, but soon enough, I was staring at my screen overwhelmed. Each problem I solved seemed to spawn two more, like some frustrating spiderweb. Eventually, I set TDD aside just to focus on making progress. I felt a bit guilty ditching tests because I genuinely liked them during Connect Four.

However, I promised myself I’d circle back once everything was up and running smoothly.

Navigating Chess Piece Logic (and the Headaches It Caused)

At this stage, I had a rough game class, a method to handle rounds, and my board displaying nicely but zero moves programmed. It was time to roll up my sleeves and start coding chess moves. I knew I’d need special pawn moves and king-rook castling eventually, but decided to start with basic movements first. Knight Travails was helpful, or so I thought.

knight travails method

It didn’t take long to hit another snag: chess isn’t just about movement, but also about dealing with other pieces. So I had to go back, refactor the code, and figure out how to handle situations like taking opponent pieces or preventing moves onto spaces already occupied by your own pieces.

Honestly, that refactoring part was a total pain, especially after finishing the knight’s moves only to realize the knight “jumps” rather than slides, forcing yet another rewrite.

knight moves after correction

Once basic moves were finally done, I tackled the special pawn moves like advancing two squares on their first move, which was tricky but manageable. Castling, though, was another beast altogether! I actually took a break to clear my head, switching back to refining the game class, adding clarity, extra variables, and cleaning things up.

By this point, things were coming together, and castling started to look less intimidating. But now I knew JSON serialization was looming, and frankly, that scared me even more than castling did!

After a few intense hours, I finally conquered castling, minus a couple of debugging sessions that nearly drove me nuts. Once sorted, I realized my prompts to the player were broken, so I fixed those too.

bit of castling movement

A Short Break and Battling JSON in Poland

Right after this, I took a much-needed holiday in Poland. It was my first trip abroad in three years, delayed by waiting for settled status. I’d ambitiously promised myself I’d code every morning from 6:30 to 11, but you know how it goes…

Friends called, family invited me over for coffee and cake, and suddenly coding turned into just an hour per day. But honestly, the downtime helped me recharge, even though it completely wrecked my sleep schedule!

trip to Poland

While in Poland, I tackled JSON serialization because I’d struggled with it before and needed to get comfortable with it. Honestly, it was incredibly frustrating. Everyone online seems to talk casually about JSON, but organizing everything into hashes, especially nested ones for chess pieces, was brutal. Maybe my design made things harder than necessary. Anyway, after three tough weeks, I finally nailed it!

a bit of JSON implementation

Back in the UK, my final week was dedicated to tests (yes, I finally returned to TDD!) and polishing prompts with some colorful console messages to make gameplay clearer and more enjoyable. And guess what? It’s DONE!

now a bit of RSPEC dopamine hit

I’m genuinely thrilled to be finished this project felt like it took forever! Now, I can finally move forward. No rush, obviously, but I’m excited for what’s next.

My Best Tips for Tackling the Chess Project

If you’re about to tackle this Chess Game, my main advice is patience. Take your time upfront to really map out your design. Grab a pen and paper, jot down your ideas, and plan thoroughly. Trust me, skipping proper planning landed me in a mess of redundant code and wasted effort. A couple more hours of preparation could’ve saved me heaps of trouble.

Good luck, and more importantly, have fun with it!

Connect Four Summary

CodeByBlazej — Fri, 04 Apr 2025 06:56:00 +0000

My most recent project was the Connect Four terminal game. You can check this out here if you want. This project was supposed to improve my TDD (Test-Driven Development) skills, as I had to write tests for every step.

It was a loooong project, and in this article, I’m going to tell you why.

The TDD Lessons Before the Project

Before I got thrown into Connect Four, I had to go through a couple of lessons and exercises about TDD.

These lessons were actually pretty interesting, they explained:

How TDD works,
What it’s used for,
Its advantages and disadvantages.

One thing I really liked is that The Odin Project doesn’t force us to use TDD, instead, it just teaches how it works in detail so we can decide for ourselves whether we want to use it or not.

The principles of TDD were pretty clear to me from the start as The Odin Project explains them very clear, and I was actually keen to try it out.

But at the back of my mind, I was a bit worried that it might stretch the time spent on each project… and, well, I wasn’t exactly wrong.

Starting the Project (And Why It Felt Hard at First)

So, I finished all the necessary lessons and started working on Connect Four.

At this stage in the Ruby course, the game itself wasn’t hard to implement.

The problem was:

I had to think about all the tests first before writing any actual code.
It was hard to wrap my head around this in the beginning.

Even now, as I’m writing this article while working on the Chess game, it’s still a bit hard to remember all the RSpec syntax.

Anyway! I quickly realized that the most important part of the process actually happens at the very beginning when thinking of test names.

That was the crucial moment when I had to figure out:

What is this test going to check?
What will the corresponding method actually do?

Once I figured that out, I wrote the basic test of course, struggling with RSpec syntax for a long time.

But then… BLINK - it’s green!

Awesome. Now I can move on to the next test and method.

It took me some time I’d say around 3 weeks? Something like that.

But I must admit, by the end of this project, I had a much better understanding of this whole TDD “magic”.

The Moment It Clicked (Why TDD is Worth It)

I realized that my project was MUUUCH BETTER thought out.

Less spaghetti code
Shorter, well-structured methods
Everything named properly

On top of that, I noticed I wasn’t wasting another week fixing bugs or refactoring half my code because I didn’t plan it properly from the start.

You know that moment when a tiny mistake messes up half your code and you have to go back and rewrite a bunch of stuff?

Yeah… that barely happened this time.

Will I Keep Using TDD?

Yes.

I liked this project. I like TDD. And I’m definitely going to stick with it for my future projects.

Less troubleshooting. Easier to understand code when coming back later. Just write tests in plain English, and you instantly know what your program is supposed to do.

It’s as simple as that.

The hardest part of all this is definitely RSpec—it just takes time to get used to:

Mocking
What to mock
When to mock

But honestly? The only way to get better at this is to just keep practicing until it becomes second nature.

How I Stay Motivated While Learning Ruby (Even When It’s Hard)

CodeByBlazej — Mon, 10 Mar 2025 06:54:43 +0000

Motivation is a huge thing when it comes to learning programming. Oh man, it is. I knew that when I was starting, but I wasn’t aware of just how important it would be later. I actually wonder if I’d even be able to do this if it weren’t for my schedule and the kind of isolated life I lead at the moment.

No, I’m not writing this from prison… well, kind of. Haha.

I’ve been learning programming—mostly JavaScript and Ruby from The Odin Project for over a year now, and I’ve noticed some interesting patterns. These patterns started emerging from the very beginning when I was going through the foundations course, but at the time, I wasn’t really aware of them. Looking back, I think this might be something useful for people who are just starting.

Before I get into these patterns, I want to mention that everything I’ve learned is based on my experience with The Odin Project’s curriculum, so it might not be the same if you’re learning from other resources. However, the human brain learns in similar ways across different fields, so chances are, you’ll find this relatable.

The Two Motivation Patterns: “Draining Necessary Boredom” and “Dopamine Hit High”

You can probably guess which one’s the low and which one’s the high.

The “Draining Necessary Boredom” Phase

This happens when a new concept is introduced, and we’re suddenly thrown into documentation, long articles, and theoretical explanations. These texts are usually lengthy, written in overly complex language, and, honestly, boring as hell.

At this stage, it’s a struggle just to stay focused. Our brain wants to procrastinate, we find our eyes glazing over the text. It’s a battle.

But here’s the thing: I never skipped any of those documents or long articles provided by Odin.

Why? Because I had already learned from other experiences (outside of programming) that this effort always pays off.

So, even though I was almost falling asleep in front of my screen, I forced myself to push through—even when I didn’t understand half of what I was reading.

Some topics required more reading than others, but trust me, this part is extremely important.

Even if you don’t understand everything clearly, just read through it till the end and carry on.

You might ask, Why not just watch a video or find an easier explanation? Well, here’s why:

First: There’s usually an easier explanation (like a funny article or a well-made video) at the end of the lesson. (Again, thanks, Odin!)

Second: By reading the full documentation, you’ll remember where to find the information when you get stuck in the future.

Third: And this one might sound stupid, but it’s not—MAGIC! Yes, dear reader, magic.

Because when you finally get to the project phase and sit down to plan out your code, you’ll realize you actually remember things from those boring lessons.

And it happens every single time, for every single project.

Okay, okay—it’s not magic. It’s just how the human brain works.

But still, seeing it happen feels like magic. And knowing this keeps me motivated—especially when I start doubting myself.

The Lifetime Plan: My “Why”

As I said in this article, I always wanted to be independent—to have my own thing rather than working for someone else.

Computers have always been a huge part of my life, and I’ve always wanted to build an online business. I’ve already had several attempts at affiliate marketing—which taught me a lot, even though they didn’t work out financially.

I knew that if I wanted to take things to the next level, I had to learn how to code.

And I also knew one thing for sure: If I started switching directions and picking up 100 different things, nothing would actually work out.

I had to stick to ONE thing and just carry on.

I chose to learn to code so that I could start building apps that solve problems and make money. This, or freelancing first to build an agency later.

But honestly? I’d rather build apps.

Now, you can already guess how this affects my motivation, right?

Especially on a Monday morning. Haha.

Finishing The Odin Project & Finally Building My Own Apps

The third motivation boost is knowing that once I finish The Odin Project, I’ll finally start building those apps I’ve planned for so long.

Right now, I have at least 60 app ideas saved up—waiting for me to validate and build them.

I hate seeing all these people pushing through on X while I’m still grinding through lessons…

But hey, it’s part of the process.

And I deeply believe it’s better to spend proper time learning than to rush into something and make nasty mistakes just because of lack of technical knowledge.

That doesn’t mean technical knowledge is everything—because it’s not. But you get my point.

Final Thoughts

So yeah, these three things have been working out for me so far!

Trusting the process (even when it’s boring).
Having a strong reason WHY.
Pushing toward a clear goal: building my own apps.

Now, I’m curious, what keeps YOU motivated?

I feel like everyone has an interesting story behind their motivation. Drop yours in the comments below!

How The Odin Project Changed the Way I Learn Code

CodeByBlazej — Mon, 27 Jan 2025 06:57:13 +0000

I started learning programming exactly a year ago. At first, I didn’t know if coding would be for me, so I decided to ask my friend, who is a programmer, some questions.

He learned how to code in college and then at university, eventually landing a job.

My Early Journey Into Programming

Why did I want to learn how to code in the first place? Well, I am tired of working in different companies doing mostly the same things every day—fixing machines, operating them, making products on various kinds of machines, and so on.

I have always wanted to start my own business and build my own projects or serve clients. I used to be a real estate agent, and I really enjoyed that kind of work—serving customers and more.

Figuring Out Where to Begin

Anyway, after asking my friend a couple of questions and comparing them with the skills I already have, we both concluded that learning programming shouldn’t be so difficult for me. The next step was coming up with some resources. He didn’t know much beyond Udemy and bootcamps, but he promised to contact another friend who’s also a programmer with much more experience. I said I would also do my own research, and then we’d try to find something great together.

After about two weeks, we called each other with some results. It looked like bootcamps were overpriced, and we thought that most of them were more about taking money from participants rather than truly teaching them how to program. Moreover, many of them tried to teach as fast as possible and seemed focused on keeping people accountable. That wasn’t a big deal for me because when I say that I’ll do something, I will do it no matter what.

I figured I might not be able to pull three hours a day of learning, but I am sure I can do one or two hours a day for a longer period than a bootcamp would last. On top of that, we claimed that for the price of bootcamps, the same knowledge might be found in courses on Udemy. So we stuck to Udemy.

Starting With Udemy

I found three teachers who seemed interesting for learning JavaScript with, and my friend also picked three. After some due diligence, I pulled the trigger on this one.

I was hyped, excited, and ready to start straight away. I bought the course, prepared some notes, and played the first video. As days passed, I could see my progress in understanding JavaScript, HTML, and CSS. I knew how functions work, what variables are, and, most importantly, how to start projects and make JS, HTML, and CSS communicate with each other.

At this point, I told myself it would be a great idea to split my learning time and add some YouTube videos featuring people doing only projects. I found these 3 guys which I learned a ton from. Really recommend them!

So much, in fact, that I started doing my own little project until I got to APIs, which I didn’t understand much. So, I went back to spending more of my learning time on Udemy courses again.

I kept going with that course until it got me to Classes, which I had no clue about. At that moment, it felt like I’d been introduced to plenty of things in coding, but all the lines of code I had written were actually copied from those resources I showed you above.

I didn’t see myself using all this stuff to do something on my own, but the course was already on Classes and OOP, which seemed so alien to me. I felt like I should have known much more at this point in order to grasp all these concepts, yet I wasn’t even told to do anything on my own yet! I knew something was off.

I checked where I was in this Udemy course, and it turned out I was exactly in the middle. I thought, “Eeeeemmmm, nope! It’s not going to work like that. There is no f***ing way to learn programming (a thing that people spend years on) in like three months.” By my calculation, I would be somewhere near the end of the course around that time. It made me a little sad, and I felt like I might join the group of people who write those types of comments online

I thought there must be a better way.

Discovering “Tutorial Hell” and The Odin Project

I began to scroll Reddit, looking for some helpful comments, and found the phrase “tutorial hell.” Yep, that’s exactly what I would’ve fallen into if I had continued getting other courses on Udemy and so on. But luckily, I found posts recommending The Odin Project.

A lot of people recommended either TOP (The Odin Project) or FreeCodeCamp. I did my own research and thought that if Odin takes sooooo long to finish, it must be a great resource. People who recommended it seemed really proud of choosing it in the first place.

I called my friend and told him about it. He had no clue what I was talking about. It looks like TOP is not very popular in Poland. But I told him my struggles with Udemy and then started TOP right away.

A Completely Different Approach

It was completely different! There was a lot of reading in the beginning and all that, but the first couple of lessons were nicely designed just to introduce the student to the whole process. I liked it.

Lesson by lesson, I became more aware of why it was so hard to learn from those courses on Udemy. I have a few theories:

Not Enough Depth: Maybe the lessons are often set up in the correct order, but there aren’t enough resources about each subject to give it more breadth. I’m not saying it needs to be as broad as an ocean, but at least broad enough for a beginner to understand what the concept is for and how to use it.
Limited Explanation: Often, there’s just one short way of explaining a particular subject by the tutor. If you still don’t understand what he/she said, you need to start looking elsewhere and then come back. Or you have to rewind the video five times, hoping your brain will finally get what the tutor is saying. In Odin, there are often five other resources linked at the end of the lesson meant to help you understand the subject.
Lack of Hands-On Exercises: There isn’t much focus on the student doing their own exercises. Of course, there’s something like, “We are going to make this thing now. Try to do it on your own before looking at the code I’ll write in a bit.” C’mon, guys, do you really want to learn coding? In Odin, when you start learning about a subject, you have an entire lesson on it. Then there are a couple of links explaining the same thing but in different words. I really love this because sometimes one article explains the subject in a more visual way, and another uses a more academic style. It helps your brain remember longer. At the end of each part, you always have some kind of project to test your knowledge. And yes, you are thrown in the deep water, and with short guidance, you need to sort everything out yourself. It’s not that you have to look for more info to do the project, because it’s always based on the things you have just learned. If you forgot something, you either know where to look for a quick refresher (the resources from the lessons) or simply in the Odin lesson itself.

Building Real Knowledge

Can you see the differences? Odin is long, and in every lesson, you find something that builds up the blocks of knowledge. Going through the course, you’ll have plenty of “click-ins” and “AHA” moments rather than, “What’s that thing for?” or “Am I lacking some knowledge at this point?” or “WTF is this, and where is it even coming from?!”.

At the moment of writing this article, I am at the end of the Ruby course—somewhere around 86%. The last time I spoke to my friend, I told him about lessons I’d just finished, which were Knights Travails, linked lists, graphs, hash maps, data structures, etc. He said that he had all those things at university, and when he asked me how deep the explanation went, he was actually surprised. He didn’t assume that Odin would take those things so far. Yep, it did, and I am really happy I decided to go through this.

At this point, I no longer have any fear of tutorial hell. Every single time I see some post online asking where to start and what course to buy, etc., I want to tell these people to stick to Odin and simply trust the process.

I don’t think anything is possible in two months, as many gurus on YouTube say. Well, you might be able to get some app running just by looking for simple guidance on what to do next, but isn’t it better to learn some stuff properly and then have fewer struggles along the way? You can just focus on building and adding to your knowledge rather than fixing up all the mistakes you’ll make and trying to figure everything out on your own.

From Wrenches to Code - Why Learning to Code Is Like Fixing a Car

CodeByBlazej — Sun, 29 Dec 2024 19:57:31 +0000

It all started with a frustrating car repair. For two months, I had been wrestling with an issue that seemed impossible to solve.

One day, I finally reached my breaking point. I sat back, took a deep breath, and tried to find some positives in the situation.

Surprisingly, that’s when it hit me: fixing cars and learning to code have so much in common. This is a story about how those two worlds collide.

Fixing Cars: A Childhood Passion

Let me take you back to where it all began. I was just 11 years old when I bought my first moped—a Romet Pony.

It was my introduction to the world of engines, grease, and endless tinkering.

Soon after, I joined a forum full of like-minded people who shared tips, tricks, and solutions to common problems.

A year later, I upgraded to a slightly better Romet Ogar 200, a Polish moped with a Czechoslovakian engine. Sounds fancy, right?

Well, not exactly. The previous owner had installed a poor-quality piston. Every summer, I would take it out for a ride, only to have the engine seize up after warming up.

Imagine the frustration of being 12 years old, spending holidays at your grandfather’s house, with no internet, no tools, and a moped that just wouldn’t work.

Still, I didn’t give up. I would tinker, troubleshoot, and try to figure out the problem.

When I finally got back home, I’d dive into the forum for answers. That forum was a goldmine of knowledge and camaraderie.

It wasn’t just about fixing bikes; it was about connecting with others who shared the same struggles. Some of the friends I made there remain close to this day.

The Value of Communities

Fast forward to today, and the parallels between those forums and modern programming communities like Stack Overflow, Discord, or even Reddit are crystal clear.

Whether you’re debugging code or diagnosing a car issue, these communities are lifelines. Need to fix a car problem? A quick Google search will bring up countless forum threads, blog posts, and even step-by-step solutions.

The same goes for coding. You’re never alone in solving a problem—someone, somewhere, has likely faced the same challenge.

Years of Repairs and Lessons Learned

Over the years, I’ve owned all kinds of vehicles—motorbikes, cars, you name it.

Some were reliable, while others were, well, let’s just say “character-building.” I’ve tackled repairs on my friends’ cars and on my own.

I’ve done everything from pulling entire engines out to complete rebuilds. Once, during a high school road trip across Poland, I even had to take apart an engine by the side of the road.

Those moments taught me perseverance, problem-solving, and patience.

The more repairs I did, the more I started seeing patterns. It wasn’t immediate—it took years.

Back then, we didn’t have smartphones or always-on internet. I would jot down notes, remember forum advice, and slowly piece together solutions.

Each problem was like a puzzle, and I loved figuring out how all the parts worked together.

Doesn’t this sound familiar to anyone who’s learning to code?

Troubleshooting: The Art of Debugging

Troubleshooting is an art, whether you’re working on a car or a program. Let me paint a picture for you.

Imagine your car’s engine is idling rough. Immediately, you start thinking: could it be the fuel-air mixture? Maybe there’s a faulty sensor or a clogged EGR valve.

You grab your diagnostic tool, check for error codes, and start narrowing down the possibilities. No air leaks? Great.

Next, you check if the turbo is spinning freely or if the DPF is clogged. Piece by piece, you eliminate the options until you find the root cause.

In coding, the process is strikingly similar. Debugging tools are your diagnostic devices. They point you to the error—file, line, and sometimes even the specific variable.

From there, it’s all about narrowing down the possibilities. Maybe the argument passed to a function isn’t what it should be.

Maybe there’s an issue with how data flows through the program. Step by step, you find the issue and fix it.

Tools of the Trade

Let’s talk tools. In car repairs, you have your spanners, wrenches, and specialized gadgets.

Each tool has its quirks and functions. Programming has its own toolbox—IDEs. Just as you’d swap a socket for a hex key when working on a different engine part, you might tweak your IDE’s theme or settings to better suit the programming language you’re using.

Even tests have their parallels. When a car starts, it runs self-diagnostics, checking sensors and systems. If all’s well, no warning lights appear, and you’re good to go.

Similarly, automated tests in programming ensure that your code runs smoothly before you deploy it.

Learning Curves and Growth

Both coding and car repair share a steep learning curve. They’re about trial and error, breaking things down, and continuous learning.

Each mistake is an opportunity to grow—whether it’s a seized engine or a crashed app. Over time, you learn to see the big picture.

You start understanding the entire system, whether it’s an engine’s mechanics or a software architecture.

I can confidently say that both skills have shaped my mindset. Programming, in particular, has refined my problem-solving abilities.

It’s taught me to stay calm in the face of challenges and to embrace the process of figuring things out.

The Joy of Completion

Here’s the thing about fixing cars and coding: the dopamine hit is real. When you solve a tough bug or get an engine running smoothly, it feels amazing.

It’s not just about the task—it’s about knowing you’ve conquered a challenge.

For me, realizing the connection between these two worlds has been a game-changer. It’s helped me approach both trades with a sense of curiosity and determination.

And I can tell you this: there’s nothing quite like the satisfaction of a job well done.

So, what about you? Have you ever noticed similarities between coding and other parts of your life? I’d love to hear your stories. Share your experiences in the comments, and let’s learn from each other.

My Journey Through Ruby Event Manager, Hangman, and Tackling Coolant Leaks

CodeByBlazej — Fri, 29 Nov 2024 06:57:20 +0000

Hi! I haven’t posted for a while as TTY lessons, articles about it, and future algorithm lessons stopped me a little. Those who read my other article Falling in love with Ruby Might know I wasted some time fixing up my car last time.

Well… This time I had a massive coolant leak but decided to give it to the garage as this time I had no room and access to tools to work on that.

I was a bit lucky as the fixup turned out not to be too expensive, and I could focus on learning again.

Event Manager

The Event Manager project was a deep dive into working with JSON, manipulating files, and reading CSV files.

It was a longer project, and for the first time, The Odin Project guided us step by step. I appreciated this approach because it felt like a solid introduction to concepts I’ll likely revisit.

It’s a great project to bookmark for future reference, especially since these skills will become second nature after repeated use.

Understanding how to build a hash for serialization took some time to click. Up until now, I relied heavily on arrays to solve most problems.

This project highlighted the importance of hashes, and I’ve decided to focus on using them more in upcoming projects.

If you want to see a code give my repo a look!

Hangman

The Hangman project was one of my favorites so far. It reminded me of the calculator project, which was the final task in the foundations section. Every step felt intuitive, like I knew exactly what to do to solve each small problem.

That said, I hit a few roadblocks toward the end—especially when trying to save the game state. Figuring out how to write valid JSON files and store them correctly took the most time. I had to revisit earlier lessons and piece everything together to make it work, but the effort was worth it.

If you’re curious about the code, there it is!

Advanced Ruby

The next in the line was Pattern Matching and Blocks. These lessons passed quite quickly and were not too difficult to understand.

Yeah, let’s see in the future 😀I can bet I will be coming to review them as well.

But to be honest, it wasn’t as bad. Pattern Matching and Blocks opened my eyes to more efficient ways to process data and pass instructions to methods.

While these concepts are still new to me, I see how they can streamline collaboration in larger applications.

Final Words

I’m currently working through the “A Bit of Computer Science” lesson, and I have no idea how long it’ll take to finish.

Once I complete the Ruby course, I’m considering writing a summary of the total hours I’ve spent on these lessons—similar to my previous article. I’ve been tracking my progress daily, and it might be interesting to share those numbers.

Let me know in the comments if there’s anything specific you’d like me to elaborate on!

How to Understand IO and TTY in Linux for Beginners

CodeByBlazej — Wed, 13 Nov 2024 14:50:00 +0000

After I finished Mastermind project which was the most difficult project so far I moved to Files and Serialization lesson in The Odin Project curriculum.

I stumbled upon a lot of long articles full of technical language that for me, non-English native speaker were quite difficult to understand. Especially after coming back from my 9-5.

When I was reading the last one, many things clicked and I thought it all could have been explained in a little easier way. I came up with an idea of how to make it in 6 simple steps and the results are below.

This is a nice funky graph for you to visualize it:

STEPS 1 - 2

Let’s start from the input. When you are typing something, input (IO) is taken from your keyboard and sent to TTY virtual device. TTY in Linux is the interface that handles input/output.

STEP 3

The input is then passed to the TTY session (the terminal interface you interact with).

STEP 4

From there, the TTY virtual device forwards it to the line discipline inside the kernel. Line discipline is the place where magic happens. For example, pressing BACKSPACE will clear the last character we typed in or process special keys, signals, and interpret commands.

STEP 5

After processing, the line discipline sends the input to the foreground process (like a shell) via STDIN.

STEP 6

When the process generates output, it then sends it to STDOUT or STDERR if it’s an error, which goes back through the TTY virtual device and then displays on the TTY session again.

Final thoughts

Don’t you think these processes are really interesting? Since I started learning how to code I was always curious about how everything works under the hood. What happens when you press some buttons, what kind of signals are sent, where they are going, and so on.

Maybe in the future, I will make a similar graph visualizing something else. We will see what I will get stuck at soon.

If you have more questions, drop a comment below! I’d love to hear what topics you’re struggling with or find intriguing. Your feedback helps me decide what to break down next. Happy learning!

Falling in Love with Ruby - First Impressions with The Odin Project

CodeByBlazej — Mon, 30 Sep 2024 19:01:00 +0000

Hi! If you read my previous article about why I chose Ruby you know why I didn’t follow JS even though it was still deep in my memory after finishing the Calculator project and the whole Foundations from The Odin Project.

Introduction to Ruby with The Odin Project

I have to tell you that I couldn’t wait for that moment and was super excited to learn Ruby and to really see how Yukihiro “Matz” Matsumoto managed to make it so programmer-friendly as many say.

Getting Started: Ruby Installation and Documentation

Firstly I had to install everything and it wasn’t difficult with TOP guide.

After a short while everything was set and ready to go. Firstly I was introduced to Ruby documentation that looked a little bit different than JS one. (What would I expect though?! It’s a different language! :D)

It took me some time to get used to that. Especially when it comes to all methods and classes. At that point, I could tell the OOP lesson was approaching because it seemed different from what I was used to.

Once you get the hang of everything, it becomes really easy to find the information you’re looking for. The next step was to learn what IRB is. It is a Ruby interactive model that lets you type your program in the console and run it without creating any files. Very useful thing that Rubyists use all the time and I liked it since the beginning as I didn’t need to open browser to check my code every single time like I was doing with JS.

Tackling the Basics: Data Types and Initial Challenges

After I was sorted with all those I was ready to tackle basic data types and after a couple of Pomodoro sessions my hype began to slow down. Why? It felt super boring!

I felt as if I was doing JS from the beginning. I thought I’d done this before, so why waste time doing the same thing again? I understand that I am learning a new language and I need to start from the basics but c’moooon!

Overcoming Boredom and Staying Motivated

I’ll admit, I was a LITTLE disappointed at first, but I had no choice but to stick to the plan and carry on.

I knew it would get more exciting at some point but I was only afraid to don’t lose motivation. Why would I? It took me already so long to get to this point that there is no chance I am stopping or changing my mind.

I didn’t want to fight with my thoughts any longer at this point and just decided to put in more hours and focus harder as procrastination started to crippling in especially between my Pomodoro sessions.

The next lessons were about conditionals, loops, arrays, hashes, methods, and debugging. I cannot say it was the most exciting time and at this time I missed making some projects. I felt as if I was forgetting how to write code while learning how to write code. Strange isn’t it? I hope that you know what I mean and maybe there are more of you who had the same struggles.

I then approached Basic Ruby Projects and this news made me happy. I was finally able to give it a try and solve some bigger exercises like I used with Java Script some time ago.

Well, I can’t remember how long it took me to finish them but it wasn’t too long before I got back to TOP lessons.

From Basics to Object-Oriented Programming (OOP)

The next one was Object Oriented Programming which I couldn’t wait for. At that moment I knew what it was going to be all about, more or less, and was eager to try it. Moreover, I was really curious if it’s so difficult to grasp as people sometimes say.

Since then, I planned to push through the curriculum faster during the weekends but something was always stopping me like my car broke and I had to buy another one as it wasn’t worth repairing my old one. Shortly after my family wanted to visit me and we were planning to go to Scotland for a week. I knew already that the time I wanted to spend on learning was limited that month.

When we were there, I did my best to learn Ruby for 1 hour a day at least. After we came back and I dropped my family at the airport, my friend from Birmingham came to me for the weekend as he needed me to give him a hand fixing garden furniture he produced and sold to clients not far away from where I live.

On top of that my newly bought car decided to start leaking and to save up money I decided to fix it myself over another weekend.

Guess what…

By this point, I had already lost three weeks of productivity. I was a little bit mad and scared that I wouldn’t be able to get my routine going again but fortunately, it seemed to start picking up nicely after I started again.

I continued with OOP which didn’t seem to be difficult. I could see the clear, organized approach, and I really liked it! I knew, however, that once I got to 1st bigger project using this, I would probably be stuck and have to return to these lessons. Well, that’s learning, isn’t it?

Ruby vs. JavaScript: My Favorite Ruby Features

Apart from time management, I knew Ruby was a great choice and even though I still had JavaScript syntax in my brain I could see how rewarding Ruby is. It was so easy to see how things are done in Ruby and I can promise you that if you decide to learn this you will have plenty of AHA and ‘’why couldn’t it be implemented to JS?!” moments.

Look at these examples I liked the most so far:

Range Operations:

In Ruby it’s super simple!

(1..5).to_a

And now look at JavaScript:

let range = Array.from({length: 5}, (v, k) => k + 1);

Symbol vs string usage in hashes

Ruby again makes it easier to read especially in large objects
Ruby (symbols as keys):

user = { name: "Alice", age: 25 }

JavaScript(plain object with string keys):

let user = { name: "Alice", age: 25 };

Another example is a case statement

I loved it since I found out about this for the first time. I finally didn’t need to use console.log which was quite annoying

case language
when "Ruby"
  "Great choice!"
when "Python"
  "Not bad!"
else
  "Consider Ruby!"
end

Javascript

switch (language) {
  case "Ruby":
    console.log("Great choice!");
    break;
  case "Python":
    console.log("Not bad!");
    break;
  default:
    console.log("Consider Ruby!");
}

Tips for Staying Motivated on Your Coding Journey

It took more work to get to this point of The Odin Project. I would even say that the whole Foundation was easier than the beginning of Ruby.

However, after these many lessons, my willingness to learn more has returned and I want to push further. I also stopped procrastinating so much.

If you are in a similar place with your learning schedule and feeling tired and thinking about doing something else I encourage you to don’t give up! Really! Maybe it sounds blatant and I might sound like a cheap coach or something but it works. At the moment of writing this article, I am working on a Mastermind project and it is fun.

Tic-Tac-Toe helped me to refresh all my knowledge about OOP and it seems like Mastermind feels much more fun as at this point I know how to solve many problems. Keep going, everything will click at some point!

I’ll keep you updated after I’m done with another challenge.