The non pseudo working experience
Wondering what is “non pseudo” here? Well, it’s just the whole working experience minus training period 😛.
Just like many others, I too started my journey as a trainee. I spent six months as a trainee at rtCamp. It was a rollercoaster of emotions—excitement, fear, nervousness, self-doubt, and even a burst of confidence. Sounds familiar, right?
When I began my training, I had no clue what to expect next. Our trainers, seniors, managers always use to discuss about different projects running in rtCamp and how are they managing things there. It was first of all very difficult to remember so complex projects names like manheim, auto-trader, kelly-blue-book and a lot more 🤯 . But then, somehow collecting all my shattered brain pieces and working again on the given training task, I find my way to this and started enjoying the process.
At first, things felt a bit overwhelming—maybe even more than a bit. But as time went on, it all started to make sense and became easier to manage. Just as I was settling into my comfort zone, training period had flown by and I got to know that I will tagged onto one of a project for real deal work.
Playing the guessing game about which project I’d be tagged onto felt like a real brain teaser! But soon enough, the surprise was revealed. After a bit of decision juggling, I landed right on the rtCamp’s very own project, rtcamp.com. 🎯
The work started with a full boom 🚀. I got onboarded to the project, setup my local environment and as soon as I opened the project code, it was a whole bundle of thoughts thinking, “Yeah, I have seen all these terminologies in my training but hey do they connect with each other like this? 🤯”. Soon after I had a first standup call with my team in morning, I got to know that I will be working with the senior engineer managers whom I admire the most, as I was still unfamiliar with the rest of the team. But, hold on—everything they said in that call might as well have been in French to me 🫢.
After that I got my first task which I had to understand and implement. The task was related to custom Gutenberg blocks and their variations. Thanks to the training, I was already pretty familiar with how these blocks worked, so it seemed straightforward at first glance. But here’s the thing—unlike in training where requirements are set in stone, in the real world, they shift all the time! Adapting to these changes was my first real lesson on the job.
Don’t just do what was told and written, always try to think whatever you can do to make it work best in the situation.
But there is always a doubt in the mind, what if my ‘best’ isn’t really the best?. There’s very simple solution to that - Communicate it! Ask you seniors, your managers and they will very honestly will tell you what’s wrong and right. No cap! and maybe that’s how we learn and grow.
And that’s how I learned that
Communication is the key to transferring your thoughts, ideas, and insights—so you better make full use of it.
Soon after I had a task in hand which could really change our whole website—a bit nerve-wracking, right? It was related to backend, a custom command line script which will be used to update the whole styling of the website. Interesting enough!
It was a good challenging issue for me. I have to think about all the edge cases like What if the script stops working halfway? What happens to our data then? And what if someone runs this script on, say, 10 million posts? We sure don’t want it to take forever!
These edge cases may not come naturally to a person who is just starting and here’s where the role of a senior experienced engineer comes in and that’s how I understood that
Keeping senior or experienced engineers in loop is the best idea to make sure the work comes out in best form.
So, a little help from the experts can really make things smoother!
After working on tasks and features, when they get merged into the site, our QA team gives everything a thorough check. They make sure nothing breaks because of the new changes, and if they spot any issues, we need to fix them ASAP. 🛠️
Fixing QA issues quickly becomes a top priority. I’ve learned that there’s usually more than one way to tackle a problem. Sometimes, a quick tweak in the code does the trick. But other times, the code needs a more thorough cleanup or restructure, which can take more time.
As engineers, the choice is ours, but I’ve realized that quick fixes are often just temporary solutions—like putting a bandaid on a crack. 😬
Working in this project, here’s something else I’ve discovered, the faster we fix big issues, especially those related to the structure of our code, the smoother everything goes later on.
The better our project’s structure, the faster we can develop things. 🚀
All of these experiences sum up what real project work has taught me. There’s not much difference in technical knowledge before and just after training, but the real-world experience can vary greatly.
Lastly, I’ve come to realize something crucial, a good and understanding project manager really makes a world of difference. When you have a manager who is supportive and rational, even if not the most technically adept, who understands the big picture and doesn’t point fingers—it’s like the cherry on top. 🚀 I’m lucky to have such a manager, which has smoothed out my entire working experience.
This experience is just a start in a galaxy of more experiences, as I am just starting out. I’m looking forward to sharing more stories like this one!✨