[ilaksh]

Since it's actually about you and for that one guy, you should just tell him what it is that is set in your mind.

The thing about it though, is that mindsets are not readily transferable. They are basically worldviews which are formed slowly and because of their foundational place in cognition are remarkably resistant to change.

One challenge is technical debt. To start to understand it, find a tool that he uses regularly (assuming such a thing exists). Maybe it is Excel. Now have him solve some kind of problem with it. And then schedule a meeting with his friend the following week to review his spreadsheet. Then add requirements that his spreadsheet must handle. Tell him he must hurry so that those requirements are complete before his meeting. Ensure that there are too many requirements for the spreadsheet or that there isn't time to properly reorganize it.

In the meeting, explain to his friend that he has been the mastermind of this spreadsheet design. Have him first demo the calculation features of the spreadsheet. The have him walk through the design, show the formulas in the cells, explain his naming scheme.

The goal of this exercise is to demonstrate why engineers seem to be so concerned about their code organization and technical debt. Which is that they have their name on any mess they make in the code, and they have to maintain it as it changes. Without ever having done that part of it, it is difficult for a business person to really understand the developer's point of view.