Should I check for nulls, even though I won't get any, as far as I know? [duplicate]

Question

I'm new to software engineering and right now I'm focused on learning the best practices to consistently write robust code. Recently I've been maintaining an application built by other people and/or my colleagues before my arrival at the company. While writing my code, I make sure of what I'm dealing with and read the "foreign" code I'm bound to use. Sometimes I find that a method is written not to return a null value. Such occasions eventually sprouted a question in my mind: should I be checking for null anyway? What if the method I'm using gets changed by a colleague and, from that point onwards, is made capable of returning null? I'm getting quite paranoid, to the point that I do such checks everywhere I use someone else's methods to get an object I need and even do so with the methods I wrote myself. What if someone else touches them? We're a team working on the same things, after all. A trivial example:

// GetData() never returns null, as far as I know, as of now,
// and an empty list is a valid value for itemsList
List<BusinessItems> itemsList = ColleagueClass.GetData() ?? new List<BusinessItems>();
BusinessItems[] itemsArray = itemsList.OrderBy(item => item.CustomerName).ToArray();

Without the null-coalescing operator to assign a default valid value, if somehow GetData() starts to return null, this code breaks. I'm sprinkling ?? and ?. almost everywhere this situation could happen in the future, if something gets changed at some point, unbeknownst to me. I'm concerned this might be code cluttering due to paranoia, instead of robust writing.
May I please ask for your opinions?

EDIT: Since this question has been flagged as a duplicate, I want to make it more specific, because I don't find the answer I'm looking for in those indicated as already answered.
What I'm doing with my code is checking for something that simply doesn't happen... Right now. The methods against which I'm defensive just never return null and I'm not accessing a database. Therefore, as of now, all the checks I'm doing are pointless. What I'm doing (I think, I'm not sure, hence the question) is prevention: "what if the method I rely on gets changed at some point and can return null?". The answer to this hypothetical question is almost always that null can be interpreted as the absence of a value (Java implements Optional<T> exactly for this) and the workflow could proceed accordingly without throwing, e.g., an ArgumentNullException.
Another example, hoping to clarify:

// GetBusinessObject() never returns null, but what if it gets changed? 
// null can still be a valid value for orderId
BusinessObject businessObject = ColleagueClass.GetBusinessObject();
string orderId = businessObject?.OrderID;

So, is this "prevention" that I'm doing just paranoia-driven code cluttering, as I'm afraid it is, or am I doing a good job by preventively designing the workflow to handle potential changes in the code?

I hope I explained my doubts well. I'm sorry if I couldn't, I'm a newbie scared of doing a bad job.