Learning From Experiences

• Open-Source Tool
• Reading the Logs
• It’s a 403
• Don’t Repeat the Mistakes
• Conclusion

I came across this tweet by Daniel on how beginners tend to learn faster from others who figured things out recently:

Beginners tend to learn faster from others who figured things out recently. You can teach something even if you don't have a lifetime of experience.

In fact, you newness can be an advantage.

— Daniel Vassallo (@dvassallo) January 20, 2022

The past few weeks were filled with learnings, mostly related to the small and stupid mistakes I made and how I learned from them while gaining experience.

Open-Source Tool

I have been working on an article related to an open-source tool since the last week of December. I was able to get a simple build working without any hesitation on my local machine and on the CI/CD platform in the first week itself.

However, the problem started when I tried to use it on a bigger project. And a plugin that was supposed to make it easier to work with. I couldn’t get it working.

I went through all the issues and the pull requests but was disappointed. Developers had similar issues, but nothing as exact as mine. I even went through the code to understand what the errors meant, but I still couldn’t just figure out what went wrong!

Reading the Logs

After opening an issue on their repository, now I know, though. I read the logs but didn’t decipher what it meant. I just copied and pasted them on Google. I hoped to find a magical answer on Stack Overflow that solved all my problems with a one-liner solution.

Sigh.

I wish it were that easy. But should it be that easy?

The error was something along the lines that Multiple commands produce... and it mentioned that two scripts are trying to produce the same file. While typing this, it sounds so uncomplicated to debug:

• Two scripts are trying to produce the same file.
• Find the redundant one, and remove it.

That’s it.

But at that time, it felt like there was some bug, and someone may have faced it too. So let’s copy the log and search for it.

After failing at it for a week with more than a dozen builds, I opened an issue asking for help. The engineer who worked on the tool flawlessly found where I duplicated the command.

I learned that I should read the logs.

It’s a 403

The second incident is worse. After reading the logs, it showed a 403 response and found that the plugin removed the secret keys when I installed it. I thought it was a bug in the plugin. After manually adding the keys again, it worked! So, somewhere, they missed something, and I should inform them.

Oh, boy, I was the one who missed reading the documentation. One line mentioned:

An object that is passed to the can contain all properties supported natively in the . In addition to that, extra parameters are unique to the .

Instead of setting the object in the tool, I had to set it up for the plugin (only once) because it supported all the properties.

I learned that I should scrutinize every word in the documentation before jumping to any conclusions.

Folks, read the documentation, like scrutinize every single line.

I wasted so much time and effort because I skimmed over a few words.

— Rudrank Riyam (@rudrankriyam) January 19, 2022

Don’t Repeat the Mistakes

Best part?

I explicitly mentioned everything that could go wrong in the article.

The reader doesn’t have to invest their time on 50+ builds, going through issues, pull requests, code, and everything in between.

Conclusion

It took me a few weeks to set up a simple project with the plugin.

It took five minutes to set up a complex project with the same plugin yesterday.

I guess that’s what experience is, and even though I wasted too much time on this, I know I will be cautious about approaching future tools with a different mindset.

Tag @rudrankriyam on Twitter, and let me know if you liked what I shared!

Thanks for reading, and I hope you’re enjoying it!