Two months ago, I was given access to a codebase with an unfamiliar language and framework. I felt a lot of pressure. Coming from a React and JavaScript background, contributing to a PHP and Laravel project felt intimidating.
I feared that learning a new environment would take me a few months before I could make a meaningful contribution.
But this wasn't the case.
While cleaning my keyboard one afternoon, I looked at the keycaps I removed (pictured above) and was reminded of solving puzzles as a kid. You don't solve a puzzle by staring at all the pieces at once. You connect one familiar piece to another until the picture slowly appears.
That's exactly how I ended up learning Laravel.
As I explored the codebase, I realized I was mentally creating key steps to learning an unfamiliar technology.
Don't Start From Scratch
When I started, I literally felt like I was back on square one. But after a few weeks, I realized I wasn't starting from scratch.
I already knew concepts like package managers, Git, debugging, and project structure. I just didn't know what those concepts were called in Laravel.
My question then gradually changed from "How do I learn Laravel?" to "What is Laravel's version of something I already know?" It was like connecting new knowledge to concepts I was already comfortable with. I'm just actively expanding it.
React has components, while Laravel has Blade templates and Livewire components. Different tools, but same concepts.
Every framework has its own syntax that solves the same problem. It's up to us to find the parallels.
This kind of approach can be applied to anything really. If you want to learn something new, try to relate it to something that is kind of similar to what you already know.
Ideas start connecting faster and learning will become much easier.
Learn the Critical 20%
In the past, I was the type of student who wants to know everything or else I'll end up not understanding at all. But now, as I grew older I realized knowing enough to get started is more than enough.
Learn enough to become productive.
Learning too deeply about something on the first day is a death sentence for the brain.
I didn't try to learn everything. Instead, I focused on the 20% of Laravel that would let me accomplish 80% of my daily work.
Now this is the critical part. I made mistakes and most of the time they are quite laughable. If I were still the junior high school me, I would be too disappointed in myself.
But now, I'm just happy I'm finding these mistakes. It shows me exactly what I need to learn. It's not like school where we are given the syllabus. It's more of discovering the lessons yourself once a mistake happens.
We just need to have the discipline to not skip these lessons because that's what makes this setup work. The struggle of understanding new lessons is what makes a good engineer.
Start Before You're Ready
This step is harder than it looks, especially if you're like me who likes everything ready from the start. But the truth is, the more you go inside the colosseum, the more you understand your weaknesses.
No one can tell you where you are lacking better than you.
So I decided facing it head-on and lo and behold, I failed miserably. It was my first time setting up a Docker environment, Linux, WSL, Ubuntu, and everything that came with it. It took me around three weeks to get the local dev environment working before I could contribute.
Oh boy, let me tell you, I learned a lot. I mean a lot.
I even learned CI during the process and I quickly applied it in my web portfolio. I also made a fun video to document my experience:
You can watch the video here in this pull request. I feel like we all had this feeling once in a while π€£
Overall, I experienced the real thing. A messy real world web application that wasn't mine, but one I was responsible for fixing, maintaining, and scaling. No amount of personal projects could top that.
Final Thoughts
Looking back, I'm glad that I adapted, contributed, and presented my work during our tech meetings.
I am becoming more comfortable living in the uncomfortable.
I asked questions when I needed help, and helped others whenever I could. It was fulfilling. This is something I can confidently say after my early experiences in tech, and I'm excited for what comes next.
If you made it this far, thank you for reading my blog. See you again when inspiration strikes!
Top comments (3)
I lowkey vibed with this π―
Every dev gotta touch a tech stack they ain't familiar with at some point. The way you learned as you built it felt way more real than acting like you knew everything from day one.
W for sharing the whole journey, not just the polished end result π₯
Thank you. W too for this insightful comment!
Good jub , you can now call yourself a developer. go duck yourself
Some comments have been hidden by the post's author - find out more