This Weekend I Read… (2019-04-14)

Amazon Workers Have a Hellish Job

With her job at Amazon, she hoped she could work and pursue an education at the same time. For years, the 27-year-old English major had taken other short-term warehouse jobs—mostly for retail companies, including the shoe store Zumiez. 

More than two years later, injuries to her shoulder, neck, and wrist sustained during her time at Amazon—lifting up to 100 items an hour, moving them to conveyor belts, and then hauling them into trailers—have made it nearly impossible for her to type without the aid of voice dictation software.

Between 2015 and 2018, OSHA reported 41 “severe” injuries resulting in hospitalization, including six amputations and 15 fractures, associated with Amazon delivery or fulfillment jobs. 

Amazon workers are receiving severe, life-changing injuries on the job, and Amazon is covering it up using a system of in-house “clinics”, complicit company-mandated doctors, and missing OSHA filings.

Who doesn’t think Amazon workers suffering through this should have a union? Well, Amazon for one. The company is using old-school union-busting tactics to single out and remove pro-union workers.

Meritocracy is Still Fake

Belief in meritocracy is a core part of our modern ideology, particularly in the tech industry. Unfortunately, meritocracy is a false idea that does not exist. Worse, research shows that believing in meritocracy makes you more selfish, less self-critical, and more prone to acting in discriminatory ways.

Although widely held, the belief that merit rather than luck determines success or failure in the world is demonstrably false. This is not least because merit itself is, in large part, the result of luck. Talent and the capacity for determined effort, sometimes called “grit,” depend a great deal on one’s genetic endowments and upbringing.

This is to say nothing of the fortuitous circumstances that figure into every success story. In his book Success and Luck, the U.S. economist Robert Frank recounts the long-shots and coincidences that led to Bill Gates’s stellar rise as Microsoft’s founder, as well as to Frank’s own success as an academic. Luck intervenes by granting people merit, and again by furnishing circumstances in which merit can translate into success. This is not to deny the industry and talent of successful people. However, it does demonstrate that the link between merit and outcome is tenuous and indirect at best.

According to Frank, this is especially true where the success in question is great, and where the context in which it is achieved is competitive. There are certainly programmers nearly as skilful as Gates who nonetheless failed to become the richest person on Earth. In competitive contexts, many have merit, but few succeed. What separates the two is luck.

We Get to Decide What Comes Next

We’re living in interesting times. I think there’s pressure building up on one of those socio-political-historical fault lines. We might live to see humanity evolve into its next political and economic model. This can be daunting, but it should also be exciting. After all, if we play our cards right, we can determine what this new model will be.

While I don’t agree with the authors entirely, this article gives much food for thought on this idea. It is likely that what comes next won’t be any of the old models, and won’t be accurately predicted by any futurist.

Where their argument falters is that they seem to assume that which of these models will emerge is a function of which one best addresses the challenges of the modern era, climate change, and the pressures of automation. That’s not how economies change. Economies change as a function of who holds economic power, those people’s interests, and how people generally relate to economic activity. Without radical economic democracy which places power in many hands, whatever comes next will only serve the few who currently hold power.

Though I do have to give a special shout-out for introducing me to the term “doughnut economics.”


This Weekend I Read… (2019-03-25)

Here are some interesting (and sometimes scary) things I read this weekend:

Facebook Content Reviewers Have A Hellish Job

Content reviewers at Facebook are constantly subjected to horrifying videos of violence, racism, and conspiracy theories, and they aren’t being given the support they need. Some might wave this off as “the nature of the job,” but I think like anyone in a hazardous job they should be given the right support structure, safety equipment, and hazard pay. Instead, the moderators (who are outside contractors) are paid far less than the average Facebook employee, and are subjected to a high pressure environment where they watch 2,400 traumatizing videos in an 8 hour shift (4 per minute) and managers time their bathroom breaks.

The Real Reason for the 40 Hour Work Week

David Cain, writing at his blog Raptitude (“Getting better at being human”), puts forward an interesting theory about why we still have the 40 hour work week even though the average office worker is productive only 3 hours a day and productivity has been steadily increasing in the years since the 40 hour work week was won. His theory: it isn’t about labor supply, but instead it is about the demands for goods and services. Tired, time-constrained workers want more creature comforts, and buy more convenience items (fast food). They also prefer hobbies which take less time and energy, but more money (e.g. TV, movies, fast fashion) over hobbies which are cheap or free, but time consuming (e.g. reading, gardening, DIY crafting). His anecdotal observations which are woven throughout— such as developing a habit for expensive takeaway coffee after getting a new high-stress job— jive with my experience as well.

The Life Changing Magic Manga of Tidying Up

Did you know that there is a graphic novel version of Marie Kondo’s The Life Changing Magic of Tidying Up? It’s a fast read (about 180 pages, mostly pictures) and it is overflowing with charm and wholesome energy. I think it could serve either as a good introduction to the KonMari technique or as a quick refresher.


Elixir Programming Language and the Phoenix Framework: What can you build with them?

You can use the Elixir programming language to build anything that you can build in any other programming language. It has a great framework for web applications called Phoenix. It can be used in embedded systems— see Nerves. It can be used for anything in between.

When people ask what Elixir can be used for, (or here) the common replies are “chat servers”, “telecomm switches”, or “APIs.” I think the reason these are the common replies is that Elixir really shines in areas where you need to handle very high volumes, have high reliability, and do real-time or near-real-time communication. And Elixir is good for those cases, but it also excels as a language for making systems that don’t need to handle huge traffic or real time communication.

Phoenix, as a framework, can essentially do everything Rails, Django, Laravel, or Spring can do. It has models (ok, schema structs), views, and controllers. In my experience, it has some serious advantages over Rails, Django, Laravel, or Spring. For one, yes, it is faster. Responses come in microseconds, not seconds or milliseconds. To me, that’s not the most important thing. What’s more important: the architects of Phoenix learned from the missteps of those other frameworks. Phoenix and Ecto (the persistence wrapper) made better choices.

To cherry pick one example: in Ecto, you have to explicitly say which related data you want fetched from the database. In ActiveRecord and Rails, if you miss a join, Rails will just load the related records when you need them. That sounds great until you put it into a loop. Rails will quietly and diligently ping your database with many queries in a row, fetching one extra record at a time. Ecto instead asks you: “Hey, did you want this? Because you didn’t ask for it.” It forces you to be clear, and in forcing you to be clear, it can be efficient.

To pick another example: in Phoenix, your entire request-to-response circuit is just a series of functions, output from one piped as input to the next. Each receives a connection and returns a connection which may or may not be different. Most of those functions sit directly in your application source code. The ones that don’t are clearly invoked from within your source code. Need to add a new junction in the chain? You go into your code and add the junction. This is how Plug works. In Rails, most of the processing of requests and responses is hidden. It lives within the Rails framework code. To modify it, you better hope that the designers of Rails left an appropriate config variable or lifecycle callback. Otherwise, you just have to “patch” Rails in memory. And you better hope that you patch the right spot and that the patch loads correctly. If the Rails team renames the methods or classes that you patched— your patch falls off and your application breaks.

So, what can you use Elixir for? What can you use Phoenix for? I personally use it for everything unless I have a good reason not to. It’s been a long time since I’ve had a reason to use something else.

Bonus Q&A: Ok, but what have you built in Elixir?

Me and my team have built, with Elixir:

  • An incentive platform for software developers
  • Tons of business workflow automation and management software for several industries
  • Real estate tools
  • Event booking software
  • Local business directories
  • Content management systems
  • Customer relationship management software
  • Chat bots