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.— Daniel Vassallo (@dvassallo) January 20, 2022
In fact, you newness can be an advantage.
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.
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.
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.
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.— Rudrank Riyam (@rudrankriyam) January 19, 2022
I wasted so much time and effort because I skimmed over a few words.
Don’t Repeat the Mistakes
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.
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!