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.

 

 

Polymer/Lit Skills Update – June 1, 2018

Photo by Tim Mossholder on Unsplash

appwriter_logo

If you thought about hiring me to help you out remotely on your Polymer or Lit project, you’re probably wondering what kind of results you would get.

Update June 1:

This update is identical to my May 1 update, excepting this section.

The Polymer team announced their move to Lit from previous Polymer during May. This exposed a large gap in my skillset, which was still weak on the javascript side.

I spent most of my working hours in May doubling back on javascript and especially ES6 functionality. I still have a ways to go to catch up to the many pieces of javascript that are necessary to move to Lit, but May saw good progress in this direction.

Skills:

One way of knowing is to see what I’ve built with Polymer. It’s all open source, but that could be time consuming, as it involves over a dozen projects, most too lame to sift through. I’m very pleased with my progress, even though its less than a year’s aggregate work. Polymer is super-fun to work with.

The ultimate test of my skills could be viewed in my alpha app, deployed at pullmodel.com, but it’s still alpha and most of the app’s functionality is only visible at the higher permission levels. So I made this video to at least let you glimpse at the kind of functionality I can easily help you with. Or, this one from a couple years ago.

Limitations:

My strongest motive in this post is to accurately present my well earned humility with Polymer. Because I’ve seen what the truly great coders in Polymer know – I spend time with them almost every day on the Polymer Slack feed. I am constantly reminded how much there is to learn about this world.

I’m good at cranking out the work and solving problems, that I can offer confidently. Straightforward CRUD stuff, deployed on Firebase, you can engage me there and know that it will get done in a reasonable amount of time.

If you’re looking for the kind of blackbelt javascript work that will get you out of tight cracks created when your JS is too ambitious or advanced – I know those guys – but I’m not in that group. There are so many aspects of advanced JS that I know about, but have not fully conquered…yet.

My primary deficits are in the areas that I just haven’t needed so far, in my first apps. These include slots, direct interaction with shadow/shady/light dom via JS, writing promises and async behaviors, and anything beyond rudimentary CSS.

Last, if you’re wondering about Polymer 3, I have no experience so far. I won’t be taking this on until summer, at the earliest.

Summary:

Recapping from other places for emphasis here – I’ve got decades of experience as a dev, mostly in back end java – but less than 12 aggregate months of full time work in the javascript world as a front end developer – all on Polymer.

Rates:

Western economies seem to have different rates than the developing world, I’ve seen job postings that seem to imply $5 an hour, compared to Silicon Valley or Austin TX rates that climb ridiculously to the hundreds.

Given the wide variability in rates, especially for remote work, I’m pretty flexible for short term work – within the normal bounds of Western rates.

Need a Bigger Team?

Maybe you don’t want to just hire “some guy.” You need a whole team. I’m decently networked in the Austin market, and could help hook you up with any of several larger shops that could deploy a whole team, depending on your needs.