[riskpeep]

I'd suggest helping him to see the 'whole' job. What do I mean by that? The best development (and developers) understand that they're not just writing code, but that code is the tool that they use to solve the real problem of the business.

That would mean spending a few minutes helping him to understand why you're writing the code you're writing and how it will impact the product or business.

Then, I'd walk him through your typical development process. Show him your ticketing system, how you identify user stories (if you're using agile) or features, how you groom those stories (e.g. things that make a story useful or not, the dialogues that you have with people to understand what you need to build), and the life cycle of a ticket.

Finally, (perhaps after a break), you could walk him through your development loop - Look at a ticket or feature, start exploring the code to see what you need to change, make an edit, run tests, commit your code, etc.

IMO, the important take away for him would be to see that development most often isn't a developer sitting at a desk typing at a computer all day. My experience has been that software development is an interactive experience with myself and other developers, myself and other teams, etc.

Not sure what kind of dev you do, but if you were so lucky to be working on front end, showing him how a change you make creates visible change on the screen that he sees as a user would be pretty powerful. Particularly if the thing you're working on is something that he could see after he leaves or that his friends might know about.