Maybe don't link to a URL (https://neuton.app/roadmap/29) that shows only a login request. Most people here aren't logging into anything without knowing more.
Your actual login page (https://neuton.app) is a bit more intriguing and looks interesting.
The biggest issue with stable coins at this time is that none of the primary stable coin providers will agree to follow GAAP and have trusted 3rd party audits. As a result, it is hard not to see the whole cryptocurrency ecosystem as a house of cards on an unstable foundation.
Will Glo allow 3rd party audits by an accredited firm? If so, THAT is how you'll get people to switch over.
Understanding the relationship between software and user value.
Very little software is developed for purely artistic purposes. Most software is built by businesses in order to sell to willing buyers with a need that the software can address. Developers who understand this relationship will be able to identify and implement solutions that no manager can even think of much less implement. That provides the power to move a business and is both rare and extremely valuable. That value provides you, the developer, with the power to work on the things that interest you most either for yourself or if you desire for someone else.
Depends on your definition of interesting. Is this 'interesting' as in intellectually stimulating and maybe even makes me a better person? Or as in 'interesting' because it solves a useful problem for the world but maybe a bit boring to actually work on?
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.
I'm pretty sure they didn't have lenses. Lenses need optically clear glass. Clear glass came along around 100AD, but it took another 1000 years before it was sufficiently clear that you could make good lenses with it.
Glassmaking would be a good one because the chemistry is based on available materials and with sufficient knowledge you would walk them through the history of glassmaking up to a simple lens and make eyeglasses.
A functional glider would do nicely I think. (Doh, they had those with Daedaleus and Icarus).
I was going to suggest a boat or a hot air balloon, but Archimedes figured that one out.
Another thought would be a simple steam engine. The Greeks had iron and knew how to work it. All the rest is knowledge that wouldn't surprise them, but they'd not put it all together.
The Greek's theory of chemistry was all kinds of messed up. There are likely lots of examples there that could be used as well.
Can you describe a bit more what you mean 'startup in large companies.' There are definitely some things to know, but only if I'm understanding what you're asking about.
At a minimum, you might start with understanding that there are essential differences between existing large organizations and startups. Most noteably that startups exist to SEARCH for a business model that works. In this world, failure is a 'good' thing if it produces learning about the product you 'should' be building. In contrast large organizations exist to EXECUTE a functioning business model. In that world failure of any kind (to hit a growth target, to generate a certain amount of revenue, etc.) is a career ending mistake.
For this reason, startup in a large organization is hard because everything about the organizational structure is about execution. The metrics you'll be evaluated on are about execution, not about learning and assessing progress towards product market fit. Even if you think it will be different it won't because there will always be one level higher in the organization that doesn't really fully GET this difference and try to impose execution metrics or leadership styles on your 'startup' team.
Steve Blank has a LOT of really good content about this difference and some others about how to do B2B product development.
Your actual login page (https://neuton.app) is a bit more intriguing and looks interesting.