Is software development interesting? Most people would say no, I suspect. Certainly most eyes glaze over when I start talking about it with non-developers (which I rarely do).
In fact, it's a very strange and interesting meeting point of diverse ideas, some better suited to literature, others to magic.
In the industry itself, we haven't got a clue what we're doing — we call it software development, software engineering, an art, a craft — what it actually is remains a constant topic of debate. And each term is freighted with meaning, implications and history.
Long before I began as a developer, it interested me in quite abstract terms. Schooled in both historicist and philological, as well as Marxian and post-structuralist literary traditions, I was naturally curious what the word 'language' even meant in programming. It seemed to have much in common with the magical languages — inscriptions which effected change in the 'real world', in reality itself. And not just on human behaviour and thought, but on the actual machineries of our lives.
At that point I didn't realise that 'programming' was only part of the puzzle, and that software development is a literary activity, probably most close to drama among the traditional forms. But it's also an interpretive literary critical activity.
What do I mean? When we design a modern software solution, we usually follow the 'object oriented' approach.
You might imagine we write big pieces of management-style code which coordinate the loading and and manipulation of data in a chronological fashion (i.e. load data, do this then that to it, save the changes, etc.). Historically a lot of development has taken this approach, and it is generally known as 'functional' programming, for reasons you don't need to know.
Under the 'object oriented' approach, we actually try to model the 'problem domain' and create an imitation of reality in software. That means we examine the language of the business problem we're solving, isolate the various actors and their responsibilities, and create software versions of them.
These are software 'objects' - defined as the data required by each and the associated actions, known as 'methods', to operate on that data - and the only way to do anything in a system like this is to ask them to perform the action for us. Common examples are user, account, institution, invoice, or payment objects.