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.

Jesus was a Software Engineer

Don’t blame Jesus for not using the latest tech, none of us can keep up, not even today. 2000 years was a long time ago.

But make no mistake about it, Jesus was a software engineer. And a good one, at that. Buddha and Mohamed and Confucius too, for that matter. But already I digress. Jesus set the highest mark, in my opinion.

Show Me the Abstraction!

Jesus did, in his time, exactly what he would do if he were alive now. He would take one look at all the haranguing and respond with ease. “Dude, your looking at the wrong abstraction! You’ll never figure out how solve for that equation given the data that your looking at!”

Software engineers like me are grabbing the data, presenting it back to you in a more usable form, and hopefully improving your life. I might keep your transactions straight with some remote vendor, or help that same vendor deliver digital content or goods back to you.

In much the same way, Jesus was all about transactions and delivery, but somehow, he found a better point of abstraction. Duh, of course he would, given who he was. But the point is still the same. Where the local boys were trying to figure out little power games between themselves, Jesus wrote software in the area of love and language itself. His equations were simple and tough, and more than anything else, they worked, where the local boys were writing software that had plainly left much to be desired.

Human Interaction as App

The app, at that time, was pretty much limited to human interaction.

Practitioners of power, at that time, did so through the sword. Jesus got that he needed a more powerful medium, and he used the most powerful medium available to him at that time. It took a few centuries, but one human interaction at a time, spreading love with love, Jesus spread his software in an open, reliable, app.

Even later, when the Roman Emperor Constantine took the religion over as a state function, much of what drove the app remained difficult to contort. Well designed software is like that. Anything that can be taken over by power hungry emperors and still maintain any degree of purity is pretty impressive.

Open Source:

By relying on human interaction as the app’s deployment model, Jesus employed open source in one of it’s earliest and most successful adaptations. How interesting that his basic data structures were able to remain intact even without the rigor of tight source control and enforcement of intellectual property rights!

Your Job:

If Jesus’s teachings had a theme, it was certainly close to a theme of personal responsibility. Half an inch below every verse in the new testament, there seems to be a plea:

  • Run tests on your software!
  • Look carefully at how it performs!
  • Don’t just write a program! Look at the basic design!
  • If it doesn’t help people, try to improve it!

Jesus was tough, but he was also kind. He seemed to expect us to carry on with his work, make things better.

 

 

Two Flavors of Logic: Science, and Debate

Photo by Andy Tootell on Unsplash

Debate Logic exists to prove that a belief is correct.

Science Logic exists to shed as much light on a subject as practical.

What follows is used to illustrate the primary difference between debate, and science. They are used for entirely different purposes, despite how similar they look.

Why do we care about Debate and Science logic?

We only care about this if it serves our purposes.

Myself personally, I care a lot about recognizing debate logic because other humans can use debate logic in a predatory fashion, to gain power over me, or destroy things that I care about most.

The easiest example is the environment. If Fox News uses debate logic to spread the belief that environmental issues just don’t matter, then that is an issue for me personally, because it’s something I care about, and science logic doesn’t seem to yield the same conclusion.

The above is just an example. There are quadzillion real life situations like the above that fall way outside of this example, any one of which might affect our shared future to a great degree.

Cliff Notes Version:

The main idea behind science logic is to shed light on the subject. Like the physical act itself, when you shed light on something you might see something you hoped you would not see. But there it is. You’re interested in the truth, and now you found it. Oh well. Back to the drawing board.

The main idea behind debate logic is to win an advantage that lies external to the logic itself. Debate logic is about winning an argument. Truth, in this scenario, is belief based. Debate logic also uses light to illuminate specific things, but to ‘win’ at debate logic you use the light very selectively, to illuminate only those facts that help you win the argument.

The essence of great debate logic is great theater, which might include talking louder, righteous anger, looking better, even bringing in scientists to give your carefully selected debating points more credibility.

For More Information

To learn more about science logic, look up ‘scientific theory’.
To learn more about debate logic, look up ‘debate’

Fun

Feynman on scientific theory – 10 minutes

Personal

My favorite phrase for debating is ‘assertion based logic’ where all the effort is used to defend or justify a belief, rather than illuminate the truth.

My favorite bad guy is someone that uses debate to resist change that is inevitable anyway. Technology always causes more change than people are comfortable with, so I see a lot of that everywhere I look.

An interesting scientific observation is that debate logic is much more powerful than science logic, because debate logic is easy and natural, and science logic, by its very nature, can go against our deepest core beliefs and assumptions. This has been proven many times by scientific experiment.

Debating is a much more efficient process. Selecting winning arguments means you can pass the ‘blink’ test and win the battle of public opinion . Science might require hundreds of scientists dozens of years just to run one set of experiments on one aspect of data. By that time, the effective debater may have already convinced 99.9% of a population what ‘the facts’ really are, nevermind any evidence to the contrary.

Debate has passion! Science requires passion too, but it’s a different kind of passion required to run tedious experiments when you are already half bored to death with the last 2500 experiments that you also had to run. Boring stuff, science.

Strong debaters mimic the appearances of science. The more scientific your argument appears, the more likely you are to win the argument. Wear a lab coat, and glasses too.