Things that are hard: trivial POST request from the browser

I’m trying to make a trivial web app. Why is this so hard?

Glitch is an amazing site for making this, but its “simple node app” example does not POST anything back to the server.

I finally got this working. Here’s the result — it might be useful to you to remix it.

https://send-json-post.glitch.me

Things I figured out:

  • add the json middleware to express
  • some library to post from the client. I used axios because it’s what we use in our apps. This is probably not the simplest one
  • browserify middleware to be able to install it from the client
  • the Chrome developer tools, alt-cmd-I on a mac:
  • you can see the request headers in the network tab if you click on the request of interest and then scroll down in the right place.
  • to play with things in the console, like trying to make a POST request: find the script under “sources”. put a debug point where you need access (like in my case, I needed axios, so I put it at a place where I used it). Then in the “scope” section of the debugger, find that variable, right-click on it, and save as global. It appears as “temp1” in your console. Don’t forget to push play to make the debugger let go. The global variable stays available and you can call “temp1.post(…)” etc to figure out what you’re doing.

Then getting anything to update in the front end, that was hard too. I’m definitely going to bring in a front end framework before I try to do anything further.

Mutual Purpose and Agreed-Upon Methods

I’ve long preferred to work on teams that base cooperation on shared values like inclusiveness, respect, and curiosity. Teams where everyone feels valued at all times, both as a coworker and as a human.

Yet, the phrase “shared values” kinda gives me the willies. It implies that our compatibility as teammates comes from deep-seated beliefs. Which implies shared culture or even religion. I want to collaborate with people who are more different from me than that.

A teammate is anyone whose success is entwined with mine. We succeed
together and fail together. This means we have a shared goal: a mutual purpose. We are going to the same place, regardless of where we each came from.

Yet mutual purpose is not enough for us to cooperate: we need to agree on how to achieve it. If we want to have dinner together, and you go to the grocery for ingredients while I book a restaurant, we are defeating each other. We need to agree that we want to share dinner and we will achieve this by cooking it, and this will require gathering ingredients and cleaning the kitchen. We can pair on tasks or divide them, but we can agree on what needs done. This way we value each other’s work at all times.

In software development, I want to agree on who our customer is and what we are doing for them. Everyone in the team shares this purpose. And I want to agree closely enough on how to do that. Like in science: an “invisible college” of collaborators exhibits shared purpose and practices.

For instance: on my project, we aim to change the way people deliver software. Our methods include:

  • provide an open-source software delivery machine framework, so people can write delivery in code.
  • in TypeScript, because it is widely accessible (lots of people know JavaScript) plus makes a framework more discoverable (with autocompletion).
  • delivering to npm, after passing our chosen checks, through code that we also control
  • collaborating asynchronously, with pull requests and in chat, so that people worldwide can participate. We each follow the code changes and a few specific channels.
  • with mutual respect and assumptions of positive intent. When we are confused by another’s actions, hop on a video call.
  • plus near-weekly planning meetings where we can go deep on what needs to change.

Agreed-upon methods incorporate: what solution we’re building, what we prioritize, some degree of architecture and implementation detail, our collaboration practices, and how we evolve these. The level of detail and which parts are important will vary by team, as needed for their purpose. It is important that they do vary; otherwise this is not a learning system. In our teams as in our technical architecture, the crucial question is “how do we change it?”

Some of these methods conflict with some deep-seated beliefs. Personal values can matter. For instance, if one of our methods is: “when we communicate, every team member’s opinion is heard” and some potential team member believes “the opinion of a woman is irrelevant” then no. That person’s deep-seated beliefs are in conflict with the agreed-upon methods of our team. If a potential team member believes that ignorant customers are to blame for any mistakes they make, that is in conflict with an agreed-upon method of discoverability.

Hiring becomes, will you adopt our mutual purpose? can you join in with our methods? and will you help us reach better methods in the future?

A person’s values might conflict with our team’s purpose or methods, but I don’t want to ask someone to hold particular values in order to work on my team.

Can we please replace “shared values” with “mutual purpose and agreed-upon methods”?