In the work, my tasks seemed like related to each. So I’ve offered my mentor that I’ll choose the second one for all my tickets from now on.

“PR bekleniyor”: Waiting for PR (in Turkish)

Then he told me the worst case senario which is when:

  • Ticket1 is decided to be unnecessary/dangerous.
  • Ticket2 still needs to be merged to master.

In the deployment of second option above, if a mistake is made and ticket2 directly deployed to production; you’ll worry the effects of ticket1.

Meanwhile, first option seems safer. There may be shitty things if these tickets are related, but its worst case scenario is safer. Do you agree?

--

--

All of my tests pass in CircleCI whereas a test fails in my local. How is it possible?

The reason is that if you are listing multiple objects in DRF, response results can be ordered differently if there is no defined ordering. In CircleCI it was ordered as I wish. Therefore it passed that test. However, in my local, response results were ordered differently which leads to a fail.

Amazing!

--

--

Just like computers, we have a call stack. For example;

  • Found a problem. It is related with the field X of model Y. What is that?
  • Oh, field X is foreign key of model Z. Let me look at Z first.
  • Understood model Z, let’s come back to field X of model Y.
  • Understood the field X of model Y.
  • Solved the problem. Hurray!

Also, just like computers, we do have limited call stack. For example, I got frustrated if depth of my call stack is bigger than 3.

Therefore, my fellow interns and juniors, it’ll get easier as we spend time with the codebase. Let’s get help when our call stack goes way beyond, cuz its normal to get lost. I’ll leave you with a quote from the series Bojack Horseman.

--

--

Can Bölükbaş

Can Bölükbaş

Senior Computer Engineering student in Boğaziçi University. Interested in backend.