How to Start a Conversation with Software Engineer Jesus

 This article tries to imagine how a Q&A would be handled by a contemporary software engineer Jesus. I take the bumbling human side of the conversation, he answers from the god-as-man, software engineer side.

Pete:
Thanks for taking the time! Before we even start, how would you like to structure this conversation?

Software Engineer Jesus:
I’d like to set the bounds of the conversation before we start.

You are both human, and also a software guy.  So that makes you  quite limited in your breadth of focus, in any one context. No insult intended. Is what it is.

So let’s start by being very limited in what we discuss.

Pete:
Agreed. I can hole up for a week coding up just one single type of transaction with just one single type of database and user interface.
Compare that to the context that a god, such as yourself might be able to focus on.

Software Engineer Jesus:
Let’s try to leave the whole god thing out of the conversation – don’t forget that even God must – for the most part – work through humans and the like. So we stick with basic software engineering issues, for this discussion.

Pete:
Agreed: We can limit this discussion to software engineering issues. Still a pretty big topic – humans have filled entire libraries on that subject, alone!

Software Engineer Jesus:
Much like the last time I showed up on the planet, humans are still rather myopically fixated on a what they see as a kind of transactional mind space – their internal software, in one sense. At that time, the sword seemed to be a ultimate operator in the various programming language sets. And like last time I was here, churning over that same path probably won’t be an interesting conversation.

Let’s try to establish a scope that allows us to target the conversation more productively.

Pete:
How then to set this limited scope?

Software Engineer Jesus:
This won’t be that far from how I focused my original work last time I came as a human.

I’d like to limit conversations to primary human states, as opposed to secondary and tertiary side effects. Not so different from what the current leading programmers call pure functional programming, in some sense.

Pete:
You might be willing to clarify what in  the world you are even talking about?

Software Engineer Jesus:
Let’s try it this way, and again I’m reverting back to some themes from my previous visit 2000 years ago.

Remember if you read the bible, how the canonical religious actors were really emphasizing downstream side effects and roles and hierarchies and behaviors towards who had the swords. And endless irresolvable downstream transactional metrics?

Back then, one on one was the basic software app, so I just kept bringing things back to primary issues, and away from downstream tertiary details. Granted, I got a little dramatic, such as when I turned over the tables of the money changers, but I tried to balance that with focusing my work with the poor and needy. It seemed so necessary to keep shifting attention away from the mere maintenance and justifications of expected behaviors and roles.

By focusing on primary state – things like, Are you warm? Do you have a proper place to sleep? How is your health? Are you getting enough to eat? It kind of shifted the focus away from what had become a very legalistic system that almost ignored the primary states, and instead focused on side effects such as who had what role.

Pete:
Yeah, I kind of glaze over when I try to read that stuff in the bible, and I’m not doing a whole lot better conversing with you now.

You do understand that a whole bunch of us are not even believers in the same sense as others in our own system who believe something. So you’re starting to lose me already.

Software Engineer Jesus:
Exactly! That whole belief thing! Don’t even get me started. Man creates god in his own image. Might be missing some important points, this habit.

Look, if you’re starting to glaze over, let’s keep this super simple. From here, and forever forward. A software use case, as a ‘story’.

You would agree that there are actions which have effects on the primary state of individuals within any system? The data schema of this primary state would reflect – are they warm, cold, healthy, rested, well fed, etc. Direct actions with those kinds of output. Let’s focus on those. Anything else is just a distraction or a side effect. Sometimes a necessary distraction, but side effects and distractions nonetheless.

Pete:
But things aren’t like when you were here last! We have giant, complex, well architected systems that bring us these so called primary states! Agriculture, energy, businesses, government, academics, it’s all systems.

Now you don’t sound so much like a god, as just a bumbling simpleton from prehistoric times, or something.

Software Engineer Jesus:
[Long smile] Yeah. Go ahead and talk to me about systems. Try DNA – a programming language with only 4 characters – or the billions of years of ultra complex molecular and even sub-atomic systems that evolved before the first human ever jumped out of a tree. God always has to work through systems, and doesn’t even require humans to understand any of them.
Or that that even matter itself is a freak occurrence that happens in an otherwise all-energy universe, if you want to get existential about the whole thing.

We agreed that our conversation here is about software. Which, pretty much has a ridiculously limited focus. I’m just trying to direct that limited focus to an even more limited focus:  the primary states, and away from tertiary states and side effects.

Pete:
Still word-soup, to me. Can we be more specific?

Software Engineer Jesus:
Sure. That’s easy. Let’s play this your way.

Use Case: Current conventional software might wish, for example, to help the younger user advantage himself in such a way as to get the education or social position that would allow him to support his future family the best. Agreed? Decent baseline, decent set of software objectives? A canonical ‘story,’ in the agile lingo?

Pete:
Ok, so far. At least I understand the use case.

Software Engineer Jesus:
The problem with that use case design is that so much of it is just side effects. As a pure functional equation, it assumes a zero sum game. Successful user gets the education and the plum, a well paying job. The non-user, does not, because the job was a zero sum state – in this case an integer of 1. The software’s objectives have been met. But this assumes a finite level of primary states to be gained by the user, (enough food, safety, etc for the user’s family going forward) but ignores all other side effects.

Which brings up the opposing contention that side effect advocates lean towards. I’ll bring it up, but only to shut it down as completely as I can.

We could – and most importantly – humans already do – have endless discussions about the tug and pull between systems and how a rising tide effects all boats etc. By designing software that improves the lot of one user, then everybody eventually gets a better deal. So I’m not saying that side effects don’t ever evolve into primary state at some future point. Rather, that it’s not my job description, and not what I’d chose to discuss with you here and now. Endless conversations like this are like programming infinite loops, to a god, at least a god that is assuming the role of a software engineer.

What I’d propose is that, at this point in our evolution of systems, we can probably just design the software to be more direct, than merely transactional, as most software was initially designed.

Actions that seem to affect the primary states of humans and the like, maybe we can focus more attention there. And actions that just shift around side effects, yea well that’s cool and all, but let’s see them for what they are, just shifting around side effects. Not something I’m interested in. Not now.

Actions.
That cause Primary States.
Let’s just focus there.

Thoughts, beliefs, taking sides, obsessing on side effects, that’s all well and good but I’m just not interested in that conversation. Not as it relates to software engineering. Great for selling stuff, crappy for real results. Everybody’s got their own shtick, I guess.

Pete:
Anything else?

Software Engineer Jesus:
Yeah.  Speaking of shtick. This whole shtick about me being a software engineer. I’m not faulting you for this perspective, it’s actually a pretty effective filter in a lot of ways. You humans do need your filters, you are not god, you can’t see everything at once. But … I would at least like to counter with my own variation on that shtick, if you don’t mind?

I’ll pose this back as a question: You do understand that this software engineering thing is rapidly becoming every human’s job, now? By other names and other professions, everything seems to be pointing in this same direction until all ‘work’ is removed from your current systems? You’re not too many decades from hitting that goal, a whole new set of side effects for your systems to metabolize.

So sure, call me whatever you want. Software engineer is as good as the next name for my function here. Just make sure you look back at each of yourselves with that same filter. All 7 billion of you humans. Because, along with that, you might pick up on some interesting observations. Observations that might otherwise elude you.

Just saying.