I agree, and this is the very reason why I favour big-endian in this particular case. I diagnose the correct use of EEPROM by raw byte dumps to serial: with big-endian, I have one less thing to worry about. I also don't have to worry about any mismatch between RAM and EEPROM endianness when I only move single bytes around. But an int16_t has 2 bytes, so the question of endianness arises: To follow what the RAM does and go little-endian or to favour human-readability and go big-endian? For me, the latter makes more sense.