It's been a long time (no seriously) since I have heard this phrase reiterated:
'It's just code'
The emphasis being on the 'code' part of the comment.
This 'callout' is a hallmark of senior/principle engineers who don't (or can't) understand the question at hand. It's saying to the other party that there's a distinct lack of understanding on one side of the table. Specifically, the side of the table that holds more 'weight' at the organization. To top it off, it belittles the person asking the question and likely makes them feel like 'less of a developer'. If it doesn't do any of these things, it surely makes them think twice about if they are 'worthy' to be at this table or not.
Let's hypothesize that it's a problem brought to these folks from the wider engineering culture. It even maybe these people's jobs to breakdown and figure out smaller paths to solutions and a general way forward for everyone. Then their response is...
'It's just code'
It is not only utterly flippant, it teaches other senior and principle engineers that it's OK to approach problems of this kind with this 'result'. There's no need to stretch and make anything better because...
'It's just code'
Unfortunately this is simply the wrong angle in almost all regards. There's a key communication breakdown above all else but, there is also a showcase of flagrant elitism and denial that the issue affects anyone besides the person who raised it.
Software engineers of every level should take the time to view problems from all other levels.
Pairing is one of the best ways to go about this,
as well as being quick to initiate small feedback loops.
This might be opening a pull request after the first WIP commit,
sharing branches of work with key product owners and passed code maintainers (git blame).
If coding isn't suitable yet, showcasing requests for proposals during demo days are a great choice.
Although these items might not be 'as easy' as saying:
'It's just code'
They go a long way in building a culture that's less about blame and more about exploration and pushing boundaries. Questioning is half the battle when it comes to propelling an engineering culture forward. The other half is having a group of people who are willing to listen and either assist in changes, or find others who will.